7 шагов создания
интерфейса
Сбор требований, определение целей, организация
и постановка задач
01
Продукт
и его покупатель
Сбор требований, определение целей, исследование
Следующий набор вопросов мы используем как скрипт на первом интервью с клиентом. Он помогает понять задачу и продукт, с которым нам предстоит работать.
Задачи
1. Опишите задачу
2. Какой результат работы требуется от нас?

Следующий набор вопросов мы используем как скрипт на первом интервью с клиентом. Он помогает понять задачу и продукт, с которым нам предстоит работать.
1
Playfair is a transitional design. From the time of enlightenment in the late 18th century, the broad nib quills were replaced by pointed steel pens.
02
Работа
с фидбеком
Когда в общих чертах все понятно, нужно углубиться в подробности и разобраться, для чего нужно создание/улучшение/изменение или переделка интерфейса. Для этого нужно понять потребности клиента. Подробный процесс как обработать обратную связь пользователей описан у Натальи Бабаевой, но если вкратце, то этот процесс делится на следующие этапы:
03
Аналитика
На основе данных по сервису и пользовательскому фидбеку находятся гипотезы, которые прорабатываются с аналитиком. Рекомендую статью «Как работать с аналитикой, если вы дизайнер».
04
Как
приоритезировать
задачи
Отдельно хотелось бы остановиться на пункте поиска сильных и слабых сторон интерфейса (график важно/хорошо, неважно/плохо). На нескольких проектах, с которыми я работал, хорошо зарекомендовал себя подход NPS (Net Promoter Score):
nps graph, nps graphic, net promoter score, user research graph
График NPS — это наглядный пример того, с чего нужно начать работу. Точки — ответы клиентов на вопросы по каждой отдельной части сервиса. В конце такого опроса будет видно, что важно и плохо проработано (красный цвет) — отсюда и начнется работа. А то, что не важно и реализовано хорошо (бледно-розовый) — получит наименьший приоритет.
05
Организация
и постановка
задач
Цель этого шага — организовать прозрачный процесс команды так, чтобы ни у кого не было вопросов: Что и зачем мы делаем? Кто уже сделал задачу и готов перейти к следующей? На каком этапе находится проект? Каков следующий шаг и т.д. Здесь большая часть процесса взята из методологии Scrum.
Работа описывается в системе управления проектами (Trello, Basecamp, activecollab, Google docs, Paper etc.), которая используется в компании. У меня она выглядит следующим образом:
Вся информация по проекту лежит в файле Info, итерации лежат в отдельных папках и имеют приоритет в виде цифр. В каждой задаче лежит полный комплект необходимых данных: дизайн, описания, тексты, верстка, разработка и т.д. Ни у кого не возникает вопросов, что где искать, откуда брать информацию и т.д. ни у разработки, ни у заказчика.
Если нужны тексты по каталогу, последняя версия верстки или дизайн лежат в папке проекта, ничего нигде не разбросано, доступ лежит только у пары ответственных людей. Никто не может без ведома перезалить информацию, что-то нечаянно удалить или изменить текст.
Сама итерация начинается с постановки проблемы, описания, зачем ее нужно решать, и само описание задачи. Прежде чем начать работу, не должно оставаться вопросов вроде «Для чего я это делаю?», «Какую пользу принесет сервису эта задача?», «Почему именно так, а не другим способом?».
Как выполнять задачи?
Когда задачи сформировались, прежде чем приступать к выполнению, нужно задать вопрос по каждой:

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