Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

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

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

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

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

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

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

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

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

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

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

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