9 модуль конспект PD. Модуль Продуктовый дизайн и основы uxвведение
 Скачать 0.78 Mb.
|
|
Модуль 9. Продуктовый дизайн и основы UX Введение Вы уже прошли достаточно большой путь: проанализировали свою аудиторию; продумали экономику своего продукта; продумали ожидания от продукта и пути его развития. В этом модуле мы будем разбираться: как подготовиться к разработке продукта; как описать продукт понятно для разработчика; что такое продуктовый дизайн, как он закладывается и зачем он нужен. Поехали! Три стороны продукта Что представляет собой цифровой продукт? Цифровой продукт — это решение, нацеленное на принесение пользы заказчику и потребителю. Заказчик в ответ на заложенные им в продукт ресурсы, (например, такие, как деньги, время), ожидает их возврата в виде прибыли, нематериального профита, продаж или другого положительного для заказчика эффекта. Пользователь, потребитель тем или иным образом генерирует прибыль по продукту, который отвечает его интересам и ожиданиям. Успешный продукт балансирует между интересами заказчика и пользователя, развиваясь по стратегии вин-вин* («победа- победа»), когда и заказчик, и потребитель извлекают из продукта пользу. В этом балансе для цифрового продукта на равных как с заказчиком, так и потребителем участвует технологическая составляющая — конкретное решение, которое будет работать в конкретных условиях. __________________________________ * win–win game — беспроигрышная стратегия, стратегия сотрудничества Все три составляющие должны быть учтены и проанализированы на ранних стадиях разработки цифрового продукта. Описание продукта Описание цифрового продукта Цифровой продукт можно описать с трех точек зрения: визуальная составляющая, интерфейсы — как продукт выглядит; функциональная составляющая — как продукт работает; информационная архитектура — из каких систем и подсистем продукт состоит. Чтобы разработчикам было понятно, как работать, цифровой продукт необходимо описывать исходя именно из этих параметров. Продуктовый дизайн Продуктовый дизайн — простой или сложный? Продуктовый дизайн — это процесс создания и описания продукта, а именно: создание продукта, выполняющего задачи пользователя и заказчика, работающего в условиях определенной технической инфраструктуры; описание этого продукта с точки зрения визуального, функционального и структурного аспектов. UX (User eXperience) «Три слона» цифрового продукта Продуктовый дизайн Цифровой продукт основывается на: интересах заказчика; интересах пользователя; технической составляющей. Еще одной важной составляющей является UX. UX, User eXperience — пользовательский опыт, субъективные впечатления, формирующиеся у каждого потребителя до, во время и после взаимодействия с продуктом, и которые никак нельзя напрямую привить пользователю, кроме как опосредованно. Взаимоотношение продукта и пользовательского опыта можно продемонстрировать следующей схемой: Проектирование UX с помощью CJM (часть 1) Этап первый проектирования UX Продуктовый дизайн Цифровой продукт основывается на: UX субъективен и формируется у каждого пользователя под влиянием множества факторов, причем UX формируется у человека еще до того, как он станет пользователем. Начинать проектировать продукт стоит именно с пользовательского опыта. Какими инструментами можно пользоваться для практики? Lucidchart ; Microsoft Visio ; RealtimeBoard ; draw.io В качестве примера проектируем продукт «Подача заявки на кредит» Начинаем с UX, составляем CJM (Customer Journey Map) — карту путешествия клиента, опыт взаимодействия клиента и продукта, выраженный в графической форме или иллюстрации. Для этого определяем: Кто наш клиент? Его ключевые характеристики? В чем его задача? CJM строится на трех ключевых пластах информации: Что делает пользователь? Что делает сервис? Болевые точки — что происходит в момент взаимодействия пользователя с сервисом? Основные принципы отрисовки интерфейсов: итеративность (постепенность), постоянная синхронизация с заказчиком и коллегами по команде (это избавит от многих косяков), постоянная сверка с CJM. Проектирование UX с помощью CJM (часть 2) Как глазами пользователя выглядит желаемое взаимодействие с сервисом? Этап 1. «Вход в сервис»: клиент осознает, что ему нужен кредит именно в нашем сервисе; клиент находит, где можно заказать кредит. Этап 2. «Заполнение заявки»: указывает основную информацию о себе; отправляет заявку. Этап 3. «Ожидание ответа»: ожидает ответ. Этап 4. «Чтение ответа»: получает ответ; читает ответ на заявку. В качестве примера проектируем продукт «Подача заявки на кредит» Этап 1. «Вход в сервис»: внутренняя реклама о возможности заказать кредит; заметный переход на заказ кредита. Этап 2. «Заполнение заявки»: возможность заполнения анкеты и отображения прогресса ее заполнения; проверка ошибок заполнения заявки; отправка заявки владельцу сервиса; отображение прогресса заполнения анкеты; сохранение введенных в анкету данных; расположение на домене организации; предупредить пользователя о сроках ожидания. Этап 3. «Ожидание ответа»: отправка отбивок на e-mail; информирование о том, что пришел ответ; помощь пользователю по входу в сервис. Этап 4. «Чтение ответа»: отображение ответа; отображение советов. Болевые точки Этап 1. «Вход в сервис». Этап 2. «Заполнение заявки»: может стереться содержимое анкеты; могут возникнуть сомнения в анкете; пользователь хочет знать. сколько ждать ответа. Этап 3. «Ожидание ответа»: пользователь хочет знать результат. Этап 4. «Чтение ответа»: пользователь хочет понять, что делать дальше. Проектирование UX с помощью CJM (часть 3) Доработка CJM Этап 1. «Вход в сервис»: Работа с CJM циклична, информация по уровням и этапам постоянно обновляется и дополняется. Дополняем нашу CJM новым действием: Пользователь: указывает, сколько хочет денег и когда готов их вернуть. Болевые точки: Сколько денег может получить пользователь? Какой процент по кредиту пользователю придется вернуть? Что будет, если пользователь не сможет расплатиться? Прототипирование интерфейса Визуальная сопоставляющая продукта Интерфейс (interface) может быть не только визуальным, но и голосовым или тактильным, он может быть направлен на любые органы чувств пользователя с целью помочь ему в использовании продукта. Интерфейс должен формировать правильное впечатление не только о продукте, но и о бренде, который он представляет. Прототипирование интерфейса (часть 1) Отрисовка интерфейса Инструменты, которые можно использовать: Axure RP ; Figma ; Sketch ; Balsamiq ; Успешный цифровой продукт создается с учетом бизнес интересов заказчика, которые могут ставить противоречивые или трудновыполнимые задачи. Для нашего примера мы установим два ограничения: заявка должна оформляться исключительно в вебе (решение по ней также) и при заполнении заявки система должна показывать пользователю рекламные предложения. Интерфейс будет выглядеть более структурно, если при его проектировании использовать сетку: интерфейсные элементы будут находится на одном уровне, на одной линии и пользователю будет комфортнее работать с интерфейсом. При прототипировании интерфейса необходимо постоянно сверяться с данными CJM. В качестве дополнительного материала советуем вам прочитать §167. Метод прогрессивного джипега из руководства Артемия Лебедева. Прототипирование интерфейса (часть 2) Нюансы и детализация При проектировании интерфейса учитывайте, что если интерфейсные элементы находятся близко друг к другу, то они либо должны выполнять схожую функцию, либо нести схожий смысл, т.е. быть как-то связаны между собой — это базовый принцип восприятия интерфейса. Как правило, пользователь при просмотре материала, любой информации изучает ее по направлению из верхнего левого угла к правому нижнему — важно учитывать маршрут взгляда пользователя при проектировании интерфейса. Проектируя интерфейс, думайте о том, как облегчить пользователю выполнение задачи на каждом отрезке его пути. Прототипирование интерфейса (часть 3) Советы по проектированию интерфейса При проектировании интерфейса учитывайте следующие моменты: пользователю продукта в интерфейсе важны забота и польза, учитывайте это при проектировании; важно не загонять пользователя в тупик и узкие рамки, из которых он не сможет выбрать варианты или сделать шаг назад — нельзя лишать клиента чувства контроля над ситуацией. Описание функциональности продукта Функциональная составляющая продукта Важно не забывать про функциональную составляющую — про то, как будет работать продукт. Это важно: для разработчиков; для нас самих, для создателей продукта; для команды; для заказчика; для пользователя. Дополнительно предлагаем вам ознакомиться со статьей от опытного UX-дизайнера « Лайфхаки при проектировании » Функциональная архитектура Содержание функциональной архитектуры Описание функциональности — это сценарий поведения системы. Для описания функции по шагам проходим все действия, которые системе необходимо будет произвести для удовлетворения потребности пользователя, т.е. описываем алгоритм действий системы для выполнения определенной функции. Старайтесь учитывать все возможные сценарии и варианты выбора пользователя, чтобы подготовить систему к ответам. Плавательные дорожки (Swimlane) — диаграмма, на которой синхронно отражено взаимодействие нескольких участников, действующих сторон. В функциональной архитектуре должен быть описан четкий, понятный, формальный системный процесс, в отличие от CJM. В качестве дополнительного материала советуем вам ознакомиться с постером BPMN Функциональная архитектура Подведение итогов Мы уже сделали (и умеем): описали бо льшую часть продукта; поняли, как наш продукт взаимодействует с пользователем; поняли, как наш продукт выглядит и работает. Информационная архитектура (часть 1) Информационная архитектура: навигация Информационная архитектура описывает, каков «скелет» нашего цифрового продукта. Навигационная структура — иерархический список, отображающий подчиненность отдельных компонентов между собой и друг другу. В качестве дополнительного материала советуем вам прочитать статью « Разница между информационной архитектурой (IA) и навигацией » (на английском языке). Информационная архитектура (часть 2) Информационная архитектура: модели ER-диаграмма (модель «сущность–связь») — модель данных, обозначающая ключевые сущности, взаимодействие сущностей между собой и их связи. Информационная архитектура — описание структуры информации, заложенной в продукт. Заключение Перед отправкой разработчику Каким образом можно передавать наработки по продукту людям, которые будут его воплощать в жизнь? 1. Описать схематично всю информацию о продукте и показать разработчику. Но! В этом случае разработчик должен состоять в вашей команде; 2. Составить техническое задание, в котором максимально полно и системно сведены описания всех составляющих продукта. Но! Не составляйте ТЗ в самом начале разработки. В качестве дополнительного материала рекомендуем вам ознакомиться со статьей « Тонкости продуктового дизайна ». Бонусный материал от Алексея Бородкина В качестве бонусного материала предлагаем вам бета- версию Стандарта документации от Гильдии вольных проектировщиков, который пригоден для описания различных цифровых продуктов. Мы старались отвязать документацию от конкретных методологий и фреймворков, сделав ее максимально универсальной и простой в обращении. Поэтому она состоит из всего лишь двух ключевых документов — концепции, где описывается стратегическое видение продукта, и ТЗ, где описывается детальное решение. При этом и концепцию, и ТЗ поддерживают разные рабочие материалы, которые не имеют самостоятельной ценности, но служат ценным промежуточным артефактом для разных согласований и размышлений. Все это нашло свое место в Стандарте. Когда я буду описывать документы ниже, я буду приводить некую последовательность действий. На ваших проектах она может быть совершенно иной — помните, что документ является всего лишь инструментом для фиксации видения продукта на определенный момент времени, и применяться он может по-разному. Мыслите не стереотипами, мыслите стратегически — вот мой вам вечный совет. Несмотря на то, что мы сознательно дистанцируемся от методологий, данный комплект документации больше подходит для проекта по водопаду, чем по Agile. Да, та же самая разбивка по шардам в концепции берет свое начало именно из нашей Agile-методологии и в целом все документы весьма комфортно ложатся на гибкие рельсы, но все равно все это требует дополнительных разъяснений. Я полагаю, позже мы запилим отдельную редакцию документации под Agile (кому интересно сейчас - концепция там в целом останется той же, но ТЗ разделится на собственно ТЗ и спецификацию продукта и будет устроено чуть иначе). Повторюсь, криминальных расхождений нет, но нужна разъяснительная работа. Поскольку на момент описания работал на стороне заказной разработки, то и документация сильно деформирована в эту сторону. Когда речь идет про проработку внутреннего продукта, документы могут быть сильно проще и описан по-другому — скажем, ТЗ может быть представлено в формате Use Cases. Вполне возможно, со временем мы выпустим спец.редакцию Стандарта для своих продуктов, но это дело туманного будущего. В качестве иллюстрации документов мы выбрали фейковый проект про театры и спектакли. При составлении ключевых документов мы следовали следующим принципам составления ключевых документов: Системность. Документ должен описывать продукт во всей полноте; Однозначность. Не должно быть кривотолков; Достаточность. Документ должен достаточно полно ставить задачу для специалиста, кто работает с ним дальше; Отчуждаемость. Документ должен по возможности не требовать наличия толмача, который будет его разъяснять. Ясное дело, в реальной жизни проектировщика ни за что нельзя выкидывать за борт после окончания проектирования, но следование принципу отчуждаемости серьезно снижает затраты на сопровождение, инфа 100%. Советую послушать мой рассказ про проектную документацию с открытого собрания Гильдии. Там полтора часа, но тема раскрыта максимально полно. Возможны баги. Да, мы постарались вычитать все по максимуму — но будьте готовы к неточностям. Трассировку требований из концепции (читай: взаимосвязь требований с фичами и интеграциями) удобнее вести не руками, а в каком-нибудь Confluence. Мы это понимаем и отдаем должное автоматизации, но даем самое простое, бронебойное решение, которое легко реализовать хоть на чем. Сам стандарт Что ж, достаточно предисловий — давайте перейдем к Стандарту! Повторюсь, последовательность действий ниже условная — не воспринимайте ее как какой-то Стандарт; сейчас важно говорить про документы, а не про образ действий проектировщика и про роль проектировщика вообще (хотя и это интересно... но не сейчас). А На первом шаге мы встречаемся с клиентом, изучаем его задачи, пользователей и всякий технический фарш, который мы можем изучить. Этот этап условно можно назвать сбором аналитики и стратегическим проектированием. Попутно мы думаем над тем, какое решение выбрать, чтобы решить задачу. На этом этапе рождается первый ключевой документ — концепция Обратите внимание, что концепцию поддерживает старый-добрый CJM с персонами. Эту историю стандартизировать — себе дороже, но мы все равно ее проиллюстрировали. Ссылку на CJM ищите в концепции Б После утверждения концепции мы начинаем заниматься деталями. В частности, что мы прорабатываем: 1. Функциональную архитектуру. Пример 2. Навигационную структуру. Очень простой пример 3. Структуру данных. Пример 4. Интерфейсы. Куда ж без примера В реальном проекте в проработке интерфейсов мы бы дошли до дизайн- макетов со всеми красотами, но в нашем фейковом проекте ресурсов на это не хватило, так что ограничимся чертежами-вайрфреймами. В Когда все видение продукта утрамбовано, начинаем собирать это воедино в виде ТЗ, великого и ужасного. Тут я не буду разводить много слов, а просто отдам вам документ Отвечая на вопрос — почему Ворд, отвечу вот что. Гуглодоки прекрасны всем кроме того, что они не очень хорошо дружат с ОГРОМНЫМИ документами и, что еще более важно, с нумерацией заголовков (это критично в нашем формате). Это лечится костылями с плагинами, но итоговый результат все равно фиговый. Мы много с этим экспериментировали, ничего путного из Гуглодоков, увы, пока не вышло. Успехов! |