Совместное проектирование

Когда использовать

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

Корни метода в 1970-х, в Скандинавии, где рабочих привлекали к проектированию систем, которыми им предстояло пользоваться. Ключевое отличие от юзабилити-тестирования в роли человека. Пользователь здесь партнёр, а не объект наблюдения.

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

Лёгкий вариант метода — FIDO (Freehand Interactive Design Online), его придумали в Fidelity. Концепцию разбирают на отдельные элементы, каждый пишут на карточке или стикере, и участник один на один собирает из них свой идеальный экран, а потом объясняет выбор. Команда считает, какие элементы брали чаще всего и сколько элементов взято из каждого продукта. Такой формат ставят между концепцией и прототипом, до юзабилити-тестирования.

Что нужно для старта

• Цель и сформулированная проблема. «Придумайте идеальный продукт» слишком широко, лучше конкретная задача
• Группа не больше десяти человек. Фасилитатор, двое пользователей, двое представителей бизнеса, двое разработчиков и ведущий записей
• Участники из целевой аудитории. Среди пользователей берут и тех, кто живёт на краю группы, например слабовидящих для продукта с доступностью
• Полдня или день, можно разбить на короткие встречи
• Материалы. Повестка, правила, сценарии, результаты прошлых исследований, бумага, толстые фломастеры, стикеры, таймер
• Ясное объяснение, что идеи не обязательно будут реализованы

Как провести

1. Цель и границы

   Заранее определите, чему посвящена сессия и на что участники могут повлиять. Скажите им, что предложенное не гарантированно попадёт в продукт, иначе потом придётся разочаровывать.

2. Участники

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

3. Подготовка

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

4. Вводная

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

5. Эскизы

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

6. Показ и обсуждение

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

7. Сведение

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

8. Закрытие и разбор

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

Результат

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

Типичные ошибки

• Слепо следовать пользователю

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

• Обещать реализацию

  Участники могут ждать, что воплотят каждую идею. Скажите заранее и повторите на сессии, что это не гарантировано.

• Слишком тёплая атмосфера

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

• Просить красиво вместо много

  Если оценивать рисунок, люди боятся. Ставьте цель по числу идей, давайте толстые фломастеры и не оценивайте качество рисунка.

• Разговоры во время рисования

  Идеи сначала возникают у каждого отдельно. Обсуждение начинайте после.

• Критика как реакция

  Оценка «нравится» ничего не даёт. Критика отвечает на вопрос, решает ли идея известные потребности.

• Выбрасывать идеи на сведении

  Группа должна развивать идеи, соединяя лучшее, а не отбрасывать.

• Групповая концепция как готовый дизайн

  Это зафиксированные рассуждения и открытые вопросы, а не итоговое решение.

• Без опытного фасилитатора

  Придётся выстраивать работу группы, давать слово всем и собирать разные мнения. Для этого нужен опыт.

Кто использует

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

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