Руководство по процессу проектирования UX и документации

Опубликовано: 2016-10-21

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

Как описывает защитник Lean UX Джефф Готельф в статье для Smashing Magazine, толстые результаты, созданные просто для дальнейшего использования в отношении пользовательского опыта, устаревают почти сразу после их создания. В современном мире Lean и Agile в центре внимания должен быть опыт, а не результаты. Независимо от того, выбираете ли вы упрощенные или более подробные процессы, важно, чтобы ваша документация помогала продвинуть проект вперед (а не была просто индикатором запаздывания).

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

Мы выбрали методы, которые, по нашему мнению, работают лучше всего, но не стесняйтесь выбирать только те, которые работают.

Как они все связаны

Когда дело доходит до документации по дизайну продукта, теория и практика — две большие разницы. Мы все знаем основные принципы дизайна, ориентированного на пользователя. Мы признаем различные методы исследования, этап прототипирования, а также процесс документирования методов в нашей богатой методологической среде. Однако вы, вероятно, часто задаете себе вопрос: «Как все это работает на практике?»


Источник изображения: Процесс проектирования .

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

  1. На начальном этапе определения продукта вы проводите мозговой штурм продукта и того, как реализовать проект на самом высоком уровне со всеми необходимыми заинтересованными сторонами. Это может привести к плану запуска проекта, простому холсту и куче действительно ранних концептуальных карт и макетов того, что вы хотите построить.
  2. Приступая к исследованиям , ваша команда уточняет предположения и заполняет пробелы. Этот этап варьируется в зависимости от сложности продукта, сроков, ресурсов, уровня существующих знаний и многих других факторов. В целом, однако, полезно проводить конкурентный и рыночный анализ и проводить опросы клиентов. Если у вас есть существующий продукт, просмотр аналитики, эвристики, контента, контекста продукта и пользовательских тестов также весьма полезен.
  3. При анализе маркетинговые данные о продукте, собранные до сих пор, служат основой для персонажей, карт опыта и документов с требованиями, таких как электронные таблицы приоритетных функций и матрицы пользовательских задач. На этом этапе определение продукта, приоритеты продукта и план продукта определены и готовы к более формальным результатам проектирования. Как обсуждалось в Руководстве по процессу проектирования и документации UX, эскизы и диаграммы, вероятно, также постоянно генерируются в течение этого времени.
  4. На основе этих результатов могут быть созданы сценарии, концептуальные карты и макеты, ведущие к этапу проектирования . Общая документация включает эскизы, каркасы, прототипы, схемы потоков задач и спецификации дизайна. Например, конкурентный анализ и персонажи, созданные в ходе исследований и анализа , используются в макетах, концептуальных картах и ​​сценариях. В свою очередь, эти части влияют на промежуточные и продвинутые результаты, такие как каркасы, раскадровки и подробные макеты. Некоторые компании рассматривают фазы исследования, анализа и проектирования как один большой процесс, как вы можете видеть на этом обзорном графике.
  5. Во время реализации код и ресурсы дизайна собираются для создания продукта, который соответствует спецификациям дизайна продукта.
  6. После запуска реального продукта данные обратной связи, такие как запросы в службу поддержки, отчеты об ошибках и другие аналитические данные, продолжают улучшать продукт посредством последующих итераций и обновлений. Когда предложение находится в рабочем режиме, данные должны постоянно генерироваться и отслеживаться в форме аналитики и отчетов, чтобы обеспечить постоянный успех.
  7. Непрерывное улучшение продукта на основе данных достигается за счет измерения и итерации предложения в производственной среде с использованием панелей мониторинга производительности и аналитики.

Руководящие принципы

Теперь, когда вы увидели, как каждый этап связан друг с другом, давайте рассмотрим некоторые полезные принципы продвижения продукта по каждому этапу. Мы объясним, как использовать дизайн-спринты, чтобы процесс развивался со временем, а не определялся только в начале.


Источник изображения: Источник: дизайн, ориентированный на пользователя .

Подобно своему аналогу программного обеспечения Agile, спринты дизайна — это спринты продолжительностью 1-3 недели, которые сосредоточены на решении конкретных проблем с продуктом и дизайном. По словам Алока Джейна, руководителя отдела UX в 3Pillar, тремя ключевыми элементами планирования спринтов являются совместная работа, уменьшение трения при передаче и командная направленность . Короче говоря, ваша документация — это совместная работа, которая всегда должна быть сосредоточена на самом пользователе. Поскольку вы быстро перемещаетесь между этапами, вы создаете импульс и минимизируете потери. Что еще более важно, вы решаете более мелкие проблемы, что позволяет больше исследовать и идти на риск.

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

1. Понимание продукта

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


Источник изображения: Достичь общего понимания .

Согласно журналу Smashing Magazine, вам необходимо включить действия, отвечающие бизнес-требованиям, требованиям пользователей и наилучшее дизайнерское решение, чтобы удовлетворить и то, и другое. Ключевое слово здесь — «деятельность», потому что, хотя такие документы, как Business Model Canvas и Lean Canvas, важны, вам нужно активизировать заинтересованные стороны — в противном случае у вас просто будет куча дорогих людей, говорящих о вещах, которые все уже знают. Эти виды деятельности эффективны и предполагают сотрудничество:

  • Интервью с заинтересованными сторонами . Используя этот шаблон, вы можете попросить каждого члена команды взять интервью у 3 заинтересованных сторон. Как продукт заставит клиентов чувствовать себя? Что они должны делать? Записывая, как заинтересованные лица думают, что клиенты будут думать, чувствовать и делать, вы устанавливаете эталон для сравнения с тестированием удобства использования и пользовательским анализом.
  • Семинары по требованиям — соберите вместе заинтересованные стороны, обсудите план проекта и начните обсуждение того, как концепции учитываются в продукте и
    технические требования. Вы можете начать с пустой канвы бизнес-модели или канвы бережливого производства и завершить ее вместе с командой.
  • Безумные восьмерки — возьмите несколько маркеров и попросите всех набросать 8 идей продукта или функции за 5 минут. Попросите всех оценить каждую идею и
    вы начнете видеть тенденции и предпочтения. На самом деле это был шаг 2 в процессе редизайна Google Ventures. Для получения дополнительных идей ознакомьтесь с этим списком мозгового штурма.

После того, как вы заложили основу, поговорите и протестируйте с множеством пользователей, чтобы у вас были реальные полевые данные для исследований и анализа. Марсин Тредер, генеральный директор UXPin, углубился в разработку клиентов и тестирование удобства использования после определения проблемы и масштаба. Когда UXPin был всего лишь инструментом для бумажного прототипирования, Марчин задокументировал (на бумаге и видео) более 50 пользовательских интервью и личных тестов юзабилити с суперзвездами UX, такими как Брэндон Шауэр, Люк Вроблевски, Инди Янг и другие. Затем команда разработчиков использовала эти идеи для создания персонажей, написания десятков пользовательских историй и, в конечном итоге, определения требований к продукту.

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

2. Дизайн продукта

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


Источник изображения: UXPin .

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

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

В UXPin наш процесс состоит в том, чтобы провести сеанс группового наброска с маркерами на бумаге с сеткой, затем сократить его до нескольких каркасов, а затем добавить детали, пока у нас не будет макета высокой точности. Если предполагается пользовательское тестирование, мы превратим макет в высокоточный прототип. Для выпусков больших функций мы проводим обширное пользовательское тестирование, поэтому соотношение составляет примерно 70/30 в пользу прототипов.

3. Создание и запуск продукта

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


Источник изображения: Кампания MVP .

Кристофер Лайон, UX-менеджер в RedStamp , считает, что вы можете визуализировать требования к продукту и документы с техническими спецификациями в виде дорожной карты. Дорожная карта продукта показывает истории пользователей и помогает определить приоритеты функций, которые вы создадите, чтобы удовлетворить их. Иногда в дорожную карту могут быть добавлены конкретные даты, чтобы она также работала как временная шкала. Элегантность дорожной карты заключается в том, что она помогает вам определить приоритеты того, что вы создаете, делая ее дополняющей «как», определяемую вашими требованиями к продукту и техническими спецификациями. При выборе функций вы можете использовать модель Кано для их оценки по 3 категориям:

  • Базовые атрибуты — абсолютно необходимы для работы продукта. Например, основным атрибутом ноутбука является клавиатура или экран.
  • Атрибуты производительности — их можно сравнивать между различными продуктами в качестве KPI. Например, ноутбук оценивается по скорости процессора и месту на жестком диске, поскольку люди предпочитают быстрые компьютеры, которые могут хранить много данных.
  • Восхитительные атрибуты — они субъективны и зависят от предпочтений клиентов. Например, Macbook Air чрезвычайно тонкий и гладкий на ощупь. Правильный клиент найдет это отличным аргументом в пользу продажи, в то время как другие не впечатлены.

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

4. Улучшение продукта

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


Источник изображения: Управление продуктами по номерам .

Дэйв Дэниелс, основатель LaunchClinic, советует записывать цели запуска (например, 30 000 загрузок за 30 дней) и проверять наличие необходимых инструментов для документирования прогресса. Используя инструменты метрик и программное обеспечение для создания отчетов об ошибках, вы можете настроить повторяющиеся отчеты, чтобы следить за изменениями в течение первых нескольких недель после запуска и в дальнейшем. Со стороны клиента вы также можете сегментировать пользователей и отправлять им специальные опросы, чтобы определить, где вы можете повторить.

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

Объективные процессы в субъективной среде

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


Источник изображения: Примечания к процессу проектирования .

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

Чтобы узнать больше о том, как включить документацию в процесс проектирования, загрузите Руководство по UX-дизайну и документации по процессу. Советы экспертов представлены Аарроном Уолтером, Лаурой Кляйн, Яном Макалистером и десятками других. Также показаны визуальные примеры от таких компаний, как Vurb, MailChimp, Apple, Google и многих других.