[pullquote align=right]
Браден Ковиц, глава Google Ventures Design Studio для GigaOM
[/pullquote]Одна из самых больших ошибок для продуктовой команды это путать дизайн, который хорошо выглядит, с дизайном, который хорошо работает. Это простая ошибка, но она может иметь серьезные последствия – если ваш продукт работает не очень хорошо, никого не заинтересует как он выглядит.
Лучший способ, который я нашел для борьбы с такой путаницей, это техника, которую называют «story-centered design» (дизайн через историю, исторецентрический дизайн). Идея в том, чтобы создать серию повествовательных сценариев использования вашего продукта, которые иллюстрировали бы каждый шаг на пути приключения пользователя в нем. Я использовал эту технику с десятками стартапов и он всегда помогал командам перейти от поверхностных визуальных деталей к принятию лучших решений в отношении того, что действительно важно – к тому, как их продукт работает.
Дизайн не должен быть чертежом
Я заметил, что команды часто работают с UI-дизайном так, будто это чертеж – показывая где каждый элемент располагается на плане. Каждый экран показывает как продукт может выглядеть в различных ситуациях, но экраны никак не связаны. Проблема в том, что создавая дизайн таким образом, вы понимаете только как продукт выглядит. Вы не сосредотачиваетесь на том, как продукт работает, вы не представляете, как потребители взаимодействуют с ним. Так что когда команда смотрит на дизайн как на чертеж, она серьезно ограничивает способность воспринимать интерактивность продукта.
Лучшие продуктовые дизайнеры используют вращающийся вокруг истории дизайн. Они начинают с создания истории, которая показывает как потребители взаимодействуют с продуктом, и только после этого создают экраны так, как будто рассказывают эту историю взаимодействия.
Процесс проектирования истории
В исторецентрическом дизайне команда смотрит на работу как на последовательность десятков мокапов, которые функционируют как кадры в киноленте (фотография ниже). Дизайнеры представляют каждую фразу, которую видит потребитель, каждое действие, которое он совершает, и каждый экран, который генерирует система в ответ. Дизайнер следует за пользователем с самого начала и до конца, показывая как дизайн поддерживает его на каждом шаге. Я научил много стартапов такому подходу и видел как техника работает для мобильных приложений, маркетинговых сайтов, аналитических дашбордов, промышленных IT-систем и так далее.
Вот пример того, о чем я говорю:
Для инженеров это должно звучать знакомо. Основа «дизайна вокруг истории» такая же, как и в разработке через тестирование. Только вместо написания тестов для проверки кода мы создаем истории для проверки дизайнеров. Как и в случае разработки через тестирование, дизайн через историю может невероятным образом повлиять на скорость разработки и качество продукта.
Рассказ истории шаг за шагом
- Зарисовка истории
Начните дизайн вашего проекта с рисования с вашей командой на доске пользовательских взаимодействий. Нарисуйте кучу маленьких квадратов на вашей доске, затем создайте историю, заполняя каждый из них небольшими взаимодействиями пользователя с вашим продуктом. Соедините критические кусочки. Покажите все точки, на которые тапает или кликает пользователь (опять же, как на картинке выше). Создание займет некоторое время, но если команда придет к согласию по поводу истории, то весь остальной процесс разработки дизайна будет идти намного быстрее, с меньшим количеством ошибок и повторов. - Смените инструменты
Большинство инструментов для дизайна были сделаны для создания постеров или книг, так что они не подходят для разработки интерактивных историй с десятками фреймов. Откажитесь от Photoshop-а на ранней стадии, выберите Keynote, OmniGraffle или Fireworks, которые поддерживают множество страниц и помогают вам сосредоточиться на создании сквозного потока. - Никогда не критикуйте один экран
Это большой красный флаг, если кто-то посылает вам для просмотра один или два мокапа. Убедитесь, что ваша команда всегда видит всю историю. Ели вы сами представляете дизайн кому-то, распечатайте каждый экран на листах бумаге и выложите их по порядку в комнате. Таким образом каждый увидит общую картину и детали на каждом экране. Если вам надо послать дизайн по почте, запишите скринкаст, который связывает все ваши экраны в единую историю.
Почему исторецентрический дизайн работает так хорошо
Он имитирует пользовательский опыт
Сфокусированный на истории дизайн заставляет нас пройти с клиентами каждый шаг. Это дает всей команде (дизайнерам, инженерам, директору) систему для принятия дизайнерских решений основанных на том, как люди по-настоящему будут взаимодействовать с продуктом.
Команда замечает проблемы раньше
Так как история добавляет в ваше видение новое измерение (время), она подчеркивает все виды проектных ошибок, которые команды часто пропускают при просмотре своего продукта просто в виде набора экранов. С историей проще заметить, когда подсказка не соответствует ожиданиям. Интерфейсы с лишними шагами и тупиками замечаются и исправляются быстрее. Все маленькие детали складываются в лучшее юзабилити и вовлеченность.
Он ставит цели дизайна на первое место
Когда команда начинает создавать историю, это заставляет каждого прийти к соглашению о целях дизайна до того, как перейти к проработке деталей. Это полезно, потому что после того, как дизайнер потратит часы на создание детализированных мокапов интерфейсов, критика будет уже целенаправленно сфокусирована на том, выполняют ли они установленные и понятные цели.
Это наука!
Ну, своего рода. Продумывание того, как потребитель идет от первоначального триггера (такого как е-мейл или пуш-уведомление) к конечной цели необходимо, согласно модели БиДжей Фогга. История дает возможность проще проверить, все ли элементы у вас на месте для поощрения пользователя на его пути.
Она ускоряет все остальное
Историю можно повторно использовать в других частях команды. Мокапы, созданные для демонстрации истории, можно быстро и просто собрать в интерактивный прототип для изучения действий пользователя. Ту же историю можно использовать для создания аналитической воронки, которая поможет узнать, что на самом деле пользователи делают в реальном продукте. А QA-команда сможет использовать историю для проверки каждого нового релиза.