Когда кто-то сегодня говорит о UX, довольно часто он имеет в виду не проектирование пользовательского опыта, а визуальный дизайн. И это объяснимо. Сам по себе интерфейс (UI) уже представляет собой некий конечный продукт, и он прост для понимания.
Но проекты давно перестали быть настолько простыми, что их может делать один человек. Иногда встречаются гении, способные делать всё на хорошем уровне, но это почти такая же редкость, как, например, единороги.
Нам полезно вспомнить, что помогает команде сделать проект вовремя и на должном уровне. Мы попробуем описать ту работу, которая чаще всего скрыта от глаз внешнего наблюдателя, но которая обеспечивает достижение высокого качества проекта. И которая у нас проходит в рамках этапа проектирования.
Формат команды влияет на используемые инструменты
При работе над проектом у нас появляются артефакты (различные представления будущей системы), которые мы создаем и которые помогают лучше понять проект.
В начале работы мы знаем о будущей системе меньше всего, но постепенно наше представление о системе растет. И формируется представление о том, что должно быть реализовано. Выбор инструментов зависит от формата команды, работающей над проектом — это с одной стороны. Но с другой стороны, в зависимости от используемых инструментов меняется и характер работы команды, по-разному начинают звучать голоса ее участников.
Если мы возьмем различные артефакты (Vision, KPI, IA, прототипы, CJM, user stories, диаграммы и т. д.), то можем заметить, что они сфокусированы на задачах разных участников проекта. И поэтому, когда начинает казаться, что отдельные объекты можно было бы пропустить и не тратить на их создание время, то, вероятно, вы не целевая аудитория, для которой такой уровень абстракции и фокусировки ценен.
В зависимости от этапа разработки команда и заинтересованные лица должны иметь представление о разных аспектах системы, ее состояниях и поведении, и поэтому в работе мы используем разные артефакты.
В этой статье мы не можем охватить все возможные варианты документов и артефактов, которые создаются в процессе дизайна и разработки продукта, но назовем некоторые, которые мы считаем важными для обеспечения качества разрабатываемого интерфейса. На наш взгляд, эти документы способны обеспечить качественную коммуникацию в команде, улучшая эффективность продуктовой работы.
Дизайн для пользователей и дизайн для команды
Обычно, когда мы говорим о дизайне интерфейса, мы представляем себе конечного пользователя, аудиторию, которая будет пользоваться продуктом. Но есть еще одна немаловажная часть пользователей артефактов дизайна — это команда, сотрудники, обеспечивающие возможность реализации продукта от замысла до эксплуатации и поддержки.
Роли членов команды могут отличаться в зависимости от организации, но часто мы имеем дело с определенными типажами: это владельцы бизнеса, менеджеры по продукту, менеджеры проекта, тимлиды, разработчики, QA-инженеры, аналитики, дизайнеры, ресерчеры, копирайтеры.
И эффективная коммуникация всех участников команды становится залогом создания качественного продукта. Поэтому давайте посмотрим на некоторые артефакты в области проектирования, которые помогают нам в работе над дизайном продуктов.
Ключевые KPI / Дерево KPI
Когда у проекта есть понятные цели, по проекту проще двигаться. Мы знаем, к чему должны стремиться. Это помогает сфокусировать усилия всех участников процесса.
Хорошо, когда проект содержит несколько очевидных, измеряемых, иерархически определенных стратегических целей. Они могут делиться на более мелкие операционные и быть представлены в виде дерева KPI.
Формализованные цели позволяют повысить качество обсуждений и эффективность принимаемых проектных решений. Мы избавляемся от лишних споров и концентрируемся на главном при принятии решений. В каком-то смысле проект, для которого не сформулированы ключевые KPI, подобен кораблю без руля — он куда-то движется, но четкий курс не задан.
Что позволяет наличие ключевых KPI:
- с самого начала договориться о важном;
- мыслить о проекте в системе метрик, а не личного вкуса;
- фокусироваться на результате.
Стратегический план
Когда у нас есть сформулированные цели, выраженные через ключевые KPI, мы можем наметить приблизительный план того, как мы собираемся их достигнуть.
Редко случается, что дорога к цели очевидна. Чем сложнее проект, чем амбициознее цель, тем более сложным может быть путь.
Основная идея стратегического плана — это попытаться декомпозировать достижение цели на отдельные шаги, которые могут включать в себя как действия, так и дополнительные тактические задачи. В совокупности это дает представление о сложности достижения главной цели.
Стратегический план позволяет в целом посмотреть на предстоящий объем работ и корректировать ожидаемый результат соизмеримо работам из плана, которые уже выполнены.
Что позволяет наличие стратегического плана:
- видеть последовательность действий для достижения цели;
- понимать влияние разных факторов на общий результат.
Верхнеуровневый прототип
Верхнеуровневый прототип (концептуальный прототип) может быть первым ощутимым результатом работы дизайнера над проектом после большого объема аналитической и исследовательской работы. Он становится объектом внимания и вызывает интерес вовлеченных участников проекта.
Верхнеуровневый прототип дает общее видение продукта, его функций, логики взаимодействия с пользователями, отражает основные принципы построения интерфейса.
Верхнеуровневый прототип подготавливается на основе небольшого набора ключевых страниц/экранов, чтобы на их примере показать, как будет подаваться информация и как будут пользователи взаимодействовать с продуктом.
Что позволяет получить использование верхнеуровневого прототипа:
- раннее видение продукта;
- решение ключевых навигационных задач;
- приоритеты в интерфейсе;
- возможность раннего обсуждения отдельных продуктовых решений и перехода к тестированию продуктовых гипотез.
В конечном счете верхнеуровневый прототип можно описать даже словами. Например: «На главной странице будут наши товары по акции, ссылки на основные категории, корзину, способы оплаты и доставки».
Главная задача — получить раннюю обратную связь от бизнеса, экспертов и пользователей, поэтому можно не заморачиваться на технических аспектах реализации. Надо быть готовым к быстрому внесению изменений и созданию новых вариантов.
Сценарии
Сценарии позволяют лучшим образом отразить полноту пользовательских требований к системе. Мы исходим из того, что они должны описывать все возможности, которые есть у пользователя, и всё, что нужно в дальнейшем превратить в интерфейсы. Через сценарии мы обеспечиваем понимание действий пользователя и ожидаемого результата.
Менеджеры, владельцы продукта и другие специалисты могут по сценариям проверить полноту проектного решения: всё ли реализуется из того, что ожидалось.
Сценарии могут быть приоритизированы, что даст возможность в дальнейшем обратить на ключевые сценарии больше внимания. Сама приоритизация зависит от особенностей проекта и задач команды.
Важно помнить, что сценарии пишутся для людей. Они должны быть написаны понятным языком и не запутывать участников проекта. Можно использовать форматы User Story, JTBD или придумать что-то свое. Но главное, чтобы приоритет отдавался понятности и полноте покрытия возможностей продукта.
Информационная архитектура (IA)
Когда мы говорим об информационной архитектуре (IA), подразумеваем навигацию, карту сайта/приложения, таксономию. Работая над информационной архитектурой, мы лучше начинаем понимать составляющие проекта, объекты, из которых он будет состоять, их количество и взаимосвязь.
Информационная архитектура может быть представлена в виде иерархической диаграммы, на которой отражены основные структуры. Таким образом мы визуализируем основные взаимосвязи на сайте или в приложении, над которым работаем.
Проработка информационной архитектуры позволяет понять объем работ по проектированию и дизайну. И позволяет еще раз провалидировать полноту решения.
На этом этапе мы уже работаем с контентом проекта и можем задумываться над точностью формулировок. Большая часть названий и обозначений, которые мы зафиксируем в информационной архитектуре, перекочуют в проект.
Что позволяет получить использование IA:
- задать основную навигацию;
- проверить понятность структуры проекта и связей между его объектами;
- сделать объем проекта видимым.
В заключение
Работа по проектированию — это движение по пути повышения нашего знания о проекте. Различные артефакты проектирования становятся точками фокусировки команды и вовлечения пользователей для валидации гипотез и уточнения ожиданий.
Процесс проектирования подразумевает, что всё, что мы делаем, может меняться. Мы должны быть готовы возвращаться к уже созданным материалам, чтобы внести в них обоснованные уточнения. Это обеспечивает постоянное обогащение проекта новыми знаниями. И не завершается до этапа разработки.
И хотя каждый из нас обычно фокусируется только на вещах, которые интересны ему, существует много артефактов, которые помогают сделать проект хорошо. Работа по проектированию в итоге и сводится к тому, чтобы через разные материалы обеспечить надежный фундамент для визуального дизайна и физического воплощения проекта.
Источник: www.agima.ru
Продуктовый подход и артефакты «продакта»: who is who?
Давайте разберемся с таким понятием, как артефакт, которое имеет отношение к продуктовому подходу. С помощью артефактов — документов, в которые упакованы мини-продукты его работы при реализации инициативы, продвижении до получения бизнес-эффекта, владельцы продукта коммуницируют со всеми функциями, вовлеченными в работу над продуктом, и ускоряют эту реализацию.
Артефакт – это мини-продукт, документ, результат какой-либо деятельности.
У специалиста в любой профессии есть свои артефакты.
Например, когда художник учится рисовать, сначала он должен научиться получать артефакты – рисунок какого-то предмета, потом животного, потом человека и т.д..
Человек, изучающий иностранный язык, как правило, сначала получает артефакт – красиво написанные буквы алфавита, потом артефакт «слово», потом «текст» и т.д.
Артефактная модщель и продуктовый подход: что такое артефакт?
При работе над продуктом на каждой стадии фреймворка для управления инициативами Product owner производит какие-либо артефакты (это например, карточка инициативы (или продуктовый канвас), в который «упаковывается» инициатива, беклог гипотез, карта стейкхолдеров для взаимодействия с лицами, заинтересованными по той или иной причине в успехе вашего продукта и т.д.).
То есть Product owner должен уметь создавать набор этих артефактов.
Постепенно их создавая, продвигаясь по фреймворку, Product owner обеспечивает реализацию инициативы.
И именно артефакты помогают «продакту» это сделать.
С их помощью «продакт» коммуницирует со всеми функциями, вовлеченными работу над продуктом (ИТ, финансы и т.д.) — то есть через них. Это инструменты кросс-функционального взаимодействия.
Только создав определенные артефакты, «продакт» может продвигаться дальше.
Артефакты Product owner
Артефактное управление продуктом помогает продакту быстро продвигать свой продукт, то есть ускорить работу над ним.
Конечно, этой упаковке своей работы в артефакты надо поучиться, поначалу на это нужно будет тратить время.
Но потом вы поймете, насколько полезны артефакты как инструмент кросс-функционального взаимодействия.
Вы приходите к клиентам, бизнес-заказчикам, топам на УК и общаетесь через эти документами, с которыми по правилами игры все участники должны ознакомиться.
Артефакт – это ваш помощник и ваш щит.
Артефакты — помощники Product owner
Да, вам может показаться, что это в некотором роде бюрократия, но она новая, органичная, вас как «продакта» защищающая.
Рассмотрим простой фреймворк.
- В нем первый артефакт — это упаковка продукта, где, условно, описан клиент, проблема и решение.
- Есть артефакт — бэклог, список задач.
- Есть артефакт — презентация, где вы презентуете на демо кому-нибудь результаты продукта.
В тот или иной момент к вам приходит, например, и начинает говорить: «Я хочу, чтобы ты сделал мне то-то».
Вы его внимательно слушаете, но то, о чем говорит клиент, вы можете «положить» только в один из артефактов.
Вы спрашиваете себя: «То, что я слышу, это какая-то новая проблема? Это какое-то новое решение, это какой-то новый клиент? Да вроде нет. То, что он говорит, это какое-то новое действие? Точно, новое действие.
Кладу его в беклог. Дальше я должен буду понять, действие в беклоге перемещается вперед или вниз идет, оно более важное или менее важное» и т.д.
Т.е. итог любого взаимодействия с клиентом, стейкхолжером, бизнес-заказчиком Product owner помещает в конкретный артефакт.
Но для того, чтобы это делать, нужно уметь создавать эти артефакты, они должны у вас быть.
Источник: dzen.ru
