Rose debug info
---------------

Subscribe to this blog

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

на русском · in english

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее про дизайн-процесс маленькой задачи →
Постер, ПДФ 2.3 МБ

 4929   2022   процесс   я
Next
Do you want to discuss something? Just write to me! telegram or email