Часть 1
Часть 3
Часть 4
Часть 5
5 шагов создания
интерфейса
Сбор требований, определение целей, организация
и постановка задач
← Назад
01
Сбор требований
и определение
целей
и определение
целей
Как понять суть продукта за 2 минуты
Первым шагом нужно понять суть продукта, который предстоит разработать. Есть классический шаблон из книги Мура Crossing the Chasm, который помогает объяснить суть продукта за 2 минуты (elevator test):
- Для (ключевой пользователь)
- Который (обозначение проблемы или возможности)
- (Название продукта) это (категория продукта)
- Который (ключевое преимущество, убедительная причина для покупки)
- В отличие от (ключевой прямой конкурент)
- Наш продукт (обозначение ключевого отличия)
Пример:
Для маркетинговых департаментов небольших компаний, у которых есть потребность создавать простую, но стильную email-рассылку для клиентов.
"Почтальон Печкин" — это веб-сервис, который позволяет на основе готовых шаблонов создать рассылку за 5 минут и при этом достичь высокого open rate. В отличие от MailChimp наш продукт заточен на особенности российского рынка и русского языка и стоит несравнимо дешевле.
"Почтальон Печкин" — это веб-сервис, который позволяет на основе готовых шаблонов создать рассылку за 5 минут и при этом достичь высокого open rate. В отличие от MailChimp наш продукт заточен на особенности российского рынка и русского языка и стоит несравнимо дешевле.
Как оценить результат
Хорошо организованный процесс, это когда каждый шаг по чуть-чуть приближает нас к основной цели. Принцип парето гласит, что нужно начать работу с 20%, которые принесут основной результат, а остальные 80% можно будет делать, когда продукт уже начнет приносить деньги (MVP). Задача, определить, где эти 20%, или другими словами, что для компании «Ценность» (value). Следующий список помогает найти правильные ответы на этот вопрос:
• Какой(е) основной критерий успеха в продукте (WAU, продажи, посещения)? — на это нужно будет ориентироваться при оценке задачи;
• Кто наш пользователь? Какие его цели и мотивы? — если это взрослая аудитория, которая сидит на оноклассниках, нужно разжевать все подробно, если это специалисты, нужно сфокусироваться на функционале;
• Откуда приходит аудитория (как генерится) и куда уходит дальше? — без этой информации результат будет инородным в системе;
• Какие задачи решает аудитория?
• Что продукт делает хорошо? Что плохо? (график важно/хорошо, неважно/плохо)
• Какой(е) основной критерий успеха в продукте (WAU, продажи, посещения)? — на это нужно будет ориентироваться при оценке задачи;
• Кто наш пользователь? Какие его цели и мотивы? — если это взрослая аудитория, которая сидит на оноклассниках, нужно разжевать все подробно, если это специалисты, нужно сфокусироваться на функционале;
• Откуда приходит аудитория (как генерится) и куда уходит дальше? — без этой информации результат будет инородным в системе;
• Какие задачи решает аудитория?
• Что продукт делает хорошо? Что плохо? (график важно/хорошо, неважно/плохо)
02
Работа
с фидбеком
с фидбеком
Когда в общих чертах все понятно, нужно углубиться в подробности и разобраться, для чего нужно создание/улучшение/изменение или переделка интерфейса. Для этого нужно понять потребности клиента. Подробный процесс как обработать обратную связь пользователей описан у Натальи Бабаевой, но если вкратце, то этот процесс делится на следующие этапы:
03
Аналитика
На основе данных по сервису и пользовательскому фидбеку находятся гипотезы, которые прорабатываются с аналитиком. Рекомендую статью «Как работать с аналитикой, если вы дизайнер».
04
Как
приоритезировать
задачи
приоритезировать
задачи
Отдельно хотелось бы остановиться на пункте поиска сильных и слабых сторон интерфейса (график важно/хорошо, неважно/плохо). На нескольких проектах, с которыми я работал, хорошо зарекомендовал себя подход NPS (Net Promoter Score):
График NPS — это наглядный пример того, с чего нужно начать работу. Точки — ответы клиентов на вопросы по каждой отдельной части сервиса. В конце такого опроса будет видно, что важно и плохо проработано (красный цвет) — отсюда и начнется работа. А то, что не важно и реализовано хорошо (бледно-розовый) — получит наименьший приоритет.
05
Организация
и постановка
задач
и постановка
задач
Цель этого шага — организовать прозрачный процесс команды так, чтобы ни у кого не было вопросов: Что и зачем мы делаем? Кто уже сделал задачу и готов перейти к следующей? На каком этапе находится проект? Каков следующий шаг и т.д. Здесь большая часть процесса взята из методологии Scrum.
Работа описывается в системе управления проектами (Trello, Basecamp, activecollab, Google docs, Paper etc.), которая используется в компании. У меня она выглядит следующим образом:
Вся информация по проекту лежит в файле Info, итерации лежат в отдельных папках и имеют приоритет в виде цифр. В каждой задаче лежит полный комплект необходимых данных: дизайн, описания, тексты, верстка, разработка и т.д. Ни у кого не возникает вопросов, что где искать, откуда брать информацию и т.д. ни у разработки, ни у заказчика.
Если нужны тексты по каталогу, последняя версия верстки или дизайн лежат в папке проекта, ничего нигде не разбросано, доступ лежит только у пары ответственных людей. Никто не может без ведома перезалить информацию, что-то нечаянно удалить или изменить текст.
Сама итерация начинается с постановки проблемы, описания, зачем ее нужно решать, и само описание задачи. Прежде чем начать работу, не должно оставаться вопросов вроде «Для чего я это делаю?», «Какую пользу принесет сервису эта задача?», «Почему именно так, а не другим способом?».
Как выполнять задачи?
Когда задачи сформировались, прежде чем приступать к выполнению, нужно задать вопрос по каждой:
- Какую проблему мы пытаемся решить?
- Откуда мы знаем, что это реальная проблема?
- Почему это важно решить?
- Как мы поймем, что мы решили проблему?
Таким образом, в голове закрепится все, что было написано выше. Теперь, когда понятно, что делать, есть план и задачи, пора приступать к следующему шагу →