Как дизайнерам выдавать хорошие решения раз за разом?

Привет! Я Ваня Соловьёв, дизайн-директор в «СберЗдоровье». Сегодня я расскажу про генерацию идей продуктовыми дизайнерами: как сделать хорошие решения автоматизированным, а не ручным процессом.

Эта статья будет полезна, как дизайн-лидам, продуктовым дизайнерам, так и продактам. Менять культуру и процессы в компании можно в двух направлениях — «снизу-вверх» и обратно.

Что хочет бизнес от продуктового дизайна?

Конечно же, отличных интерфейсных решений! Чтобы пользователи потребляли то, что предлагает бизнес в удобном и понятном виде. Гонка за внимание воспитала у пользователя понимание «хорошего» интерфейса. Он должен быть: понятным, удобным, простым и красивым. Для опытного продуктового дизайнера задача не кажется сложной. Выдавай раз за разом отличные решения, и ты красавчик!

Проблемы начинаются, когда дизайнеров становится несколько, они делают разные фичи, но в рамках одного приложения или сайта. Тогда понимание «качества» может размываться от дизайнера к дизайнеру. У первого один уровень понимания «хорошего» интерфейса, у второго — другой. Чем больше дизайнеров на проекте, тем сильнее расхождение в понимании «хорошести».

Как наладить процессы в продукте, чтобы команды стабильно выдавали хорошие решения?

Хороший процесс не может не родить результат

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

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

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

Шаг ноль: основа

Бизнес пришёл к продакту и дизайнеру с проблемой. Через некоторое время они находят несколько хороших гипотез, как её можно решить. Они даже могут провести базовые пользовательские тестирования или более глубокие, если в компании есть UX-исследователи. Я не стал выделять в отдельный шаг UX-исследования, т. к. не во всех командах они активно развиты. Если в вашей команде есть исследователи, то это ещё один шаг в процессе.

Загвоздка в том, что на этом шаге многие продуктовые команды и останавливаются. Ну а что? Нашли хорошее решение проблемы, описали и передали в разработку. Задача готова, можно идти дальше.

Проблема как раз в том, что такое решение зачастую оказывается не самым лучшим. Злую шутку может сыграть «замыленность» глаз у команды. Продакт и дизайнер слепо уверены в своём решении, и нет нужды искать дальше.

Это отправная точка в процессе автоматизации, но никак не конечная.

Шаг один: взгляд дизайнера

Самый ценный шаг в получении полезной обратной связи по своему решению. Дизайнеры всегда знают «как сделать лучше» и «как делать не надо».

Некоторые болезненно реагируют на критику от коллеги и сразу переходят в оборонительное: «А вот у тебя…! ». Их можно понять. Ведь непрошеная критика воспринимается как нечто чужеродное, что пытается проникнуть в личное пространство. Поэтому дизайнер инстинктивно хочет как можно быстрее избавиться от него.

Как сделать так, чтобы непрошеная критика стала желанной?

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

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

Выступающий презентует своё решение в формате:

  • Какая проблема была или есть?
  • Как искал решение? Варианты, черновики, ход мыслей.
  • Что сделал в итоге?
  • Планы на будущее, если есть.

Каждый участник даёт обратную связь в формате:

  • Что понравилось?
  • Что и как можно улучшить?
  • О «вкусовщине» говорит прямо и мягко.

Никакой токсичной критики. Здравые аргументы и логичные доводы — главная мотивация приходить на такую встречу и рассказывать о своих решениях на постоянной основе.

Побочная польза от таких встреч:

  • Появляется доверительное отношение к друг другу.
  • Развивается командная сплочённость и чувство плеча.
  • Растёт понимание, как твоё решение может повлиять на другие команды.
  • Прокачивается навык презентации решений.

Шаг два: взгляд руководителя

Здоровая дизайн-культура в команде включает еженедельные ревью дизайнера с дизайн-лидом или дизайн-директором. Это важный шаг, так как он помогает дизайнеру взглянуть на своё решение под другим углом.

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

На этом шаге уже можно возразить: «Зачем нужен дизайнер, который самостоятельно не может сделать хорошее решение?» или «Зачем дизайнеру отнимать время у руководителя, ведь у него и без того работы хватает!». Поймите, задача дизайна — дать хороший пользовательский опыт: понятный, простой, удобный. Это задача не конкретного дизайнера, а всей компании. В этом заинтересованы все.

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

Шаг три: взгляд продуктового отдела

У каждого специалиста свой взгляд на решение проблемы. Аналитик опирается на данные, исследователь — на результаты тестов, а продакт — на бизнес-показатели. Что будет, если всех собрать на встрече, где можно свободно высказать свои идеи по предложенному решению?

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

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

Побочная польза от таких встреч:

  • Поиск общих решений усиливает сплочённость команды.
  • Презентация решения продактом и дизайнером укрепляет командный дух.
  • Участники расширяют продуктовое видение и выходят за рамки своих команд.
  • Контроль единства всего продукта становится проще и яснее.

Шаг четыре: взгляд разработки

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

Помимо технических деталей, вы поймете:

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

Шаг пять: финальный взгляд дизайна

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

Поэтому этап дизайн-ревью важен, чтобы ещё раз проверить, все ли идеи, заложенные дизайнером, дошли до финала без изменений.

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

Что мы получили в итоге?

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

Получается простая закономерность, на которую не так сильно влияют внешние факторы: какая бы ни была большая продуктовая команда, она всегда будет выдавать хороший результат.

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

Уверен, только ради такого побочного эффекта можно затеять всё это!

Смотрим в будущее

Сложно оценить пользу такого процесса на одной задаче. Попробуйте внедрить его во все задачи, которые продуктовая команда приложения или сайта будет делать в течение года.

Что будет с продуктом, если каждая фича в течение года будет выходить отличной? Верно, вы получите отличный продукт!

0
4 комментария
Assel Kassembekova

Максимально полезно (as usual) - спасибо огромное! Еще бы почитать про процесс постановки задачи дизайнерам - то есть как выглядит обратный процесс в продуктовой команде.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Assel Kassembekova

да, странно сформулировал )

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
1 комментарий
Раскрывать всегда