К настоящему моменту вы должны были ясно сформулировать, почему что-то создаете, с точки зрения бизнеса; вы исследовали пользователей и заказчиков, так что знаете, как у них обстоят дела сейчас. Настало время вообразить будущее – сформировать видение своего решения, а также взаимодействия с ним заказчиков и пользователей.

Составьте карту решения

Вот где карты историй проявят себя – по крайней мере, я так думаю. Я использую карты историй, чтобы четко представить себе жизнь пользователей после того, как им будет предъявлено мое решение. И Гэри, и команда Globo.com из первых двух глав строили именно такие карты. И как мы говорили во вступительных главах, шаги, которые делают люди в вашей истории, формируют последовательное повествование слева направо. Эти шаги называются пользовательскими задачами и представляют собой короткие глагольные фразы, которые, если читать их слева направо, образуют историю. Более точно сформулированные задачи и различные детали перечислены вертикально под каждым шагом. Если история длинная, выделите группы действий и постройте трехуровневую карту.

Слова и картинки

Случалось ли вам, описав программисту идею продукта, с приятным удивлением слышать в ответ: «О, это просто. На разработку не потребуется много времени»? Правда, позднее, когда вы приступали к разработке, оказывалось, что программист понял вас неправильно и думает о чем-то значительно более простом, чем представлялось вам. Например, вы говорили о сайте, с помощью которого можно продавать вашу продукцию в Интернете. Вы воображали что-то вроде Amazon Marketplace или eBay, а программист подумал о чем-то наподобие Craigslist, поэтому и дал такую оптимистичную оценку. В общем, за последние десять лет я твердо усвоил, что одних слов недостаточно.

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

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

Полная визуализация взаимодействия

Джош Сайден (иллюстрации Демиана Репуччи)

В один прекрасный день мне позвонил Роберт, менеджер по дизайну, недавно получивший работу в большом, хорошо финансируемом образовательном стартапе. Компания недавно начала крупный проект и активно набирала людей, которые должны были в сжатые сроки разработать обширную систему. Одна проблема: никто не знал, как подступиться к дизайну такого огромного и сложного проекта. Не могу ли я помочь?

Придя в офис через несколько дней, я встретился с Робертом. Он, одновременно гордый и предельно замотанный, все мне показал. Компания наняла большую консалтинговую фирму для помощи в разработке требований к проекту, и фирма проделала впечатляющий объем работы. Все стены в просторном офисе-лофте были завешаны листами тонкой коричневой бумаги, а каждый лист, в свою очередь, покрыт карточками и стикерами. Это были требования в форме пользовательских историй. Тысячи историй. Пока Роберт вел меня вдоль стены с историями, я обратил внимание на то, что истории были организованы согласно функциональным модулям: стена текстового редактора, стена английского языка. Но мне не удавалось представить себе работу системы целиком.

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

Случилось так, что через несколько недель я присутствовал на семинаре, который проводила команда художников-раскадровщиков. Целью семинара было обучение заказчиков формулировать видение их бизнес-идей. Эти художники сидели рядом с заказчиками и, быстро работая, рисовали по их описанию истории и набрасывали идеи в виде раскадровок – мини-комиксов, которые ясно и четко излагали каждую историю. Мне тут же захотелось скомбинировать этот подход с составлением карт историй, поэтому я пригласил присоединиться ко мне художника Демиана Репуччи, чья работа впечатлила меня наиболее сильно.

Через пару недель Демиан и я встретились с Робертом и его командой, а также менеджерами продуктов из разных частей системы. Мы сфокусировались на высокоуровневых процессах – основных вариантах действий пользователя в системе. В течение встречи Демиан рисовал в блокноте, а я выкладывал на стенах конференц-зала пользовательские варианты с помощью карточек и стикеров. После окончания встречи Демиан должен был вернуться к себе в студию, чтобы проиллюстрировать ключевые моменты, а я использовал Omnigraffle, чтобы выполнить окончательные версии карт историй, черновики которых мы набросали на встрече.

Мы с Робертом решили: самое лучшее, что мы можем сделать для команды, – это организованная структура, поэтому выпустили серию постеров, которые можно было напечатать на листах 11×17 дюймов и повесить на стены, что сформировало бы каркас карты историй. После этого команды могли бы пользоваться ими независимо друг от друга, чтобы реорганизовать свои истории. В результате из вида, организованного по модулям, который никак не помогал итеративной разработке, мы получили вид, основанный на логике пользования, который легко было трансформировать в несколько многомодульных релизов.

Один из способов визуализации пользовательского взаимодействия, вовлекающий в работу всю команду, – подход проектной студии. Проектная студия – это быстрый и простой способ, позволяющий организовать сотрудничество большой группы людей для работы над осознанным формированием идеи, или, проще говоря, выдвижения большого количества всевозможных идей. Вы быстро поймете, что самые лучшие идеи не может выдвинуть какой-то отдельный человек – лучшие идеи возникают из комбинации предложений нескольких авторов во время обсуждения. Проектная студия (и осознанное выдвижение идей) – противоположность общепринятому подходу, когда кто-то приносит идею, на первый взгляд кажущуюся подходящей, и все обсуждают ее. Впервые услышав о методе проектной студии от его авторов Джеффа Уайта и Джима Унгера, я удивился, почему раньше не пользовался таким прекрасным подходом. С тех пор я много раз запускал сессию проектной студии с участием команд разработки, ключевых партнеров и даже пользователей или заказчиков.

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

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

Рецепт проектной студии

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

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

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

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

4. Рисуют все! Раздайте всем бумагу, ручки, карандаши, при желании – какие-то шаблоны экранов и установите таймер. В моей практике встречались отрезки времени как 5, так и 60 минут. Лучше всего, по-моему, примерно 15 минут.

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

6. Попросите каждую группу объединить свои лучшие идеи в одно решение и проиллюстрировать его эскизами. Это самая сложная часть. На нее стоит отвести 15–30 минут.

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

8. Поблагодарите всех и объедините все идеи и наброски. Вы, UX-специалист и исследовательская команда должны рассмотреть и задействовать их, чтобы создать финальные, наилучшие эскизы UI. Помните выражение моей подруги Лизы Райшелт: «Дизайн через сотрудничество – не то, что дизайн в комиссии»? У вас будет много отличных, но не согласующихся друг с другом идей, и кому-то придется принять нелегкое решение.

Убедитесь в законченности

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

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

Проверьте технические особенности

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

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

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

Поиграйте в «Что, если»

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

Это хороший момент, чтобы рассмотреть то, что вами уже сделано, с большим количеством других людей. Расскажите им обо всем, к чему удалось прийти вам и вашей группе. Обещаю: у вас будет большая группа людей, наперебой задающих вопросы, начинающиеся с «А что, если…». Я обожаю таких людей (только не в тот момент, когда они стоят прямо передо мной). И я благодарен им за то, что они помогают мне задуматься о множестве проблем, прежде чем я натолкнусь на них сам позднее, когда полученный урок обойдется гораздо дороже.

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

Я думаю, в кино эти эскизы используются для того, чтобы более тщательно обдумать будущий фильм. Как инвестор я хотел бы, чтобы можно было заранее подсчитать, сколько площадок и павильонов нужно для съемки и как они должны выглядеть. Необходимо также знать, какие потребуются декорации, реквизит и спецэффекты. Словом, мне нужны были бы сценарий, раскадровка и множество других деталей, на которых базируются построение плана и оценка затрат. Имея эти данные, можно запланировать бюджет и временной график съемок фильма.

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

Идеи, примеры и маршруты

Дэвид Хассман, DevJam

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

Следуйте простому плану.

1. Предложите идею для исследования.

2. Выберите людей, которым, по вашему мнению, будет выгодна реализация этой идеи.

3. Сделайте подборку примеров того, как эти люди используют данную идею.

4. С помощью этих примеров составьте карту и маршруты, которые, по вашему мнению, понадобятся.

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

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

Выбор «пассажиров» не отбор космонавтов. Не стоит чересчур усложнять отбор целевой аудитории. Если вы не уверены, с чего начать, просто составьте список пользователей, которым, по вашим предположениям, будут полезны ваши идеи. Дополните их образы, чтобы они долго оставались живыми и реальными в сознании членов команды разработки. Поработав с ними некоторое время, выберите какой-то конкретный тип пользователя и не слишком волнуйтесь о правильности решения. Будьте готовы извлекать уроки из исследований и не беспокойтесь о том, верен ваш выбор или нет, – скорее всего, нет.

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

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

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

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

Праздновать победу рано

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

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