Флоу работы что это
Что строить в первую очередь: User Journey Map или User Flow?
(Мы продолжаем переводить цикл статей по UX/UI. Полную подборку можно найти в коллекции « Инструменты проектировщика»)
UX дизайн — комплексный процесс. Чтобы создавать по-настоящему удобные и полезные продукты, проектировщики используют разные инструменты на разных этапах. В этой статье мы разберем два типа материалов, которые помогают визуализировать опыт пользователя в продукте: карта пути пользователя (user journey map) и пользовательские сценарии (user flows).
Попробуем ответить на такие вопросы:
Для начала я объясню некоторые базовые термины, которые встретятся нам в этой статье.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Ищите системное погружение в тему? Загляните в блог для дизайнеров.
Что такое карты пути пользователя (User Journey Map)?
User Journey Map помогает зафиксировать пользовательский опыт во время взаимодействия с продуктом. Это некое визуализированное путешествие пользователя по продукту. User Journey Map — как журнал, в котором пользователь записывает свои чувства, неудачи и успехи.
В User Journey Map может быть несколько слоев, она не привязана к конкретному элементу в продукте, который отвечает за то или иное действие. User Journey Map даже может описывать, что делает система “за кулисами”, чтобы предоставить пользователю необходимую информацию. С другой стороны, User Journey Map — это больше про пользователя: она описывает его чувства, мысли, действия при взаимодействии с продуктом.
User Journey Map обычно линейны, так как описывают различные аспекты достижения конкретных задач.
Что такое пользовательские сценарии (User Flows)?
User flows (также известные как пользовательские сценарии, UX-сценарии, Wire, UI или IX сценарии) — это наглядные материалы, которые иллюстрируют весь путь пользователя в продукте целиком.
Изначально это были блок-схемы, но со временем они обросли разными визуальными элементами — вайрфреймами, скетчами и визуализацией жестов.
Сейчас user flow — это гибрид классической блок-схемы и элементов визуального интерфейса. В основе user flow лежат задачи, которые выполняет пользователь, а также возможные альтернативные исходы.
Можете прочесть пару моих статей об UX-сценариях (user flow):
User Flows in Sketch — Step by Step Guide to Create Them Quickly
Sketch is a powerful tool to create digital products. You may be surprised but it is also ideal to prepare some other…
If one picture is worth thousand words, then UI flows are worth a thousand pictures. Even if you created outstanding…
Отличия
User flows (также известные как пользовательские сценарии, UX-сценарии, Wire, UI или IX сценарии) — это наглядные материалы, которые иллюстрируют весь путь пользователя в продукте целиком.
Изначально это были блок-схемы, но со временем они обросли разными визуальными элементами — вайрфреймами, скетчами и визуализацией жестов.
Сейчас user flow — это гибрид классической блок-схемы и элементов визуального интерфейса. В основе user flow лежат задачи, которые выполняет пользователь, а также возможные альтернативные исходы.
Можете прочесть пару моих статей об UX-сценариях (user flow):
Отличия
В основе сценария — User Flow — как правило, лежит порядок действий, которые должен выполнить пользователь. User Flow помогает понять, все ли процессы в продукте имеют логическое завершение. Глядя на user flow, команда может сразу понять, в чем суть решения, которое предлагает продукт.
User flow могут быть нелинейными — в них есть точки принятия решений, пути, режимы и петли, при помощи которых мы иллюстрируем все возможные взаимодействия с продуктом.
Обычно в User Flow мы не делаем акцент ни на ощущения пользователя, ни на множество возможных уровней решения. Основная задача сценариев — показать процесс работы с продуктом.
User Journey Map больше ориентированы на пользовательский опыт клиента. Они выявляют проблемные точки и моменты радости. User Journey Map может описывать разные аспекты решения: например, не только мобильное приложение, но и работу системы на сервере.
Есть определенные правила построения User Flow (наверное потому, что сценарии эволюционировали из блок-схем). А вот что касается User Journey Map, единого рецепта тут нет. Можно найти в интернете кучу примеров карт и все они будут очень разные.
Как использовать User Flow в процессе дизайна
Меня очень часто спрашивают: с чего начать? С User Journey Map или с User Flow? Не буду оригинальным: все зависит от ситуации 🙂
Если у вас уже есть готовое решение, тогда, мне кажется, сначала стоит создать User Flow. На основании этих сценариев вы сможете построить хорошую User Journey Map, которая в свою очередь поможет выявить проблемные места и устранить их. Не менее важно выявить приятные моменты на пути пользователя, чтобы сохранить их и при возможности усилить.
Когда вы создаете решение с нуля, собирайте требования, узнавайте потребности пользователей и пишите пользовательские истории. В первую очередь думайте о том, что должен сделать пользователь, чтобы выполнить стоящую перед ним задачу. На базе этой информации вы создадите карту User Journey Map. В эту версию карты не обязательно включать вайрфреймы: рассматривайте ее как начальный план, который вы детализируете на последующих этапах. Уже потом, когда вы создадите вайрфреймы и макеты, можно будет обратиться к UX Flows: они помогут понять, правильный ли путь вы предлагаете пользователям и как его можно улучшить.
Короче говоря:
Я рекомендую начинать с User Flow, если у вас на руках готовое решение. Если вы запускаете новый проект, начните с построения User Journey Map и уже потом усиливайте ее при помощи User Flow.
Еще я обнаружил, что User Flow очень эффективны, когда дело касается общения с клиентом. Людям, не связанным с дизайном, проще понять формат блок-схемы. А вот User Journey Map они читают с трудом — поэтому бывает рискованно показывать ее клиентам на ранних этапах и без объяснений.
Как создавать User Journey Map и User Flow
При создании этих материалов я люблю пользоваться разными полезными инструментами.
Когда нужно накидать User Journey Map прямо во время встречи или мозгового штурма, я предпочитаю стикеры. Их можно легко менять местами, выбрасывать ненужные и заменять новыми.
Цифровую карту User Journey Map проще всего создавать в электронной таблице.
Что касается User Flows, то в режиме реального времени их проще всего создавать на белой доске. Но после встречи/мозгового штурма определенно стоит красиво оформить наработки в каком-нибудь цифровом инструменте. Я использую для этого Sketch — он на удивление хорошо подходит для создания различных UX материалов. Чтобы сделать процесс еще эффективнее, я создал инструмент для создания UX-сценариев — SQUID. Благодаря библиотеке, я могу за считанные минуты создавать стилизованные пользовательские сценарии.
Флоу что это такое означает
Флоу — это очередной англицизм, прижившийся в русскоязычной рэп-культуре. В принципе, совершенно закономерно: — слово краткое и интригующее. К тому же, flow что значит в переводе «текучесть, поток», многогранное понятие.
Оно относится к тому, как преподносит себя исполнитель публике, как ему удаётся «раскачать» зал. Флоу заставляет воспринимать текст слов как неоспоримую истину. Ритмичность, качественная читка, динамичность, варьирование скорости для акцентирования внимания, или следуя за битом, плюс харизматичность исполнителя (группы) и всё вышеперечисленное — это в совокупности и можно определить как флоу. Если попробовать уместить более-менее адекватный перевод в одно слово, что означает суть термина, следуя правилу краткость сами знаете, чья сестра, это будет «подача». 
Дисклеймер. При определении флоу исполнителей использованы собственные субъективные ощущения от восприятия их творчества. Суждения не претендуют на абсолютную истину, и вполне вероятно, могут не совпадать с мнением читателей.
Исторический экскурс Флоу
Флоу считается новым атрибутом качественного исполнителя, хотя на самом деле это абсолютно не так. Даже у самых первых рэперов, часто в основе мелодии и текстов своих песен черпавших вдохновение у англоязычных коллег и в окружающей действительности, подача была на высоком уровне.
Просто на заре хип-хопа и рэпа в России термина флоу не существовало. Без него была очевидна и бешеная популярность, и умение так завести публику, чтобы она выкрикивала слова вместе с исполнителями. Распавшаяся уже группа «Мальчишник», в ядре которой был триумвират Дэн-Дельфин-Мутабор плюс Олень, качала не только залы.
В каждом дворе начала 90-х годов прошлого века их скандальные тексты подростки знали наизусть. Что примечательно, и учить их было не нужно — энергетика подачи передавалась даже через динамики кассетных магнитофонов. Они были в числе первопроходцев формата, контрастно отличающегося от гремевших тогда же, не к ночи будут помянуты, «Ласкового мая» и «Миража».
Ещё один родоначальник русскоязычного хип-хопа — Влад Валов (он же ШЕFF), по его собственному определению, обладает «ядерным» флоу. Вполне обоснованно — он умеет зарифмовать свои мысли и прочитать их публике таким образом, что понятны не только слова, но и смысловой посыл.
У Децла и Тимати, при всей их популярности, подача как таковая далека не только от ядерной, но и от тротилового эквивалента. Флоу пытались повысить эпатированием публики. Конечно, ещё вложенными в раскрутку средствами и частотой прокручивания композиций по тв и радио.
Что означает — флоу был в рэп-культуре всегда. Просто его, как отдельное достоинство исполнителя (группы), не выносили за грани творчества.
Современные законодатели flow
Рэп за прошедшее стал новым популярным направлением в русской музыке, привлекая возможностью, не обладая классическим образованием и выдающимся вокалом, поделиться своими мыслями с публикой. Исполнителей этого жанра стало очень много — «все теперь МС» (Оксимирон). Поэтому на передовую в борьбе за популярность выходит флоу.
Кто-то делает ставку на техничность читки, её динамичность, кто-то упирает на загруженность текста смыслами и артистизм.Различные рейтинги в интернете, скрупулёзно подсчитывающие количество подписчиков у исполнителей, или проводя голосование, субъективны по определению. Но практически во всех встречается Гуф, Скриптонит, Нойз МС, уже упомянутый Тимати.
Особенной техничностью отличается Oксимирон, видимо, сказывается англоязычное обучение. Впитанная ритмика американского и британского рэпа перенесена в собственное творчество, и, хотя и вызывает неоднозначную реакцию у коллег по цеху, в целом у публики пользуется успехом.
Появление в рейтингах певицы Бьянки может показаться полным бредом. Но, кроме того, что девушек вообще в хип-хопе мало, у неё явно оригинальный стиль. К произнесению текстов она добавляет танцы и беззастенчиво эксплуатирует сексуальность образа.
Скоростной, или fast-flow, когда слова речитатива произносятся быстро, набирает обороты. При этом исполнителю важно не просто быстро-быстро произнести текст, но и сделать его разборчивым. Исполнение требует техничности, и умения виртуозно владеть чувством ритма, задавая качающий бит (при а капельном выступлении), или следуя установленному. Встречается понятие вялое флоу. Его суть понятна — подача не вызывает у публики яркого эмоционального отклика.
Тренировка flow
Флоу, как подача, в наличии у каждого хип-хопера или рэпера по определению. Вопрос в качестве и формате. Наверное, нем смысла подробно объяснять важность в баттлах. Соперник с отточенной манерой подачи заведомо имеет преимущество.
Главная проблема в том, как сделать её эффективной. Первый этап — проанализировать множество успешных выступлений. Но одного лишь бездумного копирования мало. Его обязательно заметят соперники и слушатели, и не преминут поставить в упрёк.
Второй этап, в идеале — создание оригинального флоу. Что значит, собственного авторского и исполнительского стиля. Талант — ни купить, ни выменять, ни украсть. Зато над flow можно, и, если уж цель обозначена как популярность, нужно работать.
Если этой задачи нет — дальше можно не читать, лучше послушайте исполнителя с импонирующим лично вам стилем, и прекратите мучить слушателей «закосами» под рэп.
В сети встречаются ценные советы, как улучшить флоу: отшлифовать дикцию, тренировать дыхалку для произнесения длинных текстов без одышки и пауз, добавление артистизма. Подача станет лучше. Другой вопрос, что это произойдёт путём упражнений, бессонных ночей и каждодневных терзаний, проведённых в поисках своего стиля в подаче. А что вы хотели? Качественный рэп — это труд, а отстойного суррогата уже и так много. 
Дерзкая птица структур: development flow
Если вы на пальцах не можете описать структуру вашей организации, отдела, вообще работы — значит, вы делаете это неэффективно.
Эффективность и прозрачность это никогда не одно и то же. Можно прозрачно делать неэффективные вещи, а эффективно делать вещи непрозрачные.
Построение структуры работы это сложный, индивидуальный процесс, с налётом дерзости. Потому что нужна не только смелость и рефлексия («мы работаем неэффективно, почему?»), но и умение делать изящные нагромождения.
Изящные нагромождения — залог создания структур. Кажется «нам не надо, работаем и ладно, зачем нам лишние слои», но на деле — один продуманный слой поднимет вашу работу на новый уровень. Это нагромождение, но оно изящно. Что-то вроде dependency injection или использование фотошопа вместо рисования красками.
Если сейчас вы подумали «нет, у нас всё эффективно» — даже не надейтесь. Неэффективно. Даже если у вас абсолютно, совершенно, никогда вообще не создаётся заторов в работе — то вы просто живёте в иллюзиях. Это невозможно. Эффективность это грёбанный процесс, а не данность. И конкретный человек должен этот процесс обеспечивать. А другие — поддерживать. Не потому, что «так сказали», а потому что всем будет хорошо — все будут работать так, как им комфортно, и быть эффективными.
Короче, наше детище изящных нагромождений мы называем «дерзкой птицей структур» или «development flow». Сейчас мы его опишем, и еще съедим пару ваших собак в спорах.
Зачем он нужен
Development Flow призван для исполнения 4 обязательств:
Система
Система состоит из элементов, элементы разные, и по ним идёт «ток» — рабочий процесс. В ИТ «ток» это код, дизайн, документы и прочие штуки, с которыми и над которыми мы работаем.
Системы бывают отсутствующими
Если вы не знаете, на каком этапе вашего Частного флоу сейчас находитесь (например, «разработка фичи»), и не знаете, каким этапом вы являетесь в Общем флоу (например, четвёртым, после Владельца продукта, Скрам мастера и Дизайнера), и какой этап должен пойти за вами, какие у него критерии возврата, и много всяких мелочей еще…
Или если вы знаете, но для вашей работы с вами рядом должен сидеть Проектный менеджер, и напоминать, чем именно в эту самую секунду вам следует заниматься (не отрывайся от монитора, тут же следящие программы)…
Или если вы просто чувствуете, что вы неэффективны…
… то скорее всего, у вас нет Системы.
Система бывают неработающими правильно
Не всё золото, что блестит. Не всё V12, что под капотом. И главное — не каждый двигатель работает правильно, даже если едет (привет, любимый автопром).
Важно иметь правильно работающую систему, потому что это наша уверенность. В своей работе, в работе всей системы. Вы сразу будете находить проблемы, большинство которых сможете решить.
У работающего двигателя есть звук. Он ритмичный, приятный. Если там есть проблема, это слышно чуткому уху мастера. Скрип, чихания, нарушение ритма, стук. Это медленно или быстро уничтожает двигатель, и «машина бизнеса» ломается именно тогда, когда ты взял долларовую ипотеку на трёшку внутри кольца.
В системе работы людей эти шумы — нарушение сроков, недовольства, утечка кадров, пониженный тонус сотрудников, перекидывание проблем на соседний отдел — и много всего другого. Хороший управленец ходит по офису с растопыренными сверхчувственными локаторами вместо ушей. Ему известен надвигающийся шторм, он чувствует, что упало давление. Он слышит все короткие вздохи, и замечает отведённые глаза. Он и есть Система.
Development flow: система
Система DF подразумевает два раздела — Общий флоу (функционирование системы в целом), и Частный флоу (функционирование отдельных её частей).
Общий флоу
Система состоит из элементов, объединенных в структуру для достижения намеченной цели.
Цель в ИТ — выпуск продукта в нужное время, нужного качества. Элементы системы — участники процесса: Владелец продукта, Проектный менеджер, Скрам мастер, Разработчик, Дизайнер, Тестировщик, Техписатель… Всё это элементы, и не все они присутствуют постоянно. Иногда роли объединяются. Нужно выделить свои элементы.
Нужно выделить свои элементы. Записать их, и стрелочкой нарисовать свой первый флоу. Это называется Общий флоу.
Владелец → СМ → Дизайнер, Разработчик → Тестировщик → Техписатель
Задача — объединить элементы в структуру и показать, какие профессиональные взаимодействия возможны. Непрофессиональные — о том, что дизайнер и владелец продукта живут вместе, не надо. Надо только роли. Владелец не должен взаимодействовать с Дизайнером или Разработчиком. Только Скрам мастер. Только. Скрам мастер.
Когда мы выделяем взаимодействия, эти стрелочки, мы должны показать, что даёт Первый, и что в качестве обратной связи возвращает ему Второй. Так система начинает жить.
Владелец → даёт описание задачи → СМ
СМ её переформулирует и для Владельца, и для остальных. Оценка задачи — приблизительная — выстроится сама собой. Но задача СМ — из простого описания, применив изящное нагромождение, сделать ДОСТАТОЧНОЕ_ОПИСАНИЕ. Части этого ДО он и будет обсуждать и распределять с командой.
СМ → даёт части ДО → Дизайнеру и Разработчику
ДО включает в себя схему, все возможные её состояния, и много другого (не хочу пока нагромождать). Каждый получает свою часть. Не всегда одновременно. Обычно Дизайнер опережает Разработчика на один спринт.
Дизайнер и Разработчик на ежедневном митинге в качестве обратной связи с СМ возвращает ему своё видение задачи. Убеждаемся, что всё понимаем одинаково. Это занимает 25-28 секунд. А спасает часы и недели.
Разработчик → после своего частного флоу (об этом позже), передаёт код → Тестировщику
Разработчик отдаёт код, Тестировщик смотрит в свою часть ДО, и отрабатывает своё флоу. Обратная связь Тестировщика — для СМ → «позитивная», то есть то, как он понимает задачу, а для Разработчика → «негативная» — только в том случае, если сломано.
Разработчик не имеет представления, что его код тестируют, до тех пор, пока не появляется проблем.
Думаю, что Общий флоу правильно формулировать так. Первый отдаёт Второму, Второй обрабатывает, возвращает «позитивную» или «негативную» Обратную связь, двигает дальше в Общем флоу. Позитивная обратная связь — убеждённость, что всё работает как задумано; негативная обратная связь — показывает, где и что пошло не так.
Частный флоу
В этой статье я в общих чертах разберу частные флоу Владельца, СМ и Разработчика, в качестве примера. Если вам будет интересно, потом выложу остальные наработки.
Владелец
Главная цель
Формулировка задачи (backlog ← описание), читать обратную связь
Что дальше
Когда задачи сформулированы Владельцем, СМ их описывает → приводит к Достаточному_Описанию.
Обратная связь от
СМ переописывает задачу и обсуждает с быстро Владельцем ключевые вехи, в тч сроки.
Взаимодействует с
СМ
Главная цель
Принять задачу, привести её в вид Достаточного_Описания, оценить задачи, распределить, читать обратную связь
Что дальше
Распределяет задачи сотрудникам
Обратная связь от
Дизайнер, Разработчик, Тестировщик, Техписатель
Взаимодействует с
Владелец, Дизайнер, Разработчик, Тестировщик, Техписатель
Разработчик
Главная цель
Разработка фичей и исправление багов. В Общем флоу ему приходят задачи от СМ, и при помощи своей профессиональной деятельности, он их реализует (git flow, rebase flow, feature flow и др).
Что дальше
Он может вносить предложения по модификации, обсуждая их с СМ и Дизайнером.
Обратная связь от
СМ, Дизайнера, Тестировщика
Взаимодействует с
СМ, Дизайнером, (важно — он не может порождать взаимодействие с Тестировщиком)
(В таком описании схема мне не очень нравится, вот эта моя презентация с другим описанием, и мне с ним приятнее работать. Но я же исследую варианты, пробую, оттачиваю, и тут получилось так. )
В сухом остатке
Development Flow решает такие задачи:
Очень много работы у Скрам Мастера (Тимлид, CTO). Но так и должно быть, он — главный тягач в этом подходе.
Оставайтесь в неведении или создавайте дерзкие структур. Мы предлагает свою птицу, но она большая и это только часть, в первом приближении. Нам нужно больше всяких кейсов. Потому я прошу вас — вешайте на меня всех собак, хочется разгрызть тему получше.
(Многое пришлось вырезать, чтобы хоть немного ужать размер статьи. Из-за этого что-то мог упустить, но буду оперативно исправляться, пишите.)
User flow: как создаются популярные приложения и сайты
Я – Максим Скворцов, UX/UI-дизайнер Omega-R, международной компании по разработке и интеграции IT-решений. Я занимаюсь проектированием и визуализацией интерфейсов мобильных и веб-приложений.
На базе своего опыта в сфере информационных технологий и экспертизы компании хочу поделиться своим видением и подходом к применению одного из инструментов проектирования дизайна – user flow. Почему его используют и почему он является ценным помощником для дизайнера? Как может выглядеть user flow и как его создать?
Что такое user flow?
Ситуация: Вы нашли новое приложение, которое обещает делать именно то, что вы хотите, и вы нетерпеливо нажимаете кнопку загрузки. Через мгновение приложение запускается, и вы готовы приступить к работе. Но сначала вам приходится зарегистрировать учетную запись, затем дать приложению разрешение на доступ к вашему местоположению и отправлять вам push-уведомления, после этого необходимо пролистать весь туториал, соглашение об использовании персональных данных и т.д. Горькая правда заключается в том, что пользователь при таком взаимодействии скорее закроет и удалит приложение, каким бы функциональным оно ни было. Вот почему так важно оптимизировать путь пользователя в приложении с помощью user flow.
User flow – это визуальное представление последовательности действий, которые пользователь выполняет для достижения своей цели. Может охватывать как какую-то отдельную функцию, так и полностью весь продукт.
Чтобы составить последовательность, необходимо провести исследование и ответить на три базовых вопроса:
User flow – это история о пользователе
User flow позволяет взглянуть на взаимодействие пользователя и приложения глазами пользователя.
Если полноценные сайты предоставляют достаточно места для творчества, то разработка мобильных приложений всегда заставляет искать баланс между функциональностью и удобством использования. С одной стороны, пользователи должны легко получать доступ к наиболее важным функциям с главного экрана приложения без множества дополнительных шагов, легко нажимая на большие кнопки. С другой стороны, когда мы говорим о приложениях, речь идет не только о кнопках.
Допустим, вы создаете приложение для музыкального плеера. С одной стороны, вы хотите, чтобы пользователь мог воспроизводить свои любимые песни одним касанием. С другой стороны, им нужен способ определять избранные треки, искать новую музыку (возможно, в нескольких местах), контролировать громкость и настраивать эквалайзер, сортировать музыку, шаффлить список, читать биографию исполнителя, делать покупки и иметь под рукой все остальные функции плеера. Пользователю захочется делиться рекомендациями и плейлистами в соцсетях и видеть, что слушают их друзья.
Если пользователь сёрфит в интернет-магазине во время прослушивания плейлиста и решает пропустить текущий трек, ему не нужно закрывать магазин и переходить обратно через несколько шагов меню — доступ к этой кнопке пропуска должен находиться на том же экране.
Создать максимально функциональное приложение не так сложно, но собрать все это в наиболее привлекательном и комфортном для пользователя виде – гораздо более сложная задача. Если компания-разработчик не справилась с ней и не создала приложение интуитивным, то оно так и останется лежать невостребованным в сторах. Пользователю всегда легче загрузить более понятное приложение, чем тратить время на чтение мануалов и туториалов или без конца бродить по нему в поисках смысла.
Роль дизайнера
Представьте, что вы работаете над продуктом в одной команде, где есть Project Manager, Backend- и Web-разработчики. Предположим, есть даже какое-то техническое задание от заказчика, которое написано достаточно подробно и добротно. Осталось просто взять и сделать продукт.
Что же должен сделать дизайнер? Если судить по ожидаемому результату – нарисовать все нужные экраны так, чтобы конечный продукт был удобным и красивым, и отдать разработчикам.
В целом – да. Но есть подводная часть айсберга. Там скрыто множество вещей, о которых мало кто задумывается. Все мы любим удобные и интуитивно понятные интерфейсы, любим, когда все работает логично и результат любого взаимодействия предсказуем. И чтобы все это было, нужно тщательно проработать каждую деталь.
Как раз для этого нужен user flow – он поможет определить пути достижения пользователями цели, вычислить позитивные и негативные сценарии на выбранном пути достижения цели наших потенциальных пользователей. Он дает возможность понять, все ли процессы в продукте имеют логическое завершение и выстроены эффективно, так, чтобы пользователь тратил минимум времени для достижения цели.
Важно: чем больше проблема и чем больше функций, тем больше сценариев необходимо проработать.
Таким образом, user flow помогает исключить распространенную ошибку, когда создают список требуемых функций и на основе них просто проектируют интерфейсы. Такой подход, разумеется, возможен. Но это может привести к тому, что сценарии взаимодействия с интерфейсом заставят пользователя проходить слишком много шагов для выполнения простых операций.
Ценность для продуктовой команды
User flow помогает на верхнем уровне согласовывать с заказчиком сценарии для работы продукта или функционала. Особенно тогда, когда у заказчиков нет конкретных и детализированных требований (когда они сами плохо понимают, чего они хотят). В этом случае user flow может дать какое-то направление для заказчиков, и они уже подскажут, в каких местах они хотели бы изменить логику, предоставив свою обратную связь – либо в виде комментария, либо самостоятельно скорректировав текущую схему. Несмотря на то что создание user flow кажется сложным и длительным по времени процессом, он помогает исключить множества ошибок при разработке продукта. С его помощью, как говорится, «медленно запрягают, но быстро едут».
Для PM на основании user flow удобно заводить задачи для разработчиков – достаточно очевидно и прозрачно, какие изменения необходимо внести в текущую логику или какие новые функции будут добавлены.
Тестировщики могут готовить use cases (тесты) и чек-листы, поскольку они в удобном формате демонстрируют пользовательские сценарии.
User flow очень полезен для команды, особенно когда состав команды достаточно большой – не нужно каждому отдельно объяснять логику работы. Таким образом, user flow вовлекает в процесс проектирования заказчика, мотивирует команду, направляет весь рабочие процессы в единое русло, поскольку каждый член команды видит картинку в целом.
Ценность для заказчика
Пользователь – это почти всегда тот, кто покупает или пользуется продуктом или услугой или потенциально готов это сделать. От того, насколько комфортно выстроен этот процесс, зависит его лояльность пользователя. Каким бы способом он ни приобретал продукт или услугу – в офисе, по звонку, с выездом специалиста на дом, через сайт, через приложение – путь приобретения и пользования должен быть максимально простым.
Что касается сайтов и мобильных приложений, user flow – это то, как пользователь будет перемещаться по контенту (тексту, картинкам, аудио, видео). User flow включает в себя определение приоритетов в требованиях к контенту, барьеров в навигации и поиск наиболее быстрых и безболезненных маршрутов к целевому действию. По сути user flow непосредственно связан с воронкой конверсии, и IT-компания, использующая user flow, автоматически разрабатывает эффективную воронку конверсии или оптимизирует существующую воронку.
Итогом оказанной ему помощи в достижению цели, воплощенной в дизайне благодаря user flow, является счастливый и заинтересованный пользователь. А счастливый и заинтересованный пользователь означает большее количество проведенного времени в приложении или на сайте, более низкие показатели отказов, повышенные коэффициенты конверсии и улучшенный пользовательский опыт работы.
Таким образом, user flow напрямую влияет на успех сайта или мобильного приложения и прибыль заказчика. В центре дизайна становится пользователь, и это полностью совпадает с принципом клиентоориентированности бизнеса.
Как всё выглядит?
Я нигде не видел четко прописанного стандарта, в соответствии с которым происходит проектирование user flow. Представление user flow может быть разным и зависит от того, насколько детально надо все проработать. Важно достичь вашей цели как дизайнера – чтобы заказчик и продуктовая команда понимали, каким образом пользователь получит доступ к той или иной функции, где они будут находиться и как они будут работать.
User flow может быть представлен в виде комбинаций из:
Пусть нашим пользователем будет молодая мама, цель которой – купить многофункциональный кухонный комбайн. Один из сценариев последовательности шагов может выглядеть следующим образом:
Task flow
Task flow – это простое представление того, что пользователь делает на каждом шаге для выполнения цели или задачи. По сути это классическая блок-схема, определяющая эту последовательность.
В данной схеме не отражены условности и прочие вопросы, которые необходимо проработать. А что будет, если по результатам поиска ничего не нашлось? А что будет, если оплата не прошла? Здесь представлены лишь общие этапы, которые могут предполагать множество действий: например, поиск может быть расширенным с множеством фильтров, путь оплаты зависит от выбора инструмента оплаты и т.д.
Для составления схемы можно пользоваться списком необходимых и достаточных элементов из классических блок-схем, представленных на картинке, или использовать стандарт BPMN – он ориентирован как на технических специалистов, так и на бизнес-пользователей.
Wire flow (lo-fi)
Wire flow – это объединение блок-схемы и wireframes. Wireframe – это низкодетализированный набросок дизайна экрана, упор в котором делается не на визуальную составляющую, а на расположение элементов, структуру и содержание экрана.
В wire flow вместо элементов блок-схемы представлены схематичные макеты экранов, с которыми взаимодействует пользователь на пути достижения цели. Не нужно зацикливаться на визуальных деталях и отрисовывать каждую кнопку и иконку. Чаще всего акцент делается на элементах навигации в дизайне каждой отдельной страницы.
Wire flows особенно удобны при создании мобильных экранов: относительно небольшие размеры мобильных экранов легко используются для замены более абстрактных элементов блок-схем. Wire flows комфортны для формирования и уточнения технического задания, но едва ли подходят для этапа тестирования.
Пример такой схемы:
Screen flow (hi-fi)
Здесь речь идет о детально проработанных экранах, которые понятны как пользователям, так и разработчикам. Обычно делается акцент на элементах навигации и некоторых нюансах поведения. Его можно использовать как регламентирующий документ для утверждения дизайна макетов.
Screen flow можно по сути назвать прототипом, если ему добавить интерактивность. Его особенностью является высокая точность или идеальное пиксельное соответствие: в нем учитывается физический размер экрана и представляются все визуальные и типографические детали продукта. Элементы screen flow – это фактически макеты экранов готового приложения.
Заказчик приложения может быть приятно удивлен скоростью разработки, когда вы покажете ему screen flow, и может подумать, что разработка близка к завершению. Мы, как правило, заранее сообщаем заказчику, что за screen flow не стоит никакого кода, но наличие screen flow дает заказчику гарантию, что за отлично подготовленными UX и UI последует не менее идеальный код.
Пример screen flow:
Ниже представлен вариант, как может в совокупности выглядеть гибрид классических блок-схем, схематичных изображений и финальных макетов.
Как вы понимаете, самым затратным по времени является самый проработанный – screen flow. Именно он выглядит как рабочее приложение и готов к интерактивному прототипированию, тестированию, новым итерациям, утверждению и передаче разработчикам. Для командного проектирования user flow существует множество инструментов автоматизации, среди которых Overflow, Miro, Flowmapp и другие.
Таким образом, user flow, охватывая весь продукт, систематизирует и структурирует процесс его создания, максимально ориентирует продуктовую команду на потребности пользователя и на их единое понимание, позволяет создать предельно понятный и интуитивный продукт с помощью анализа пользовательских сценариев. Всё это не только существенно ускоряет скорость разработки, но и углубляет взаимодействие с заказчиком. User flow заставляет IT-компанию всегда думать о бизнес-требованиях заказчика, чтобы создавать приложение более эффективным и успешным, чем это возможно в рамках выделенного бюджета и времени без применения user flow.