Design Thinking и работа с конечными пользователями

Рекомендуем

Please reload

Design Thinking и работа с конечными пользователями

10.12.2017

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

 

  1. Определение проблемы

  2. Исследование

  3. Формирование идей

  4. Прототипирование

  5. Выбор лучшего решения

  6. Внедрение решения

  7. Оценка результатов

 

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

Проект, в котором я выполняла роль одного из аналитиков, был направлен на автоматизацию работы сельскохозяйственного сектора. Этот сектор сложен тем, что конечные пользователи очень консервативны, существует большой порог вхождения новых технологий, а также очень сложна предметная область (термины, бизнес процессы). Более того, проект был нацелен на решение задач отрасли в различных странах мира (3 абсолютно не связанных страны, с разными климатическими условиями).

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

 

  1. Ваша должность, возраст, образование, специализация и т.д.?

  2. Опишите ваш типичный рабочий день (неделю, месяц, год)?

  3. С какими проблемами вы сталкиваетесь ежедневно (еженедел., ежемес....)?

  4. Как вы решаете эти проблемы?

  5. Какая информация, знания, ресурсы вам необходимы для принятия оптимальных решений?

  6. Что доставляет вам наибольший дискомфорт (отнимает больше всего времени, приносит наибольшие убытки)?

 

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

 

Далее был реализован кликабельный прототип системы, с использованием таких программ как Axure, InVision, Adobe XD, Sketch. О плюсах и минусах каждой я расскажу в отдельной статье. В прототипе были выделены наиболее приоритетные сценарии использования и составлен тест план, который включал в себя:

 

  1. Набор заданий, которые должен выполнить конечный пользователь

  2. Успешный результат выполнения каждого задания

  3. Систему оценок достижения результата

  4. Общие вопросы к респонденту

    1. Что больше всего вам понравилось в системе?

    2. Что меньше всего вам понравилось в системе?

    3. Что бы вы добавили в систему?

    4. Что бы вы изменили в системе?

    5. Какие чувства у вас вызвала работа с данной системой? (интерес, отторжение, желание использовать еще и т.д.)

    6. Все ли термины и обозначения были понятны?

 

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

 

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

 

  1. В ходе первичного опроса, сначала попытайтесь понять истинную проблему респондента (можно воспользоваться методами 7W, или 5 Why). Не пытайтесь разрекламировать или навязать решение, которое уже у вас есть (лучше его вообще не иметь или забыть на время). 

  2. Попробуйте пересказать проблему, которую обозначил вам респондент, но своими словами

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

  4. Тестирование каждой версии прототипа стоит проводить на 3-4 респондентах каждой группы пользователей

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

  6. Задания для тестирования должны быть краткими и понятными, содержать 1-2 функции системы, выполняться не более 2х минут пользователем, который хорошо знает систему.

  7. Всего заданий для тестирования должно быть от 5-7. Непосредственное тестирование системы не должно занимать более 1 часа.

 

 

 

Please reload

Контакты

ИП Теселкина Ксения Валерьевна

ИНН 540202590009

+7-913-720-63-13

analystlife@gmail.com