Перейти к основному содержимому

Как устроен дизайн-процесс?

Глобально дизайнер сталкивается с тремя типами задач в своей повседневной жизни. Первый тип — просто что-то поправить. Второй решить какую-то маленькую задачу. Третий — сделать большой проект. В зависимости от типа задачи зависит и подход к ней.

  1. «Что-то поправить» — самый простой. Тут не нужно что-то выдумывать, нужно пойти и поправить. Будет сложно с точки зрения процесса что-то тут сделать не так.
  2. «Решить маленькую задачу» в рамках большого проекта. Например, мы хотим добавить возможность лайкать публикации в ленте новостей или добавить возможность добавлять QR-коды в свой профиль. Чтобы почитать процесс для маленькой задачи переходи сразу в пункт номер пять.
  3. «Сделать большой проект». Это что-то более крупное, что состоит из десятка, сотен, тысяч задач второго типа. И самое главное в этом подходе разбить большой проект на более мелкие задачи. Итак, если речь идет о третьем типе, то сначала нужно ↓

1. Понять цели​

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

2. Посмотреть на продукт с высоты​

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

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

Applying systems thinking in product design Shekman Tang

Creating systems not destinations Paul Adams

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

Хорошая практика прямо на этой встрече, в виде воркшопа, набросать потенциальный план исследования.

3. Убедиться, что мы на правильном пути​

Настало время валидации концепции и поиска точек роста. На это у меня есть несколько простых способов.

  1. Глубинные интервью. Отличный способ найти новые инсайты, точечно. Но не стоит сразу их брать в работу, лучше всего их отвалидировать пунктами 2 и 3.
  2. Опросы. Количественное исследование, которое может подтвердить инсайты из пункта 1 и дать поводы для размышления в отрыве от качественных исследований.
  3. Анализ данных. Количественное исследование, которое может подтвердить инсайты из пункта 1 и дать поводы для размышления в отрыве от качественных исследований.
  4. Анализ конкурентов. Верхнеуровнево посмотреть набор функций ваших прямых и косвенных конкурентов. Это поможет вам найти что-то новое и проверить то, что у вас уже есть.
  5. Анализ метрики, которую бустим. Кабинетное исследование. Как правило мы делаем это не первые в мире и про многие практики написано достаточно много статей с исследованиями и лучшими решениями. Нельзя сказать, что они подойдут нам, но изучить стоит.
  6. Анализ пользовательского фидбэка. Работа с отзывами в сторах и с тем, что прилетает в службу поддержки. Там часто есть алмазы, которые могут подтвердить вашу идею или гипотезу.

Все эти способы могут изменить вашу модель из пункта номер два.

4. Приоритезировать и разбить на версии​

Далее нам нужно всю нашу концепцию разделить на маленькие пользовательские истории, приоритизировать их и разделить на версии.

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

Для приоритезации историй по важности можно использовать фреймворк moscow, а для технической сложности фреймворк t-shirt size.

В итоге мы имеем десятки, сотни, тысячи пользовательских историй, которые приоритезированы и разбиты на версии.

5. Индивидуально подойти к каждой истории​

Далее работаем с каждой историей (маленькой задачей) по похожему процессу, но всё же, немного другому.

  1. Понимание задачи
  2. Дискавери
  3. Формулирование гипотез и низкоуровневые прототипы
  4. Скоупинг и высокоуровневые макеты
  5. Ревью результата и запуск!
  6. Анализ результата и новые итерации

Ссылки​

Дизайн-процесс Ivan Zviahin

Проектировщик интерфейсов в Контуре

Логотип Додо-пиццы: как ставили задачу и планировали сроки

Как выстроить дизайн-процесс при проектировании сложных продуктов: опыт команды Selectel