Часть 1
Часть 3
Часть 4
Часть 5

5 шагов создания
интерфейса

Сбор требований, определение целей, организация
и постановка задач

1
Сбор требований
и определение целей
Как понять суть продукта за 2 минуты
Первым шагом нужно понять суть продукта, для которого/который предстоит разработать. Есть классический шаблон из книги Мура Crossing the Chasm, который помогает объяснить суть продукта за 2 минуты (elevator test):
  • Для (ключевой пользователь)
  • Который (обозначение проблемы или возможности)
  • (Название продукта) это (категория продукта)
  • Который (ключевое преимущество, убедительная причина для покупки)
  • В отличие от (ключевой прямой конкурент)
  • Наш продукт (обозначение ключевого отличия)
Пример:
Для маркетинговых департаментов небольших компаний, у которых есть потребность создавать простую, но стильную email-рассылку для клиентов.
"Почтальон Печкин" — это веб-сервис, который позволяет на основе готовых шаблонов создать рассылку за 5 минут и при этом достичь высокого open rate. В отличие от MailChimp наш продукт заточен на особенности российского рынка и русского языка и стоит несравнимо дешевле.
Как оценить результат
Хорошо организованный процесс, это когда каждый шаг по чуть-чуть приближает нас к основной цели. Принцип парето гласит, что нужно начать работу с 20%, которые принесут основной результат, а остальные 80% можно будет делать, когда продукт уже начнет приносить деньги (MVP). Задача, определить, где эти 20%, или другими словами, что для компании «Ценность» (value). Следующий список помогает найти правильные ответы на этот вопрос:

  • Какой(е) основной критерий успеха в продукте (WAU, продажи, посещения)? — на это нужно будет ориентироваться при оценке задачи;
  • Кто наш пользователь? Какие его цели и мотивы? — если это взрослая аудитория, которая сидит на оноклассниках, нужно разжевать все подробно, если это специалисты, нужно сфокусироваться на функционале;
  • Откуда приходит аудитория (как генерится) и куда уходит дальше? — без этой информации результат будет инородным в системе;
  • Какие задачи решает аудитория?
  • Что продукт делает хорошо? Что плохо? (график важно/хорошо, неважно плохо)
2

Работа с фидбеком

Когда в общих чертах все понятно, нужно углубиться в подробности и разобраться, для чего нужно создание/улучшение/изменение или переделка интерфейса. Для этого нужно понять потребности клиента. Подробный процесс как обработать обратную связь пользователей описан у Натальи Бабаевой, но если вкратце, то этот процесс делится на следующие этапы:
3
Аналитика
На основе данных по сервису и пользовательскому фидбеку находятся гипотезы, которые прорабатываются с аналитиком. Рекомендую статью «Как работать с аналитикой, если вы дизайнер».
4
Как приоритезировать задачи
Отдельно хотелось бы остановиться на пункте поиска сильных и слабых сторон интерфейса (график важно/хорошо, неважно/плохо). На нескольких проектах, с которыми я работал, хорошо зарекомендовал себя подход NPS (Net Promoter Score):
nps graph, nps graphic, net promoter score, user research graph
График NPS — это наглядный пример того, с чего нужно начать работу. Точки — ответы клиентов на вопросы по каждой отдельной части сервиса. В конце такого опроса будет видно, что важно и плохо проработано (красный цвет) — отсюда и начнется работа. А то, что не важно и реализовано хорошо (бледно-розовый) — получит наименьший приоритет.
5
Организация и постановка задач
Цель этого шага — организовать прозрачный процесс команды так, чтобы ни у кого не было вопросов: Что и зачем мы делаем? Кто уже сделал задачу и готов перейти к следующей? На каком этапе находится проект? Каков следующий шаг и т.д. Здесь большая часть процесса взята из методологии Scrum.
Работа описывается в системе управления проектами (Trello, Basecamp, activecollab, Google docs, Paper etc.), которая используется в компании. У меня она выглядит следующим образом:
Вся информация по проекту лежит в файле Info, итерации лежат в отдельных папках и имеют приоритет в виде цифр. В каждой задаче лежит полный комплект необходимых данных: дизайн, описания, тексты, верстка, разработка и т.д. Ни у кого не возникает вопросов, что где искать, откуда брать информацию и т.д. ни у разработки, ни у заказчика.
Если нужны тексты по каталогу, последняя версия верстки или дизайн лежат в папке проекта, ничего нигде не разбросано, доступ лежит только у пары ответственных людей. Никто не может без ведома перезалить информацию, что-то нечаянно удалить или изменить текст.
Сама итерация начинается с постановки проблемы, описания, зачем ее нужно решать, и само описание задачи. Прежде чем начать работу, не должно оставаться вопросов вроде «Для чего я это делаю?», «Какую пользу принесет сервису эта задача?», «Почему именно так, а не другим способом?».
Как выполнять задачи?
Когда задачи сформировались, прежде чем приступать к выполнению, нужно задать вопрос по каждой:

  • Какую проблему мы пытаемся решить?
  • Откуда мы знаем, что это реальная проблема?
  • Почему это важно решить?
  • Как мы поймем, что мы решили проблему?
Таким образом, в голове закрепится все, что было написано выше. Теперь, когда понятно, что делать, есть план и задачи, пора приступать к следующему шагу →
Часть 1
Часть 3
Часть 4
Часть 5