Как разрабатывать сложный продукт и параллельно улучшать его дизайн

От бессистемных макетов к проектированию по утверждённым правилам

Привет, это команда В2В-дизайна в Банке ДОМ.РФ. В наши задачи входит дизайн основного продукта для юридических лиц — Единого личного кабинета. С его помощью клиенты проводят расчётно-кассовые операции, работают с накопительными/кредитными продуктами, а также решают многие другие вопросы взаимодействия с банком в цифровом виде.

В рамках работы на Единым личным кабинетом мы параллельно ведём следующие направления деятельности:

Занимаемся продуктовым дизайном, готовим макеты клиентских путей для новых фич (продукт находится в стадии активного роста);
Развиваем дизайн-концепцию продукта;
Моделируем и развиваем дизайн-процессы в домене.

Таким образом, мы играем и составляем правила игры одновременно. Кроме того, макеты некоторых фич для нас разрабатывает вендор, поэтому согласовывать и утверждать правила дизайна иногда нужно очень быстро — сотрудники вендора не погружены в контекст работы и не знают ничего о внутренних договорённостях на словах.

Эта статья для вас, если при разработке макетов вы часто сталкиваетесь с подобными вопросами:

Какой из вариантов реализации верный? Есть ли записанные правила?
Почему в разных разделах эта механика реализована по-разному, хотя функционал похожий?
Как это будет выглядеть при развитии? Какое дизайн-решение выбрать, чтобы оно справилось с дальнейшим масштабированием?

Сегодня поговорим о том, как мы эти правила разрабатываем, утверждаем и документируем.

Приведём здесь общую схему, а ниже подробно опишем каждый шаг. Чтобы алгоритм был полезен в вашей работе — пробуйте адаптировать его под особенности дизайна в вашей компании.

Под дизайн-паттернами, о которых далее пойдёт речь, нужно понимать систему правил, по которой в цифровом продукте будет спроектирован тот или иной пользовательский сценарий. Ниже приводим несколько примеров таких паттернов:

Набор элементов, из которых собираются табличные блоки интернет-банка, а также документация по использованию этих элементов.
Полноценная модель работы экранных уведомлений. Она может включать в себя сценарий анимации появления/исчезновения уведомлений, правила группировки при появлении на экране множества уведомлений, а также описание других связанных механик.
Правила цветового кодирования статусов документа в зависимости от этапа процесса (например, когда прописано, что отклонённые документы имеют красный индикатор определённого цвета из дизайн-системы, а согласованные — аналогичный зелёный).

Важно: хуже, чем отсутствие правил, может быть только постоянное изменение правил. Поэтому общий принцип — сначала завершить работу с паттерном, а потом использовать его в дизайне. А до внедрения новых правил лучше не суетиться — работать по старым договорённостям или рассматривать соответствующие вопросы индивидуально.

Разработка дизайн-паттернов продукта — это выявление точек роста его дизайна, документирование правил, их согласование и дальнейшее использование при проектировании макетов. В продукте, который создаётся или проходит стадию редизайна, таких точек роста обычно много. А вот ресурсы на создание правил под них чаще всего в дефиците, поэтому при выборе очень важно исходить из приоритетов. В расстановке приоритетов можно опереться на разные критерии:

Посмотреть, какие паттерны понадобятся в разработке самых прибыльных сценариев. При высокой зрелости продуктовой культуры в компании дизайнер без проблем может получить доступ к метрикам и по ним принять решение, с паттернов для каких сценариев нужно начать.
Даже если доступ к метрикам получить не удаётся — есть принципиальное понимание, что одни сценарии важнее для компании, чем другие. Например, для банка с высокой долей вероятности автоматизация сценария открытия вкладов будет более ценной, чем разработка сценария автозаполнения данных контрагентов. Определить, какие из запланированных задач важнее, поможет общение с продуктовыми командами.
Также немаловажно обращать внимание на календарь релизов — можно пробовать сначала заниматься теми паттернами, которые наиболее скоро (или уже сейчас) нужны для проектирования сценариев.

Когда выбрали «белое пятно» — нужно понять, насколько быстро получится его «закрасить». От этого зависит, в какой момент получится взяться за проработку:

Если видите понятное решение, которое можно быстро описать — можно проработать его между рабочими задачами без планирования. Например, мы в спринтах оставляем 20% времени сотрудников под внутренние процессы, и простые задачи по унификации систем можно брать в рамках этих 20 процентов. Хотя важно отметить, что «быстрых» задач по унификации у нас бывает мало — как правило, нужна вдумчивая работа, поэтому обратите внимание на следующий пункт.
Если понимаете, что для проработки нужно больше, чем пара часов — заведите задачу наряду с остальными, оцените время на работы и обсудите приоритеты с заказчиками ваших работ. Мы помещаем такие задачи сразу в бэклог дизайн-команды и общаемся по ним с коллегами на церемонии планирования. Как правило, если точка роста выбрана правильно и продуктовые команды согласны с важностью работ — отстоять приоритет получается без проблем, и задача попадает в один из ближайших спринтов.

Полностью описать создание дизайн-концепции не получится, но можно выделить список того, что стоит сделать для принятия решения:

Проанализируйте конкурентов в вашей сфере. Часто бывает, что велосипед изобретать незачем и нужная механика уже придумана.
Проанализируйте лучшие практики за пределами вашего класса систем. Здесь тот же смысл, что и у предыдущего шага — они оба направлены на быстрый поиск ответа.
Соберите кейсы в вашем продукте. В этом могут помочь коллеги из продуктовых команд или самостоятельная проверка разных разделов (макеты, а также тест/прод). И если ваша задача в равной мере решается несколькими способами, а в продукте один из способов реализован чаще, чем другие — стоит попробовать привести правила к нему и объявить его целевым.
Соберите кейсы в других продуктах вашей компании, если они есть. Например, у нас есть большое количество цифровых продуктов, во многих из них дизайнеры решают схожие задачи, поэтому обмен опытом и унификация решений — наше всё. И нет смысла придумывать, например, правила работы модальных окон для сайта, если они уже существуют для внутреннего портала сотрудников (здесь указаны схожие по классу нагруженности системы — это важно, т.к. если для кардинально разных продуктов далеко не всегда можно написать общие паттерны дизайна).
Выберите решение и проверьте его на различных интерфейсах и во всех ситуациях. Здесь советую руководствоваться условием «отлично для большинства, не ломается в корнер-кейсах». Если решение выполняет это условие — рекомендую остановиться на нём и двигаться дальше. При этом компромиссы, конечно, должны быть разумными — плохой дизайн в рамках этих правил получаться не должен.
Обсудите с разработкой возможные сложности реализации. Обычно продуктовые дизайнеры вместе с командой дизайн-системы могут довольно точно оценить возможность реализации, а оценку трудозатрат разработчики назовут в момент получения задачи. Но обсудить точно не будет лишним, поскольку всегда есть риск технических блокеров или ограничений, которые могут существенно удлинить разработку.
Согласуйте решение внутри подразделения дизайна с руководителем и коллегами из смежных продуктов. Важно договориться, чтобы решение было в согласии с концепцией дизайна других продуктов, либо — если унификация невозможна — это было зафиксировано в итогах встречи и/или будущей документации.
Опишите решение с той степенью детализации, которая понадобится для презентации лицам, принимающим решения. О самой презентации чуть позже, но сейчас важно сказать, что всегда есть риск получения критичных замечаний, поэтому готовить финальный документ до согласования может оказаться контрпродуктивно.

Результатом работ на этом шаге могут стать:

Выжимка фактуры, на основе которой принято решение
Черновик документации
Прототип, демонстрирующий решение

Важно: не полагайтесь на устный рассказ — готовьте материалы. Ваши коллеги не смогут (и не должны) ориентироваться на слух и представлять предлагаемое решение в голове. Ниже фрагмент документации по одному из наших паттернов: такие артефакты мы показываем на встречах, а после согласования — дорабатываем и проектируем макеты по ним.

На этом этап создания правила закончен — можно переходить к его согласованию.

Для начала определите список лиц, с кем нужно согласовывать решение для завершения работы над правилом. Для этого ответьте на два вопроса: чьих продуктов коснутся изменения и чьи ресурсы пойдут на разработку после утверждения правил. В нашем случае состав выглядит так:

Продуктовый дизайнер + дизайн-лид. Они фасилитируют согласование и ведут рассказ о концепции решения, отвечают на вопросы. Также фиксируют замечания, если они появляются в ходе обсуждения.
Руководитель подразделения дизайна. Больше выступает в роли наблюдателя и модератора, поскольку до выхода на общее согласование смотрим решение в кругу дизайнеров.
Владельцы всех продуктов внутри цифрового канала. Важно донести коллегам предстоящие изменения и сформировать ожидания, поэтому их тоже нужно привлечь. Также владельцы продуктов могут точечно подключать к обсуждению своих сотрудников, если считают нужным привлечь дополнительную экспертизу для приёмки.
В отдельных случаях — бизнес-заказчики направлений. С ними всегда согласовываем клиентские пути с точки зрения потребностей банка и клиентов, но, если речь идёт о точечных механиках интерфейса — достаточно вышеупомянутых участников. Привлечение бизнес-заказчиков к согласованию паттернов нужно только тогда, когда происходят изменения корневых разделов (например, обновление меню всего продукта или добавление новых инструментов подписания документов — словом, тех механик, которые существенно меняют клиентские пути).

Теперь о самой процедуре. Есть два варианта проведения:

Обсуждение голосом. Наиболее удобный формат с точки зрения отработки вопросов и замечаний, но почти всегда есть сложности с поиском свободных окон в календарях всех участников обсуждения. Поэтому советуем ставить встречу заранее — например, когда у вас сложилось общее видение концепции паттерна. Если можете достоверно предположить срок выполнения работ — то можно поставить будущую встречу уже на этапе планирования работ, принимая риски работы в ограниченном промежутке времени.
Через почту (письмо на всех лиц, принимающих решения, с возможностью обсуждения). Плюс здесь в том, что не требуется выбирать идеальное время общей встречи — коллеги смогут ответить в удобное время, а вам достаточно обозначить ожидаемый срок ответов. Важно понимать, что в таком формате отработка замечаний может оказаться длительной и неэффективной, поэтому мы стараемся прибегать к нему только для простых задач с высокой степенью определенности. Один из конкретных примеров — уведомить коллег о принятых решениях по цветам элементов интерфейса, если решение было однозначным и соответствует принятой в вашей компании дизайн-системе.

Вредный совет — согласовывать изменения с каждым лицом, принимающим решения, по отдельности. Никогда так не делайте, поскольку это лишает всех участников обсуждения общего контекста и делает достижение договорённостей невыполнимой задачей.

Само повествование при этом довольно простое и может содержать все или часть из следующих пунктов:

Если выбрали формат встречи — обозначить план обсуждения.
Напомнить о проблематике, обосновании работ и ожидаемых эффектах от решения.
Презентовать итоги анализа вашего продукта, конкурентов и лучших мировых практик.
Описать и показать решение — как устроено, какие кейсы покрывает, насколько будет сложным в реализации и какие имеет ограничения.
Обозначить сроки внедрения правила на стороне дизайна, и если оценка времени на реализацию известна — обозначить её.
Ответить на вопросы, если есть замечания — задокументировать их.

По итогам согласования возможно три варианта завершения:

Есть критичные замечания. Такой вариант мы не рассматриваем, поскольку компетенции дизайнера предполагают выяснение всех условий задачи в момент проработки. Но если критичные замечания всё же получены — нужно вернуться на этап разработки и учесть новые вводные при создании нового решения.
Согласовано с замечаниями. Здесь подразумеваются неблокирующие замечания, которые можно отработать после процедуры согласования и уведомить круг лиц, принимающих решения, о результатах.
Согласовано без замечаний. Думаю, не нужно объяснять, что это лучший из исходов и его вполне реально достичь при качественной проработке задачи.

Если итогом согласования стал вариант 2 или 3 — основная работа с правилом выполнена. Но важно также поговорить о формальностях, которые нужно соблюсти, чтобы новые правила вступили в силу и макеты дальше разрабатывались по ним.

После успешного согласования правил у вас появляется разрешение на их использование, но перед этим вам нужно сделать несколько вещей:

Отправьте всем участникам итоги согласования. Протоколирование обсуждений сложно переоценить, поскольку оно позволяет зафиксировать договорённости и вернуться к ним, если появятся вопросы. Протокол должен содержать основные тезисы обсуждения, зафиксированные замечания (если они были), а также сроки завершения документации правил.
Завершите документацию правил, отрабатывая замечания, если они были. Эту работу может выполнить продуктовый дизайнер или команда дизайн-системы — зависит от того, относится ли новое правило к дизайн-системе или только к конкретному продукту.
Оповестите лиц, принимающих решения, и других коллег о вступлении новых правил в силу (лучше всего написать краткое письмо всем причастным к новым правилам разработки дизайна). К оповещению обязательно приложите ссылку на новые правила, чтобы все могли к ним обращаться при наличии вопросов.

После приведения новых правил в действие работы завершены полностью — поздравляем вас! Вы закрыли часть вопросов в дизайне вашего продукта, и для последующих макетов для вас и продуктовых команд будут согласованные готовые ответы. Надеемся, описанный алгоритм будет полезен в вашей работе. Успехов вам в систематизации дизайна и повышении качества макетов ваших продуктов.

Автор: Антон Боев — лид-дизайнер B2B, Банк ДОМ.РФ

Как разрабатывать сложный продукт и параллельно улучшать его дизайн

Алгоритм внедрения дизайн-паттернов

Шаг 1. Выбрать участок разработки/обновления правил

Шаг 2. Оценить сложность выработки решения

Шаг 3. Разработать концепцию решения

Шаг 4. Согласовать дизайн-паттерн с лицами, принимающими решения

Шаг 5. Дописать правила и ввести их в работу

Заключение