Проблема не должна заранее содержать решение
Просьба сделать приложение для очереди уже выбирает инструмент. Но исходная трудность может состоять в другом: посетитель не понимает, где ждать и когда наступит его очередь. Возможно, часть проблемы решается понятным указателем или изменением порядка обслуживания. Поэтому сначала описывают человека, ситуацию и затруднение. Полезно отделять услышанную просьбу от наблюдаемой потребности. При этом нельзя объявлять, что разработчик лучше знает желания людей: предположение нужно уточнять через вопросы и наблюдения, а не заменять чужой опыт собственной уверенностью.
Разные варианты расширяют пространство выбора
Если сразу дорабатывать первую идею, команда начинает защищать её ещё до проверки. Лучше предложить несколько направлений, которые меняют разные элементы ситуации. В примере с ожиданием это могут быть информация о порядке, обозначение пространства или изменение момента вызова. Сначала варианты описывают кратко, без дорогой реализации. Затем сопоставляют их с ограничениями: доступностью, понятностью и возможностью применения. Необычный вариант может подсказать полезный принцип, даже если целиком он непригоден. Оценка и генерация остаются связанными, но не должны полностью подавлять друг друга.
Прототип отвечает на один вопрос
Прототип не обязан быть уменьшенной копией окончательного продукта. Им может стать бумажный экран, временная табличка или разыгранная последовательность действий. Важно заранее знать, чему должна научить проверка. Например, найдёт ли человек нужное место без объяснения? Если проверяется понятность указателя, не требуется сразу строить систему уведомлений. Чем уже вопрос, тем проще заметить полезное наблюдение. При этом участнику дают возможность действовать, а не только выслушать презентацию и оценить её вежливым одобрением.
Реакция помогает уточнить задачу
Во время проверки полезно фиксировать конкретные действия: куда человек посмотрел, где остановился, что спросил. Фраза ему не понравилось слишком общая. Возможно, решение было незаметно, текст непонятен или исходная проблема определена неверно. После наблюдения выбирают изменение и следующую проверку. Иногда возвращаются к постановке задачи, а не улучшают оформление прежней идеи. Такой возврат не означает потерянную работу: он предотвращает дальнейшие затраты на решение, основанное на ошибочном предположении.
Попробуйте на практике
Разработайте бумажный прототип указателя для вымышленного места ожидания. Реальных посетителей привлекать и помещение менять не требуется.
- Опишите ситуацию человека, который впервые пришёл и не понимает, где ждать своей очереди.
- Сформулируйте проблему без слов приложение, экран или табличка, сохранив только потребность.
- Придумайте три разных направления решения и выберите одно для ограниченной проверки.
- Нарисуйте прототип и запишите ожидаемое действие пользователя, а также признак затруднения.
- Составьте два возможных результата проверки и объясните, что измените в каждом случае: оформление, содержание или саму постановку задачи.
Как проверить результат. Прототип связан с конкретной потребностью и одним вопросом. Успех определяется наблюдаемым действием, а не только положительной оценкой идеи.
Частые вопросы
Дизайн-мышление подходит только дизайнерам?
Нет. Логику наблюдения, уточнения задачи и проверки вариантов можно применять к услугам, рабочим процессам и повседневным решениям. Специальность не заменяет понимание контекста.
Если прототип не сработал, нужно начинать всё заново?
Сначала выясняют, какое предположение не подтвердилось. Иногда достаточно изменить одну деталь, иногда требуется вернуться к вопросу. Объём пересмотра зависит от полученных данных.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.