Поток схем как компонент разработки пользовательского опыта

Posted on by riasevastopol

Потоки каркасного проектирования (Wireflows; «потоки схем») сочетают структурные схемы веб-страниц/интерфейсов (Wireframes) и блок-схемы (Flowcharts) для разработки опыта сотрудничества (User eXperience; UX — пользовательский опыт). Таковой способ разрешает документировать поток работ (Workflow) и контролировать дизайн интерфейсов при, в то время, когда нужно проектировать пара динамически изменяющихся страниц.

В области проектирования UX структурные схемы («каркасы») являются общеприменимыми компонентами, иллюстрирующими идеи макета на уровне страниц, тогда как блок-схемы употребляются для документирования сложных рабочих пользовательских задач и процессов. Но не обращая внимания на то что две эти методики обширно применимы, довольно часто обе они не хватает действенны для воплощения и передачи проектных идей. В частности, при документировании мобильных, настольных и веб-приложений без неповторимых интерфейсов, но с динамической сменой контента либо макета на базе сотрудничества с пользователем.

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

Структурная схема веб-страницы передает идеи макета, дизайна и контента на уровне страницы для приложений и сайтов, насчитывающих пара — по большей части статичных — страниц, но данный метод не через чур нужен для отображения сложных динамических процессов.Поток схем как компонент разработки пользовательского опыта

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

Просматривайте кроме этого: Проектирование пользовательского опыта: мега-экскурсовод по навигации сайта

Wireflows как компонент потока работ

Определение: поток схем — новый формат проектных спецификаций, сочетающий разработку макета в «каркасном» стиле с упрощенной блок-схемой как методом представления интеракций с приложением/сайтом.

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

Потоки задач появились как общепринятая практика среди команд разработчиков мобильных приложений, где любой ход на блок-схеме принято воображать в виде структурной схемы полноразмерного эскиза дизайна экрана. Из-за довольно маленького размера мобильного дисплея, фактический дизайн страницы («каркас») легко заменить абстрактными знаками блок-схем.

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

Просматривайте кроме этого: Проектирование пользовательского опыта: стратегия task flows

Для чего это необходимо?

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

Однако, потоки задач пользуются популярностью вследствие того что, во-первых, их легко изучить тем, кто раньше видел «блок» и каркасы-схемы, и во-вторых, потоки задач имеют хватает преимуществ, дабы преодолеть инерцию, которая в другом случае помогает привычным форматам.

Структурные схемы — хороший метод демонстрации макета, но они не через чур прекрасно показывают сотрудничества. Особенно очевидно бедность «каркасов» проявляется при документировании макетов цифровых продуктов с обилием динамического контента, как мобильные- и онлайн-приложения. Структурные схемы нужны при документировании веб-сайтов/лендингов (или других цифровых продуктов) с солидным числом дискретных, довольно статичных страниц/интерфейсов, где, надавивший кнопку либо ссылку пользователь, в большинстве случаев, переходит на совсем другую страницу.

Но многие современные мобильные- приложения и интернет имеют пара неспециализированных страниц, но изменяют их макет и контент динамически при помощи AJAX (или других разработок), основываясь на сотрудничестве пользователя с продуктом. Они смогут варьироваться от продуктов для электронной коммерции, изменяющих показываемые на странице товары в зависимости от выбранного пользователем фильтра (цена, количество твёрдого диска и т. д.), до сложных «творческих» и технических приложений, где неспециализированный макет интерфейса и содержащаяся информация смогут существенно изменяться на базе сотрудничества с применяемыми инструментами, другими параметрами и режимами управления.

В этих обстоятельствах структурные схемы не учитывают всех возможностей компоновки элементов интерфейса либо правил трансформации контента. Помимо этого, обычные «каркасные» модели не документируют обратную сообщение, которую совокупность предоставляет пользователям сотрудничества со страницей. (Обратная сообщение говорит о том, что воздействие выявлено совокупностью; она владеет важным значением при создании хорошего UX. Это первая из «10 эвристик юзабилити» Якоба Нильсена ((Jakob Nielsen).)

Блок-схемы, иначе — инструмент для исчерпывающего документирования непростых потоков взаимодействий и задач, создаваемых в пара этапов либо разными методами, но в большинстве случаев не учитывающих контекст интеракции и его авторитет на пользователей. Применяя блок-схемы для документирования (и этапов) проекта и представления взаимодействия многоступенчатых пользовательских задач, возможно потерять из виду данные, говорящую о контексте восприятия веб-страницы и воздействующую на успешность интеракции.

Просматривайте кроме этого: Из-за чего проектировать пользовательский опыт (UX) так сложно?

Использование потока схем для описания интеракции

Хороший вариант применения потоков схем — фиксация того, как пользователь делает задачу посредством цифрового продукта (к примеру, «послать сообщение кому-то в вашей сети» для социального приложения). На каждом этапе потока задач несложная структурная схема либо точный макет дисплея демонстрируют интерфейс, дешёвый пользователю.

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

Второй «узел» этого сотрудничества не должен быть отдельной страницей/интерфейсом; напротив, он обязан показывать ту же страницу с видимым результатом случившейся интеракции — таким, как изменившийся контент, — либо установленной обратной связи (к примеру, появление поп-апа с формой подтверждения, изменение цвета, вывод сообщения об неточности). Принципиально важно, что стрелки четко показывают на интерактивные «тёплые точки» (hotspots), либо цели (targets), каковые ведут к следующему этапу процесса, тем самым уменьшая неопределенность в потоке задач. Для сложных приложений принципиально важно показывать триггерные точки, имеющие на одной странице пара целей.

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

Помимо этого, поток задач демонстрирует визуальную обратную сообщение на втором этапе (в то время, когда у альбома, по заглавию которого кликнул пользователь, изменяется фоновая подсветка чтобы зарегистрировать воздействие).

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

Упрощенный поток задач веб-приложения для десктопа демонстрирует, что не все части проектируемого интерфейса должны отображаться на каждом этапе процесса. Из-за громадного размера эскизов дизайна (для мониторов ПК) показывать полную страницу для каждого шага не требуется, в случае если большинство видимой информации не изменяется. Тактический подход к показу проектировочных эскизов интерфейса разрешает визуализировать лишь элементы, каковые изменяются в следствии ввода данных пользователем.

Не смотря на то, что способ Wireflows подходит для показа потоков задач в приложениях и на динамических веб-сайтах, где содержание либо макет страниц изменяются от сотрудничеств, он кроме этого применим для документирования задач потоков на классических статических веб-сайтах. Но с последним нужна осторожность: громадные изображения «каркаса» смогут нарушить контекст документируемого процесса.

Просматривайте кроме этого: Проектирование пользовательского опыта посредством модели вертикалей

Применение потока схем для мозговых штурмов

Поток схем еще и налаживает контакт между участниками проектной команды — что особенно принципиально важно при динамичной разработке продукта.

На воркшопах по проектированию с участием громадных межфункциональных команд строятся общее понимание и взаимная заинтересованность; на протяжении этих мероприятий члены команды формируют идеи и записывают потоки задач, после этого несколько обсуждает вероятные варианты, а важный за UX участник иллюстрирует любой этап в стиле «потока схем» — чтобы визуализировать пути ответа пользовательской задачи (и документировать лучшие идеи).

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

Несколько на семинаре «Результаты разработки UX» в рамках конференции Nielsen Norman Group, применяет наклейки с изображением дисплея смартфона, маркеры и бумагу для совместной работы над потоком схем. Для этого хватает доски, карандашей и простой бумаги.

Просматривайте кроме этого: Как решать UX-проблемы в команде: «пчелиные» сессии

Вывод

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

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

Высоких вам конверсий!

По данным: nngroup.com

Случайные статьи:

3. Веб-разработка. Серверная разработка ч.1 | Технострим


Подборка похожих статей:

riasevastopol

More Posts