Дизайн-мышление. Про трудности и неопределенность.
Мы делаем сервис для обмена электронными документами — Диадок. В нем можно формировать, отправлять, получать и подписывать электронные документы, которые равносильны бумажным документам с подписью. Недавно мы опробовали в команде метод дизайн-мышления. Решили по-честному рассказать про свой опыт и те трудности с которыми столкнулись :)
У нас была задача понять, как можно привлекать новых пользователей силами тех, кто уже работает в сервисе. И гипотеза: чтобы привлечь пользователей силами пользователей, нужно дать текущим во-первых мотивацию, а во-вторых удобный инструмент.
Вот вы говорите «дизайн-мышление»
Главное в методе — фокус на пользователях. Сначала решаем проблемы и боли, закрываем потребности пользователей, а уже потом думаем про технические и экономические нюансы.
В дизайн-мышлении есть куча инструментов и четкий порядок действий для того, чтобы исследовать сценарии работы. Мы прошли все этапы:
- Вместе выясняли, что делают люди, зачем они это делают, какие за этим стоят потребности
- Анализировали получившиеся данные
- Генерировали и ранжировали идеи
- Вместе продумывали варианты решения, рисовали бумажные прототипы и тестировали их
Приоритеты VS время
В команде были: аналитик, UX-исследователь, дизайнер, менеджер разработки и заказчик задачи. Через некоторое время выяснилось, что собираться командой в 5 человек, которые к тому же работают в разных офисах, не получается часто. Плюс куча времени уходит на то, чтобы состыковать расписания. Встретиться удавалось в лучшем случае один раз в неделю, а когда наконец встречались, было сложно вспомнить, на чем остановились. В результате задача безобразно растянулась, а у команды появилась новая присказка «А давайте не затягивать». Но мы затягивали.
Выглядело это так:
На самом деле, время конечно можно было найти. Но помимо времени была и другая проблема — падающий приоритет задачи. У каждого участника одновременно несколько задач в работе и приоритет у исследовательской задачи без конкретных сроков оказался невысок. Чем дольше мы ее делали, тем больше появлялось задач поважнее.
После первой итерации мы поняли, что так жить нельзя. Усилием воли поставили себе срок 2 недели и отодвинули другие задачи. В этот срок мы не уложились, но по крайней мере закончили вторую итерацию быстрее.
Мы поняли, что начали радостно делать задачу по новому методу, но не подумали, как совместить это с нашим существующим способом работы. Оба процесса пострадали: задача по дизайн-мышлению сильно растянулась, параллельные задачи пришлось подвинуть.
Начать заново сложно
После первой итерации мы получили такой результат: у людей, с которыми мы говорили, все хорошо. Гипотеза, что им просто не хватает мотивации, провалилась. Но, похоже, мы спросили не у тех ребят и не о том. И тут пришло осознание, что нужна вторая итерация и совсем другая категория пользователей.
Для команды это стало ударом. Несмотря на то, что методика дизайн-мышления предполагает, что у задачи может быть несколько итераций, недизайнеры оказались к такому не готовы. Психологически начать заново сложно. Возникает иллюзия, что что-то пошло не так, раз решение не нашлось с первой попытки.
И тут нам помог состав команды. Дизайнер напомнил остальным, что больше одной итерации это нормально и даже хорошо для процесса дизайна. И вообще было бы подозрительно, если бы с первой попытки все получилось. Мы вдохновились и вернулись к началу.
Размазанная ответственность — отстой
Когда у команды нет четкого понимания, кто несет ответственность за ход работы, то это не круто. Очевидная мысль, но мы это ощутили на себе. Обычно в Диадоке роль фитчалида выполняет аналитик. Он знает все, что происходит по задаче, фиксирует договоренности, собирает встречи и высылает по ним резюме, а главное, тащит задачу до финала.
В этот раз все было иначе. Мы начали работу всей командой. С установкой, что каждый из нас включается в равной степени на всех этапах и для каждого члена команды задача одинаково приоритетна.
Но нет. В реальности ответственность все равно пришлось взять двум участникам. А раз мы не договорились на берегу, то ребята взяли эту ответственность по необходимости, без четких границ. Один начинал, другой подхватывал и вроде бы нет четко обозначенного фитчалида, а вроде без него двигаться дальше тяжко, а иногда и невозможно.
Какой мы сделали из этого вывод? Делать каждый этап вместе — это здорово. Ещё лучше и комфортнее, когда есть человек который несет ответственность за процесс и результат. И хорошо бы сразу договориться, кто будет этим человеком.
Чем дело кончилось
Пройдя все этапы дизайн-мышления, мы узнали реальную ситуацию и сценарий работы, что мотивирует людей и какие проблемы они закрывают. Правда, ни одно решение не подошло пользователям полностью. В итоге революции не свершилось, но мы смогли предложить точечные решения, которые помогут решить конкретные проблемы.
Не смотря на трудности, с которыми мы столкнулись, дизайн-мышление вроде бы хороший инструмент. Отдельными кусками пользоваться вообще красота. Например, сталкивать идеи на мозговом штурме или идти в поля к пользователям и прямо там, с ними, на бумажках проверять гипотезы. Мы немного опасались, но люди отлично реагируют на бумажные прототипы, пусть их делал и не дизайнер.
При этом, чтобы эффективно и быстро прогнать задачу по процессу дизайн-мышления, нужно полностью выключить из работы 5–7 человек на несколько дней. В нашей текущей схеме работы это очень дорого делать. Да в любой дорого наверное.
В целом, мы с удовольствием взяли себе конкретные приемы и будем ими пользоваться. Но прогонять задачи по всему циклу в нашей ситуации долго и неудобно.
