01

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

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

02

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

03

На основе данных по сервису и пользовательскому фидбеку находятся гипотезы, которые прорабатываются с аналитиком. Рекомендую статью «Как работать с аналитикой, если вы дизайнер».

04

Отдельно хотелось бы остановиться на пункте поиска сильных и слабых сторон интерфейса (график важно/хорошо, неважно/плохо). На нескольких проектах, с которыми я работал, хорошо зарекомендовал себя подход NPS (Net Promoter Score):

График NPS — это наглядный пример того, с чего нужно начать работу. Точки — ответы клиентов на вопросы по каждой отдельной части сервиса. В конце такого опроса будет видно, что важно и плохо проработано (красный цвет) — отсюда и начнется работа. А то, что не важно и реализовано хорошо (бледно-розовый) — получит наименьший приоритет.

05

Цель этого шага — организовать прозрачный процесс команды так, чтобы ни у кого не было вопросов: Что и зачем мы делаем? Кто уже сделал задачу и готов перейти к следующей? На каком этапе находится проект? Каков следующий шаг и т.д. Здесь большая часть процесса взята из методологии Scrum.

Работа описывается в системе управления проектами (Trello, Basecamp, activecollab, Google docs, Paper etc.), которая используется в компании. У меня она выглядит следующим образом:

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

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

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

Таким образом, в голове закрепится все, что было написано выше. Теперь, когда понятно, что делать, есть план и задачи, пора приступать к следующему шагу →