← Назад | Продолжение (Глава 6) →
(Перед вами бесплатный курс от InVision Studio «Дизайн-мышление». В курсе 6 глав. Если вы здесь впервые, то лучше начните сначала)
Вы читаете перевод руководства “Design Thinking”. Над переводом работали: Федор Фоминых и Ринат Шайхутдинов.
Главный принцип — не дурачить самого себя. А себя как раз легче всего одурачить. Здесь надо быть очень внимательным. А если вы не дурачите сами себя, вам легко будет не дурачить других ученых. Тут нужна просто обычная честность.
Ричард Фейнман
Однажды в начале 1980-х компьютерный гений Дэнни Хиллис обедал с лауреатом Нобелевской премии физиком Ричардом Фейнманом.
Хиллис обмолвился, что он сейчас работает в одном стартапе над созданием компьютера с параллельной архитектурой в миллион процессоров.
Фейнман как настоящий физик ответил, что это «самая дурацкая идея, которую я когда-либо слышал». Но интрига сработала, и уже к концу обеда он согласился присоединится к проекту на всё лето.
В первые несколько месяцев работы Фейнман разработал схемы маршрутизатора. Эта штука отвечает за обмен данными между процессорами и устроена в разы сложнее чем сами процессоры. Маршрутизаторы передают информацию от точки к точке. Для этого требуется найти свободный проход в 20-мерной толкучке между процессорами. Если такой возможности не было, то данные должны были храниться в буфере до тех пор пока не откроется путь. Тут возникал вопрос — достаточно ли хорошо спроектирован буфер чтобы всё это выдержать?
Фейнман начал изучать принципиальные схемы и сидел и ждал когда ему расскажут как все это работает. Но в какой-то момент он взял карандаш, бумагу и попробовал самостоятельно смоделировать процесс для каждой схемы.
Команда буквально заново открыла для себя потенциал компьютера благодаря работе Фейнмана! Они назвали его машиной соединения, для комплексных числовых вычислений и физического моделирования. Он легко мог решать задачи с которыми не справлялись обычные компьютеры той эпохи. С его помощью стали изучать поведение жидкостей и имитировать зарождение жизни.
Вообще, изначально команда не ставила перед своей машиной задач на подобные вычисления, но Фейнман настаивал что стоит попробовать.
В итоге он не стал затягивать спор и написал прототип будущей программы. Из всех языков программирования он знал только Basic, поэтому выбор пал на него. Правда пришлось немного адаптировать язык для работы на параллельных процессорах. Фейнман писал программу, вручную моделировал запуск и прикидывал как быстро машина сможет ее запустить.
Фейнман воспринимал происходящее как игру и начинал с самых простых вопросов типа “Какой у нас самый простой пример?” Потом он накидывал следующие вопросы до тех пор пока проблема не начинала казаться решаемой. Тогда он вытаскивал карандаш и бросался в бой.
В итоге компания получила десятки миллионов долларов и стала лидером в области параллельных вычислений. Вклад Фейнмана оказался неоценим.
Хиллис признавался потом, что они с Фейнманом тогда сувались в области где по сути были не более чем новичками-любителями. Они ни черта не понимали ни в нейронных сетях ни в параллельных вычислениях. Их спасло только то, что все остальные находились примерно на таком же уровне.
Разделяя сложное и комплексное на несколько простых частей они активно прототипировали с целью найти ответы на ключевые вопросы. В результате им удалось запустить настолько инновационные процессы, что самим пришлось удивляться.
Прототип от физика
Ричард Фейнман ни разу не был продуктовым дизайнером — он был физиком. Но он был физиком с хорошо развитой интуицией и отлично понимал какой мощью обладает прототип. Разрабатывая прототип дизайнер каждый раз проходит хорошую школу. На этом этапе мы учимся устранять разногласия в команде. Прототип — отличный способ быстро и недорого проверить идею. На эскизном этапе Фейнман определил проблему и наметил ключевые вопросы которые предстояло решить.
Прототип показал и доказал что проектируемая машина будет способна выполнять сложные вычисления. Можно сколько угодно пялиться в умные книги, щеголять формулами, а можно просто сделать прототип и пойти дальше. Фейнман правильно поступил когда решил не тратить время на изучение новых языков. Он работал на том, что знал и это дало большую экономию времени. И если бы прототип провалился это означало бы потерю лишь нескольких дней, но никак не месяцев.
На этом примере мы очень хорошо разобрали для чего нужно делать прототипы компаниям которые уделяют внимание дизайну. Причём прототипы лучше делать не только в начале проекта а ходу всего движения. Ниже мы рассмотрим историю создания прототипа для компании Uber. Это кейс про то, как находить решения для мультиязычных продуктов. Вы узнаете как научить свою команду не бояться пилить прототип на начальной стадии разработки продукта.
Кейс: Uber выходит на международный уровень
Знаете что, когда продукта ещё нет а фидбэк нужен уже вчера, то самое лучшее решение это прототип! Его можно разослать пользователям прямо в поля … именно так мы получаем мнения водителей со всего мира а не только из Сан-Франциско.
Молли Никс, Убер
Uber — активно развивающийся сервис совместных поездок показывает просто впечатляющую статистику.
На момент написания этой статьи у Uber: более 1 миллиона водителей (Uber зовёт их водители-партнеры), более 2 миллиардов поездок, более 8 миллионов пользователей. Куда бы вы не отправились путешествовать — скорее всего вы и там вы встретите Uber. Uber — платформа, которая объединяет водителей и пассажиров, работает более чем в 400 городах из 70 стран.
И почти в каждой стране разработчики столкнулись с совершенно уникальным набором задач. Приходилось учитывать отличия в языке, символике и конечно же, в скорости интернет-соединения. Всё это учли еще в 2015 году, когда Uber решились с нуля переработать своё приложение.
На старте команда выкатила облегчённые версии прототипов на английском языке. Для работы использовали Sketch и InVision. Команда не забывала про свою глобальную аудиторию и возвращалась к исходным файлам Sketch для замены английского на хинди или китайский. Потом они прорабатывали по каждому направлению прототип в InVision.
С такими прототипами на руках команда Uber получила возможность в каждой стране добиться тугой струи фидбэка от пользователей и начать собирать ответы на важные сведения о барьерах в концепции приложения. Сначала прорабатывали навигацию. Какие функции самые главные для водителей и как предоставить к ним доступ через приложение наилучшим образом? На этапе оценки они постоянно задавались вопросом как лучше бы перевести на другой язык такие термины как «прибыль» и «рейтинги».
Хороший прототип — это прототип, который помогает найти ответы на ваши вопросы.
Молли Никс, Uber
По дороге ребята сделали несколько довольно забавных открытий. Иконка «Прибыль» отображала внешний вид собственно самого экрана с прибылью когда ты на него попадёшь. При тестировании прототипа для Индии выяснилась интересная деталь: водители воспринимали эту иконку как “настройки сети”. Дело в том, что в Индии очень слабый интернет и люди вынуждены постоянно держать на прицеле уровень сигнала. Магическим образом иконка прибыли напоминала всем иконку отвечающую за качество интернета в строке состояния. Иконку перерисовали и таким образом, проблема была решена до запуска продукта!
На этом приключения с качеством интернета не закончились и вскоре появился ещё один проблемный сценарий. Это произошло когда команда начала выстраивать функционал и переходить от низкой детализации (lo-fi) к высокой (hi-fi) и к интерактивным анимированным прототипам высокой проработки
До этого, на lo-fi прототипах они ещё не получали обратной связи на сценарий подключения к интернету. Итак, водитель начиная смену подключается к интернету для приёма заказов. В этот момент приложение запрашивает сервер о возможности принять сигнал в данной локации. И здесь у водителя появляется стойкое ощущение что приложение просто-напросто зависло. Пришлось в срочном порядке заанимировать сюда плавный переход. И если в обычной ситуации анимированный переход относится скорее к полировке визуальной части, то сейчас это сыграло важную роль в ключевом сценарии. В результате взаимодействие было восстановлено и водители перестали паниковать.
Обратите внимание, что на протяжении всего рабочего процесса команда постоянно сопоставляла насколько точно прототипы соответствуют тем вопросам на которые они должны были отвечать. На начальных этапах работали с прототипами с низкой проработки чтобы точно понять как складывается перевод на другие языки. По мере развития продукта появились более функциональные прототипы с высоким уровнем проработки. Их задачей было устранять проблемные точки при взаимодействии пользователя с приложением.
Быстрые прототипы
Запустить прототип перед запуском продукта вполне нормально для любого дизайнера. Но, почему бы не поискать возможность применить прототипирование на ещё более ранних стадиях? Когда вы определяете степень проработки прототипа учитывайте на какие именно вопросы должна ответить именно эта версия. Рекомендуем внимательно относиться к прототипам низкой проработки. В таких случаях следует с большой осторожностью относится к результатам исследований с участием пользователей.
Но, если вам надо запилить новую фичу или просто как-то передать команде свою очередную супер-идею, то использовать скетчи и бумажные прототипы — очень даже хорошая идея. Сейчас мы вместе разберём как именно можно использовать прототип на старте проекта. Конкретные примеры можно найти в Bootleg Stanford d.school Bootcamp.
Создаем серию интерактивных прототипов за минимум времени
Выберите конкретную функцию для которой вы с командой хотели бы разработать прототип. Прототип с высокой степенью проработки пойдёт на тестирование к пользователям. Поэтому он требует на себя кучу времени. Но перед ним не поленитесь и разработайте версию с низкой проработкой — этим вы возможно, сэкономите кучу времени. Работайте быстро. Если не можете — бросьте себе вызов и научитесь. Найдите час времени и сделайте 2-3 варианта прототипа. Нарисуйте карандашом от руки, сфоткайте и перенесите в InVision. И уже там быстренько собираем интерактивный прототип. Как вариант можно использовать приложение «Прототип на бумаге» (POP).
Почему дизайнеры стали использовать прототипы
Ставим жирную точку в спорах на тему дальнейшего развития продукта или новой функциональности.
Помните как Ричард Фейнман и Дэнни Хиллис имели разные взгляды на дальнейшее развитие продукта? Наверняка в вашей команде имеют место похожие ситуации. В таких случаях просто сделайте два разных прототипа на два разных варианта развития концепции. Но уж если вы решились тестировать прототип на пользователях, то для достижения наглядной реакции постарайтесь довести проработанность прототипа до необходимого уровня. Но без фанатизма, не увлекайтесь. Устранив проблему постарайтесь изолировать переменную, которую вы тестируете.
Прототипирование в изумрудном городе
Если подключите к разработке прототипа своих back-end-спецов, то сэкономите время и ресурсы.
Сервис потокового воспроизведения музыки Pandora умеет творить волшебство — тыкаешь палец вверх и нужные треки сами попадают в плейлист! Компания обожает свой проект Music Genome Project, так как он умеет фильтровать музыку по атрибутам (темп, вокал и т.д.). Ещё он умеет подключать сложный алгоритм и выстраивать всё это в нужном порядке.
Когда-то, на ранних этапах проектирования команда смогла прочувствовать важный момент. Плейлисты будут слушать люди значит и разработать их должны тоже люди. Как в книжке про изумрудный город, за кулисами представления всегда стоит человек и руками классифицирует песенки являясь по сути частью алгоритма.
Возьмите этот способ на вооружение. Например, при разработке чат-бота, сначала посадите отвечать на вопросы живого человека — так получится куда точнее выявить нужды пользователя. Если делаете скажем Uber для собаководов, то первое время всей командой дружно гуляйте с собаками. А уже потом начинайте разработку приложения для собаководов. Такие инструменты, как IFTTT и Zapier, могут подключать сервисы, необходимые для создания подобных прототипов и всего лишь одним нажатием кнопки вы отправите текст прямо вашей группе разработчиков.
Прототипирование как в изумрудном городе — это история о том, что сначала надо узнать как вообще ваши пользователи общаются, а потом уже садиться писать код.
Прототипы — инструмент обучения
В 1986 году космический шаттл «Челленджер» взорвался на 73 секунде полета. Погибли 7 астронавтов. Ричард Фейнман присутствовал в конгрессе на совещании по расследованию причин ужасной катастрофы.
По прошествию лет эта история обросла анекдотами. Но Фейнман действительно стоял на трибуне конгресса и показывал, что происходит с уплотнительными кольцами если температура за бортом немного холоднее обычной. В руке он держал стакан с холодной водой в котором плавало деформированное уплотнительное кольцо.
А теперь сравните его действия со сложными диаграммами используя которые инженеры пытались предупредить об влиянии низких температур на уплотнительные кольца.
Фейнман обладал умением выявлять проблему, разбирать её на части и решать её при помощи прототипа. Это умение и помогло ему провести данный эксперимент. Мы делаем прототипы, для того чтобы учиться. Но можно делать прототипы чтобы обучать.
Если вы хотите дать своей команде новые способы решения сложных проблем — заставьте себя шире использовать прототипирование в вашем рабочем процессе. Иногда процесс созидания сам по себе даёт взрыв энергии необходимой для решения проблемы. Главное — чётко обозначить вопросы на которые мы отвечаем и уровень точности ответа который мы ждём.
Для большинства практикующих дизайнеров самая прикольная движуха начинается на этапе создания прототипа. И этот этап действительно может стать отправной точкой. Нас не должно смущать то что прототип лишь четвёртый по счёту этап в дизайн — мышлении. Помните, процесс не обязан быть линейным. Чтобы добиться эмпатии дайте пользователям совместный доступ к прототипу, или даже привлеките их к разработке! Это даст вам от них отличную обратную связь. В оставшейся главе мы узнаем как использовать прототип для проверки гипотезы. Попробуем направить вашего внутреннего Фейнмана на решение настоящих проблем.
← Назад | Продолжение (Глава 6) →