Comments 3
Прежде всего, небольшое замечание. Live coding - "живое" кодирование, кодирование в прямом эфире, не life coding - кодирование жизни.
Взгляд со стороны технаря - создателя продукта.
Упражнение - создание наброска дизайна под очень конкретный сценарий за ограниченное время. Цель упражнения - продемонстрировать свой подход к решению подобных задач наравне с умением оставаться в рамках обсуждаемой темы.
Важно - не надо пытаться показать своё глобальное видение, обширные знания и всё такое прочее. Это всё прошли на этапе собеседования. Надо попытаться решить конкретную задачу. При этом показать умение учитывать желание заказчика, разумеется.
Как бы я подошёл к решению конкретной задачи.
1 Понимание задачи через вопросы.
а) Выявление отличий от тех бизнес-процессов которые вы понимаете, либо имеете о них общее представление. Как вариант, т.к. тест синтетический, можно выдвинуть встречный синтетический сценарий.
Допустим, что обычные курьеры (простите, представители) работают так-то и так-то. Хоть что-то решающее такую задачу вообразить должен любой дизайнер. Пусть в реальности они вообще не так работают, это не важно для данного теста.
В чём значительное для решения задачи отличие роверов от представителей? Мне не нужно понимание, как роверы двигаются по маршруту или как конкретно с точки технической реализации туда карта загружается и как именно она выгружается. Мне нужно понимание, нужна ли им подзарядка в течение дня и, например, осмотр после каждого клиента, т.к. это важные шаги бизнес-процесса. Что собеседующий перечислил - то и важно. Что забыл - того не существует.
Нельзя самому выдвигать какие-то предположения, если нет понимания хоть чего-то похожего - мы просто записываем шаг за шагом все основные переходы между участниками процесса, избегая впадания в подробности. Нужно задавать вопросы. Итак, начинаем с того, что клиент заказал карту, то дальше? ОК, дальше карту изготовили и доставили в распределительный пункт. Что дальше? Дальше карту загрузили в ровер и он повёз её до места. Дальше? Дальше дошёл ровер до места и послал СМС клиенту. Дальше? Дальше клиент ПИН-код ввёл и получил карту. Стоп, откуда у него ПИН-код? Он получил его на указанный способ связи после оформления заявки и изготовления карты. ОК, т.е. шаг №3 - отправление клиенту ПИН-кода. Карта получена, что дальше? Дальше ровер отправляется по маршруту. А когда маршрут закончен? Дальше ровер идёт на быстрый осмотр, потом зарядка, потом новая загрузка. ОК. А клиент? А клиент дальше как обычно, это уже всё есть. ОК, закончили тогда. Получается вот это - согласны? Где неточности? Что пропущено? Ничего? ОК.
Всё, значит роверы у нас не застревают, не ломаются, нет шагов с этим связанных в нашем мире. Если что-то упущенное пришло в голову самим - можно упомянуть просто как что-то, что мы сейчас рассматривать не будем, чтобы показать, что у вас самих есть какое-то представление - это плюсов добавит, но если не пришло в голову, то и фиг с ним. И так хорошо.
Это просто пример - я не имею представления как эти ваши роверы работают, у нас в Австралиях их нет пока что.
Пусть включают своё воображение тоже, пусть участвуют в процессе по полной - ваша задача показать умение получения информации из третьих лиц, а не способность телепатии. А ешё ваша задача уметь показать способность концентрироваться на важном и отбрасывать второстепенное.
б) Выявление жёстких ограничений, которые прямо не указаны пока что в шагах БП, но важны с точки зрения UX. Требования закона, например. Или неспособность открыть дверь и подняться по лестнице. Что не перечисленно клиентом - того не существует в нашем синтетическом мире этой задачи.
Цель этого этапа - выстроить каркас из:
а) основных шагов бизнес-процесса, диктуемых как жёсткими ограничениями, которые нельзя обойти, так и сложившимися в компании привычными процессами.
б) в случае принципиального непонимания процесса или слишком большой сложности задачи, создания искусственного упрощённого сценария для укладывания в заданные временные рамки. Это синтетический тест, так примите участие в задании ограничений для облегчения его выполнения.
Результат - искуственный бизнес-процесс содержащий все важные для решения задачи шаги и ваше понимание всего этого. Никаких метрик, никаких целей. Просто как это делается с точки зрения клиента и каковы важные ограничения на этом всём лежат.
2 Теперь у нас есть понимание процесса, можно выдвигать гипотезы, строить прототипы. Вот тут уже могут быть важны задачи бизнеса - хотят ли они сделать роверы основным средством доставки или это просто опция для определённых сценариев (доставка поздно вечером, как вариант). Вот на этом этапе эти вопросы продемонстрируют Вашу способность строить гипотезы, удовлетворяющие запросам и модифицировать решение под эти запросы.
Никаких вопросов про метрики. Метрики ВТОРИЧНЫ. Задачи бизнеса ПЕРВИЧНЫ. На вторичное в условиях жётского ограничения нет времени. Тут выявится почти наверняка что-то, пропущенное на первом этапе. Например, этап выбора даты и времени доставки карты.
Ну и как технарь, дальше я идти не буду, это вам дизайнерам виднее и привычнее. Я дальше сделаю наброски дизайна экранов, UX flows, wire flows если можно таким гордым словом описать мои каракули и т.д. Но я не дизайнер, я технарь - решатель проблем. Я описал свой обычный подход к поиску решения реальных практических задач, которые я изначально не понимаю. Для меня он работает и примерно так я бы подошёл к такому тестированию.
Коротко:
1 Через вопросы сформировать понимание процесса как такового на этапах передачи информации/задач между участниками процесса. Определить жёсткие ограничения процесса на каждом шаге. В случае полного непонимания задачи, сформулировать синтетическое решение по аналогии на своих представлениях. Это наш "контракт" с заказчиком. SoW, ТЗ, требования. You name it.
Это те самые 10 минут "вопрос-ответ". Вряд-ли уложитесь, если нет никакого понимания, пусть 20 будет. Гипотеза всё равно формируется во многом уже здесь, т.к. дальше работать будете просто отражая шаги БП в UX.
2 Сформировав представление о задаче решить её, уточняя пожелания и требования заказчика в рамках "контракта" на этом этапе, отсекая, однако, всё большое, что не вошло в понимание процесса, если только это не критически важно для заказчика, т.к. время ограничено.
Умение оставаться в рамках задачи, а не растекаться - это крайне важное умение, которое полезно продемонстрировать. Можно вернуться к новым требованиям, если время останется. Или, как вариант, продолжить его обсуждения здесь и сейчас если заказчики готовы добавить время для обсуждения этого тоже, или если они готовы признать успехом что-то не готовое по истечению времени.
Это шаги формирования гипотезы и прототипа. 20-30 минут. Или больше.
Спасибо за статью! Классный и полезный материал, сам сейчас изучаю whiteboard challenge. Под конец появился один вопрос, касаемо "абстрактных задач".
Мне кажется не совсем правильно отказываться от них, ведь даже если они не применимы в реальном мире, они могут помогать развивать нестандартное мышление и помогать быстрее находить решение необычных кейсов
Как подготовиться к Whiteboard Challenge: мой провал, выводы и советы для дизайнеров