Формирование требований к цифровому продукту
Написать эту статью меня подтолкнула публикация Александра Волкова “Теория ограничений в интерфейсах (кто убил старого графа?)” в которой автор описал метод помогающий разобраться в сценариях и расставить приоритеты. Я же хочу, коротко, рассмотреть другую проблему…
Проблема
Узким местом в процессе проектирования является определение требований к будущему продукту. Если неправильно определить потребности и цели, а затем cгенерировать идей как достичь этих ошибочных целей, то и результат будет соответствующим…
Сбор данных, определение целей и потребностей
Перед тем как приступить непосредственно к проектированию интерфейса продукта дизайнер собирает данные, без этого не возможно понять что же нужно получить на выходе. Сначала от клиента нужно получить бизнес-требования, только он понимает каких целей нужно достичь. Если клиент не понимает значит ему нужно в этом помочь, а для этого клиента нужно хорошенько опросить, то есть залезть в мозг и достать всю необходимую информацию. Очень часто, для того чтобы понять чего же клиент хочет, нужно разобраться в его бизнес-процессах и понять как же он зарабатывает деньги.
На следующем шаге нужно понять кто будет пользоваться продуктом, какие у них есть проблемы в данной предметной области, каких целей они хотят достичь и какие потребности нужно удовлетворить. Как правило, эти данные оформляются в виде Профиля персонажа пользователя. Такой способ анализа и представления информации является достаточно удобным потому, что это позволяет лучше сфокусироваться на целях пользователей.
Генерация идей, формирование требований
Далее нужно собрать все цели и потребности, изучить и найти способы их удовлетворения. Для этого проводится брейншторм (или другой способ генерации идей) с участием всей команды, а чтобы было еще веселей можно привлечь к этому процессу клиента. Для записи идей, и их сортировки, хорошо подходят программы типа XMind. С таким форматом представления информации удобно работать на следующих этапах, дополнять её, структурировать и т. д.
Первым делом выписываем цели и потребности пользователя.
Дальше отключаем критическое мышление и генерируем идеи как удовлетворить потребности будущих пользователей. Нужно записывать все идеи подряд, и чем больше идей тем лучше.
“Нет ничего опаснее идеи, если она у вас единственная.”
Эмиль Шартье, мыслитель
Главное на этом шаге повеселиться как следует, это помогает расслабить мозги и дать волю своему воображению. Лучше всего для этого подходят ассоциативные карты (Mind map).
Важное преимущество визуализации мозгового штурма состоит в том, что помимо сохранения ваших изначальных идей она помогает генерировать множество новых, которые, возможно, и не пришли бы в голову, если бы вы не использовали этот механизм, который позволяет удержать все ваши идеи и постоянно напоминает вам о них. Ваш мозг словно подает вам сигнал: «Ты получишь ровно столько идей, сколько сможешь эффективно использовать. Если ты не собираешь их системно, на большое количество не рассчитывай. Но если ты действительно что-то с ними делаешь, хотя бы просто записываешь для последующей оценки, тогда вот тебе, получай!
Из книги Дэвида Аллена “Как привести дела в порядок”
Следующий шаг является ключевым: нужно сфокусироваться на целях и потребностях, определить их значимость, найти и отобрать идеи которые решат проблемы пользователя, оценить важность для пользователей и расставить приоритеты.
На основе этой информации и составляется финальный список требований к будущему продукту.
Финальный список требований
В итоге нужно получить документ в котором описаны цели и потребности с отобранными сценариями. Для того чтобы сформировать список требований, который не будет содержать ничего лишнего, требования должны проходить фильтрацию по трем критериям. Требование должно:
1. Соответствовать целям проекта.
2. Быть выполнимым.
3. Не конфликтовать с другими требованиями.
Ниже представлен один из вариантов оформления требований для мобильного приложения с разбивкой по разделам и без расстановки приоритетов. Очень важно чтобы этот документ изучил и утвердил сам клиент, ведь он указывает направление дальнейших работ.
Отдельно хочу подчеркнуть, что мы получаем список требований который основан на данных доступных на момент исследований. После разработки, тестирования продукта и анализа полученных данных этот список может измениться, или вообще потерять актуальность, и это нормальный рабочий процесс. Ниже представлен пример описания требований для оффлайнового проекта.
Почему важно все описывать и держать информацию в документах? Да потому, что голова для того чтобы думать и решать задачи, а не для того чтобы держать в ней огромный массив данных.
Что дальше?
А дальше уже можно писать более подробные пользовательские сценарии, если это необходимо, или переходить сразу к прототипированию интерфейса будущего продукта.
Этот материал является частью онлайн-курса DIGITAL PRODUCT DESIGN
Я разработал курс, который дает методику проектирования сайтов, веб-сервисов и мобильных приложений, и будет полезен тем, кто уже работает как WEB Designer или UX/UI Designer, или ещё только учится, и хочет лучше разобраться в процессе и перейти на новый уровень. Инфо: https://hyperschool-digital-product-design.webflow.io/
