Один из способов визуализации пользовательского взаимодействия, вовлекающий в работу всю команду, – подход проектной студии. Проектная студия – это быстрый и простой способ, позволяющий организовать сотрудничество большой группы людей для работы над осознанным формированием идеи, или, проще говоря, выдвижения большого количества всевозможных идей. Вы быстро поймете, что самые лучшие идеи не может выдвинуть какой-то отдельный человек – лучшие идеи возникают из комбинации предложений нескольких авторов во время обсуждения. Проектная студия (и осознанное выдвижение идей) – противоположность общепринятому подходу, когда кто-то приносит идею, на первый взгляд кажущуюся подходящей, и все обсуждают ее. Впервые услышав о методе проектной студии от его авторов Джеффа Уайта и Джима Унгера, я удивился, почему раньше не пользовался таким прекрасным подходом. С тех пор я много раз запускал сессию проектной студии с участием команд разработки, ключевых партнеров и даже пользователей или заказчиков.
Какой бы подход вы ни использовали, комбинируйте идеи, совершенствуйте их и приходите к единому пониманию программного продукта, который хотите создать.
Может случиться, что в попытке визуализировать свое решение вы обнаружите, что некоторые моменты не были внесены вами в карту. Придется что-то добавлять, менять или переставлять карточки, чтобы отразить на карте вашу новую идею. Не волнуйтесь, на самом деле это положительный момент.
Рецепт проектной студии
Проектная студия – эффективный и быстрый способ работы в группе для генерации идей. Этой техникой можно пользоваться по-разному, вот мой простой рецепт.
1. Пригласите группу людей, чьи мнение и идеи вам близки, а одобрение и понимание нужны для создания продукта. Оптимальный размер группы – от восьми до двенадцати человек.
2. Опишите задачу, которую решаете. Рассмотрите уже проделанную работу, чтобы выявить возможности. Просмотрите еще раз персонажей и карты, отражающие то, как пользователи решают проблемы сейчас. Если вы уже начали составлять какие-то карты для решений, просмотрите и их, но будьте осторожны, не говорите слишком много, иначе все неизбежно будут отталкиваться от ваших мыслей и вы не услышите самые лучшие идеи других людей.
3. Можно продемонстрировать примеры для вдохновения. Посмотрите вместе и обсудите удачные похожие продукты. Рассмотрите также продукты, не совсем схожие с вашим, но воплощающие удачные идеи, которые могут натолкнуть на хорошую мысль.
4. Рисуют все! Раздайте всем бумагу, ручки, карандаши, при желании – какие-то шаблоны экранов и установите таймер. В моей практике встречались отрезки времени как 5, так и 60 минут. Лучше всего, по-моему, примерно 15 минут.
5. Делитесь идеями, если действуете в маленьких группах. Этот прием работает в группах до четырех человек, поэтому, если всего вас, например, 12, разбейтесь на три меньшие группы. Поделитесь друг с другом своими идеями и дайте им оценку. Следите, чтобы оценки высказывались с точки зрения эффективности решения изначальной проблемы, а не просто из-за того что нравится или не нравится. Следите, чтобы каждый развивал не только свои, но и чужие идеи. Продолжайте личную работу в маленьких группах в течение фиксированного времени, скажем 30 минут.
6. Попросите каждую группу объединить свои лучшие идеи в одно решение и проиллюстрировать его эскизами. Это самая сложная часть. На нее стоит отвести 15–30 минут.
7. Попросите каждую группу представить свои лучшие идеи, сведенные воедино, всей группе. Обсудите их.
8. Поблагодарите всех и объедините все идеи и наброски. Вы, UX-специалист и исследовательская команда должны рассмотреть и задействовать их, чтобы создать финальные, наилучшие эскизы UI. Помните выражение моей подруги Лизы Райшелт: «Дизайн через сотрудничество – не то, что дизайн в комиссии»? У вас будет много отличных, но не согласующихся друг с другом идей, и кому-то придется принять нелегкое решение.
Убедитесь в законченности
Что мы умеем делать хорошо, так это додумывать детали. Например, если мы видим два кадра какого-нибудь комикса, то легко догадаемся, что произошло между ними. Этот прием широко используется в комиксах, романах и кинофильмах. Но, раздумывая о том, что делает программный продукт, мы часто склонны воображать себе интересные функциональности, пренебрегая тем необходимым, что их связывает. Продолжая аналогию с фильмом, можно представить, что на экране сменяли бы друг друга погони на автомобилях и перестрелки, но ни слова не было бы сказано о том, почему все это происходит и какая история их связывает.
Изложение во всех подробностях пользовательских историй с помощью карты поможет вам проговорить все критически важные детали, которые их связывают. В большинстве случаев люди понимают, что крутая функциональность, которую они рассматривают, потребует изменения некоторых пользовательских настроек в самом начале истории, а также отчетов и уведомлений в конце. Могут быть затронуты не только функциональности, но и люди. Например, администраторы должны обработать новые настройки безопасности для системы, а менеджеры – контролировать, как функциональность используется в их командах.
Проверьте технические особенности
Возвращаясь к аналогии с киносъемками: если вы собираетесь продолжать работу над своим фильмом, стоит подумать о выборе места съемок, спецэффектах и других деталях. В какой-то момент вам придется с головой погрузиться в сценарий и продумать все технические детали создания фильма.
Карта историй вашего программного обеспечения очень полезна в дискуссиях того же типа, что вы проводили бы, будь вы режиссером кинофильма. Обсудите карту своих решений с инженерами и архитекторами, прежде чем двигаться дальше. Видение картины в целом поможет им заранее предусмотреть большинство технических ограничений, которые могли бы затруднить реализацию по-настоящему удачных решений. Вас могут заранее предупредить о том, что хоть ваше решение и выглядит прекрасно, но реализовать его при заданном бюджете времени и имеющейся архитектуре не представляется возможным. Они могут также предложить альтернативные пути выполнения задач, которые обеспечат вашим пользователям те же возможности взаимодействия, но будут более экономичны с точки зрения реализации.
Эти инженеры большой страховой компании потратили много времени на обсуждение находящейся на стене карты. По ходу обсуждения они обнаружили в огромной карте своего продукта небольшую нестыковку: придется изменить обработчик бизнес-правил их продукта. Возможность увидеть картину в целом помогла им визуализировать свою работу несмотря на сложность продукта. Обладая этим знанием, ребята смогут обсудить, что им необходимо запланировать на самых ранних этапах и как минимизировать риски.
