Потоки каркасного проектирования (Wireflows; «потоки схем») сочетают структурные схемы веб-страниц/интерфейсов (Wireframes) и блок-схемы (Flowcharts) для разработки опыта взаимодействия (User eXperience; UX — пользовательский опыт). Такой метод позволяет документировать поток работ (Workflow) и проверять дизайн интерфейсов в случае, когда необходимо проектировать несколько динамически изменяющихся страниц.
В области проектирования UX структурные схемы («каркасы») являются общеприменимыми компонентами, иллюстрирующими идеи макета на уровне страниц, в то время как блок-схемы используются для документирования сложных рабочих процессов и пользовательских задач. Но несмотря на то что две эти методики широко применимы, часто обе они недостаточно эффективны для передачи и воплощения проектных идей. В частности, при документировании мобильных, настольных и веб-приложений без уникальных интерфейсов, но с динамической сменой контента или макета на основе взаимодействия с пользователем.
В последние годы сформировался альтернативный метод проектирования UX — поток схем, решающий упомянутые проблемы. Он используется для показа дизайна страниц в контексте общих задач пользователя.
Структурная схема веб-страницы передает идеи макета, контента и дизайна на уровне страницы для сайтов и приложений, насчитывающих несколько — в основном статичных — страниц, но этот способ не слишком полезен для отображения сложных динамических процессов.
Блок-схемы используются для описания серверных процессов и пользовательских задач. Но для применения этой методики при разработке UX ей недостает учета контекста страницы — аспекта, сильно влияющего на опыт пользователя.
Wireflows как компонент потока работ
Определение: поток схем — новый формат проектных спецификаций, сочетающий разработку макета в «каркасном» стиле с упрощенной блок-схемой как способом представления интеракций с приложением/сайтом.
Этот поток схем, выполненный с низкой точностью, показывает простую пользовательскую задачу. Использование проектных эскизов экрана, а не абстрактных символов, применяемых в блок-схемах, фокусирует внимание разработчика на продукте, с которым пользователи будут взаимодействовать. Если с целью передачи подробных спецификаций дизайна потоки схем могут создаваться с высокой точностью, то выполненные с более низкой верностью отображения полезны для обсуждения и проектирования интеракций и потоков задач пользователей.
Потоки задач возникли как общепринятая практика среди команд разработчиков мобильных приложений, где каждый шаг на блок-схеме принято представлять в виде структурной схемы полноразмерного эскиза дизайна экрана. Из-за относительно небольшого размера мобильного дисплея, фактический дизайн страницы («каркас») легко заменить абстрактными символами блок-схем. Но область применения потоков не ограничивается простым документированием мобильных приложений и веб-сайтов — они также пригодны при разработке цифровых продуктов для десктопов, обычно для показа части экрана или веб-страницы, изменяющихся при интеракции с пользователем. Множество разработок для сайтов электронной коммерции — страницы оформления заказа, например — подходят под определение потока задач.
Зачем это нужно?
Блок-схемы и структурные схемы недостаточно хорошо документируют сложные приложения. Вводить новый формат спецификации — крайняя мера, поскольку многие заинтересованные не поймут, как его интерпретировать. Со старыми форматами они, как правило, знакомы. Тем не менее, потоки задач пользуются популярностью потому, что, во-первых, их легко изучить тем, кто раньше видел «каркасы» и блок-схемы, и во-вторых, потоки задач имеют достаточно преимуществ, чтобы преодолеть инерцию, которая в противном случае благоприятствует знакомым форматам.
Структурные схемы — отличный способ демонстрации макета, но они не слишком хорошо показывают взаимодействия. Особенно явно бедность «каркасов» проявляется при документировании макетов цифровых продуктов с обилием динамического контента, как мобильные- и онлайн-приложения. Структурные схемы полезны при документировании веб-сайтов/лендингов (или других цифровых продуктов) с большим числом дискретных, относительно статичных страниц/интерфейсов, где, нажавший кнопку или ссылку пользователь, как правило, переходит на совершенно другую страницу.
Однако многие современные интернет- и мобильные приложения имеют несколько общих страниц, но изменяют их контент и макет динамически при помощи AJAX (или других технологий), основываясь на взаимодействии пользователя с продуктом. Они могут варьироваться от продуктов для электронной коммерции, изменяющих показываемые на странице товары в зависимости от выбранного пользователем фильтра (цена, объем жесткого диска и т. д.), до сложных «творческих» и технических приложений, где общий макет интерфейса и содержащаяся информация могут значительно изменяться на основе взаимодействия с используемыми инструментами, режимами и другими параметрами управления.
В этих случаях структурные схемы не учитывают всех возможностей компоновки элементов интерфейса или правил изменения контента. Кроме того, типичные «каркасные» модели не документируют обратную связь, которую система предоставляет пользователям взаимодействия со страницей. (Обратная связь показывает, что действие распознано системой; она обладает решающим значением при создании хорошего UX. Это первая из «10 эвристик юзабилити» Якоба Нильсена ((Jakob Nielsen).)
Блок-схемы, с другой стороны — инструмент для исчерпывающего документирования сложных потоков задач и взаимодействий, производимых в несколько этапов или различными способами, но обычно не учитывающих контекст интеракции и его влияние на пользователей. Используя блок-схемы для документирования (и представления) проекта взаимодействия и этапов многоступенчатых пользовательских задач, можно упустить из виду информацию, указывающую на контекст восприятия веб-страницы и влияющую на успешность интеракции.
Применение потока схем для описания интеракции
Классический вариант использования потоков схем — фиксация того, как пользователь выполняет задачу с помощью цифрового продукта (например, «отправить сообщение кому-то в вашей сети» для социального приложения). На каждом этапе потока задач простая структурная схема или высокоточный макет дисплея демонстрируют интерфейс, доступный пользователю.
Стрелка обозначает конкретный компонент пользовательского интерфейса, в котором человек предпринимает действие (например, нажатие на кнопку, клик по ссылке и т. д.), и указывает на другом схематичном изображении результат интеракции.
Второй «узел» этого взаимодействия не должен быть отдельной страницей/интерфейсом; наоборот, он должен показывать ту же страницу с видимым результатом произошедшей интеракции — таким, как изменившийся контент, — или установленной обратной связи (например, появление поп-апа с формой подтверждения, изменение цвета, вывод сообщения об ошибке). Важно, что стрелки четко указывают на интерактивные «горячие точки» (hotspots), или цели (targets), которые ведут к следующему этапу процесса, тем самым уменьшая неопределенность в потоке задач. Для сложных приложений важно указывать триггерные точки, имеющие на одной странице несколько целей.
Этот простой поток схем показывает последовательность из нескольких «каркасов» интерфейса мобильного приложения для типичного процесса решения пользовательской задачи. В этом примере каждая структурная схема соответствует одной странице приложения вместо того, чтобы показывать различные страницы. На каждом этапе четко указываются «горячие точки», соединяющие пользователя со следующей стадией потока задач. Кроме того, поток задач демонстрирует визуальную обратную связь на втором этапе (когда у альбома, по названию которого кликнул пользователь, меняется фоновая подсветка для того, чтобы зарегистрировать действие).
Хотя потоки задач чаще используются при разработке мобильных приложений, они также полезны при документировании сложных рабочих процессов на десктопах. Так как показ структурной схемы полноэкранного рабочего стола для каждой стадии процесса занимает много экранного пространства, то, если большая часть проектируемого интерфейса остается неизменной на каждом этапе, можно демонстрировать только ту часть экрана, которая пошагово изменяется в процессе интеракции (например, диалоговое окно или фильтры) — этого достаточно для релевантного документирования изменяющихся частей интерфейса с одновременным предоставлением контекста.
Упрощенный поток задач веб-приложения для десктопа демонстрирует, что не все части проектируемого интерфейса должны отображаться на каждом этапе процесса. Из-за большого размера эскизов дизайна (для мониторов ПК) показывать полную страницу для каждого шага не нужно, если большая часть видимой информации не меняется. Тактический подход к показу проектировочных эскизов интерфейса позволяет визуализировать только элементы, которые меняются в результате ввода данных пользователем.
Хотя метод Wireflows подходит для показа потоков задач в приложениях и на динамических веб-сайтах, где содержание или макет страниц меняются от взаимодействий, он также применим для документирования задач потоков на традиционных статических веб-сайтах. Однако с последним нужна осторожность: большие изображения «каркаса» могут нарушить контекст документируемого процесса.
Использование потока схем для мозговых штурмов
Поток схем еще и налаживает контакт между участниками проектной команды — что особенно важно при динамичной разработке продукта.
На воркшопах по проектированию с участием больших межфункциональных команд строятся взаимная заинтересованность и общее понимание; в ходе этих мероприятий члены команды формируют идеи и записывают потоки задач, затем группа обсуждает возможные варианты, а ответственный за UX участник иллюстрирует каждый этап в стиле «потока схем» — дабы визуализировать пути решения пользовательской задачи (и документировать лучшие идеи).
При совместной разработке потоки задач не нужно доводить до визуального совершенства; напротив, здесь выигрывают эскизы, нарисованные «от руки», что позволяет быстро документировать идеи и фокусироваться на конкретных интеракциях.
Группа на семинаре «Результаты разработки UX» в рамках конференции Nielsen Norman Group, использует наклейки с изображением дисплея смартфона, маркеры и бумагу для совместной работы над потоком схем. Для этого достаточно доски, простой бумаги и карандашей.
Вывод
Поток схем — новый компонент проектирования UX, полезный в документировании потока задач и сложных интеракций для мобильных и онлайн-приложений. Он хорош для визуального представления динамических изменений одной или нескольких страниц внутри приложения, но работает хуже при фиксации потоков на большом количестве взаимосвязанных, относительно статичных страниц.
Потоки схем налаживают контакт и помогают в брейнсторминге командам, проектирующим пользовательские потоки задач и разрабатывающим концепции дизайна интерфейсов для каждого этапа процесса.
Высоких вам конверсий!
По материалам: nngroup.com
