Книга: Пользовательские истории. Искусство гибкой разработки ПО
Эмпатия, фокус, формулировка, прототип, тестирование
Эмпатия, фокус, формулировка, прототип, тестирование
Несколько лет назад со мной связался один клиент и спросил, могу ли я помочь адаптировать процесс, который он назвал мышлением дизайнера. В организации этого клиента был внедрен процесс, типичный для Agile, и дела у них шли неплохо – неплохо в том смысле, что все предъявлялось вовремя и с хорошим качеством. Но, как известно, чем быстрее предъявляешь барахло, тем больше барахла получаешь. Это, конечно, звучит грубовато. Другими словами, клиент убедился, что корреляция между количеством программного обеспечения, которое они разрабатывали, и эффектом, который получали в результате, была невелика.
В то время я был известен как специалист по дизайну пользовательского взаимодействия и разработке Agile. Я подумал: «Раз я дизайнер и способен мыслить, значит, у меня есть мышление дизайнера». Но я был не прав. Это было не то, что имел в виду клиент. К счастью, я не высказал свою мысль вслух.
Мышление дизайнера – это способ работы, изначально внедренный компанией IDEO. Затем в школе дизайна Стэнфордского университета этот способ изучили и начали преподавать. В наши дни ему обучают во множестве университетов и используют во множестве компаний по всему миру.
В процессе дизайнерского мышления есть несколько этапов, которые в моем изложении выглядят многообещающе. Но на практике и я, и большинство других людей склоняемся к тому, чтобы делать прямо противоположное. Неудивительно, что нас преследуют неудачи.
Первый шаг дизайнерского мышления заключается в обеспечении эмпатии. Я бы не назвал это исследованием, что, как правило, ожидается в процессе дизайна. Название «эмпатия» выбрано потому, что в результате исследовательской работы необходимо по-настоящему осознать и прочувствовать, каково это – быть пользователем вашего продукта. Для этого нужно отправиться туда, где находятся пользователи, познакомиться с ними, понаблюдать за их работой и в идеале поработать вместе. Разумеется, если вы создаете программное обеспечение для хирургов, никто не ждет, что вы займетесь любительской хирургией, но сделайте все, что от вас зависит, чтобы ощутить себя в их шкуре. Не забывайте, что при традиционных исследованиях, особенно если это автоматические инструменты и опросы, собирающие количественные данные, мы получаем только данные, но не эмпатию.
Общайтесь с пользователями и заказчиками напрямую. Испытайте на себе те проблемы, от которых вы хотите их избавить своим решением.
Следующий шаг называется определением (фокусом). На предыдущем шаге, обеспечения эмпатии, мы многому научились, теперь нужно извлечь из него суть для того, чтобы выработать одинаковое понимание. Для этого понадобится большая совместная работа: изложение историй, передача информации и выделение главного из того, что мы узнали. После этого можно выбрать конкретных людей, имеющих конкретные проблемы, на которых мы сконцентрируемся.
На этом этапе используйте карты историй для того, чтобы отразить на них актуальное положение вещей. Включите в них детали, отражающие то, что вы видели или узнали. Сфокусируйтесь на трудностях пользователей, на том, что их раздражает или, наоборот, радует. Используйте простых персонажей, чтобы отобразить образ пользователя, который объединяет все, что вы изучили. Выберите специфические проблемы, на которых будете фокусироваться.
Концентрируйтесь на небольшом количестве проблем. Точно их сформулируйте.
Следующий шаг – формулировка. Если вы внимательно прочитали предыдущую главу, то помните упомянутую там простую методику проектной студии. Это и есть пример хорошего подхода к формулировке идеи. Как правило, в реальном бизнесе, где первый выдвинувший идею получает все пинки и все почести, кажется бессмысленным тратить время на выявление всех возможных идей. Может быть, вы помните, что ваши первые очевидные решения были именно очевидными. Поэтому, если важно найти действительно инновационное решение, подумайте об этом.
Мне нравится использовать карты историй в качестве контекста для формулировок. Применяйте карту, где показаны приятные и неприятные стороны работы, а также имеется другая информация о пользователях, а затем набрасывайте идеи прямо на карте. Записывайте идеи на карточках или стикерах и вставляйте их в карту в тех местах, где они наиболее уместны.
Сознательно придумайте несколько возможных решений проблем заказчиков и пользователей.
Следующий шаг – составление прототипа. Надеюсь, нам всем известно, что такое прототипы, но зачастую мы пренебрегаем их созданием, чтобы поскорей взяться за создание работающего продукта. В самом деле очень жаль! Затраты на создание простейшего бумажного прототипа невелики, но он помогает нам лучше обдумать свое решение. С его помощью мы можем сами попробовать взаимодействовать с продуктами. Создание простых прототипов из бумаги или средствами специальных программ занимает немного времени, но позволяет отфильтровать много идей, которые попросту не будут работать. Эмуляция реального использования продукта может помочь вам при формулировке идей и стимулирует к высказыванию дополнительных идей, которые улучшат решение.
Создавайте простые прототипы, чтобы проработать наилучшие решения. Доведите их до такой степени детальности, которая позволит пользователям и заказчикам оценить, действительно ли это решение поможет им справиться со своей проблемой.
Последний шаг заключается в тестировании. Под этим я не подразумеваю проверки, выполняемые для поиска багов. Я говорю о проверке того, действительно ли ваше решение может помочь кому-то справиться со своими проблемами. Быть может, вы удивитесь, но иногда это возможно, даже если в продукте есть баги. Когда у вас наконец появляется прототип, который, по вашему мнению, решает проблему, на которой вы решили сфокусироваться, покажите его людям, которые будут использовать продукт. Вы должны не просто показать и рассказать, да и о продажах говорить пока рано. Потенциальные пользователи должны оценить этот прототип как нечто, что может решить одну из имеющихся у них проблем. Они должны использовать его для выполнения реальной задачи. Вы можете обеспечить это, смоделировав необходимое количество нужных данных.
Представьте свое решение людям, которые будут покупать или использовать ваш продукт. Не ожидайте успеха с первого раза, итеративно совершенствуйте решение.
Важная особенность мышления дизайнера – такой способ работы, который поощряет небольшие мультидисциплинарные сплоченные команды к тому, чтобы быстро работать вместе, используя простые модели, эскизы, не слишком детальное документирование и общение. Это описание должно напомнить вам исследовательскую команду и ее партнеров, которых я описал в главе 12. А еще метод работы, в котором важное место отводится выработке одинакового понимания.
Использование элементов дизайнерского мышления помогает хорошо осмыслить проблемы, которые мы решаем, в результате чего мы всегда работаем над реальными, а не воображаемыми сложностями. Прототипирование и тестирование решений перед вложением значительных средств в создание полноценных масштабных продуктов поможет нам подтвердить, что мы создаем нечто действительно полезное людям.
Но само по себе дизайнерское мышление может вызвать некоторые проблемы.
- Тестирование Web-сервиса XML с помощью WebDev.WebServer.exe
- Разработка через тестирование и разработка с тестами
- 9.1. Классы и прототипы
- Часть III. Шаблоны разработки через тестирование
- Фокус-группы вместо пудры
- Приложение 1 Тестирование ПК при включении
- Тестирование модема
- Объекты без прототипов
- Качество ? Тестирование
- 2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ
- Прототипы – это опора программистов
- Эмпатия бренда: Постоянно улучшайте потребительский опыт