Пошаговое руководство по основам UX-дизайна.
В этой статье представлен рабочий процесс, который поможет командам, продуктам, стартапам и компаниям создать надежный и осмысленный процесс для улучшения пользовательского опыта своих клиентов. Различные этапы процесса можно использовать по отдельности, но в идеале они лучше всего работают как последовательность шагов.
В этом руководстве многое заимствовано из методологии Design Sprint, которую используют несколько команд Google для устранения неполадок и решения таких задач, как самоуправляемый автомобиль и проект Loon .
Двойной бриллиант
Этот рабочий процесс основан на том, что мы в UX-кругах называем «двойным ромбом», популяризированным Британским советом по дизайну , когда ваша команда расходится, чтобы понять идею посредством исследования, а затем сходится, чтобы определить задачу, расходится, чтобы сделать индивидуальный набросок, поделиться идеями, решить, как лучше всего двигаться дальше, протестировать и проверить.
Подготовка сцены
Для начала нужно определить основную задачу и записать её в виде предложения, спросив себя: «Какую проблему я на самом деле пытаюсь решить?». Формулировка задачи — это краткое описание проекта, которое включает в себя вашу цель.
Эта задача может быть связана с существующей функцией продукта, требующей доработки, или с совершенно новым продуктом. Какой бы ни была ваша задача, просто скорректируйте формулировки в соответствии с целью, которую вы пытаетесь достичь. Заявление должно быть связано с целями вашей команды, ориентировано на вашу аудиторию, вдохновляющим и лаконичным.
Вот несколько реальных примеров продуктов, над которыми я работал в прошлом;
Разработать систему управления лечением и последующим наблюдением пациентов с косолапостью.
Создайте приложение, которое упрощает сложные финансовые системы и сокращает их до самого необходимого.
Разработайте единое мобильное приложение для разных платформ, не жертвуя при этом брендом.
Обновление вашего заявления о вызове
После того, как вы запишете несколько вариантов цели, представьте их своей команде для достижения консенсуса. Можно установить крайний срок, чтобы помочь команде сосредоточиться на проблеме. Таким образом, с учетом внесенных изменений список выше может выглядеть так:
- Разработать систему управления лечением и последующим наблюдением за детьми в возрасте до 2 лет с косолапостью для запуска в первом квартале этого года.
- Создайте простое финансовое приложение, позволяющее покупать и продавать акции одним нажатием кнопки без предварительных знаний о финансах. Первоначальный запуск приложения запланирован на июль 2017 года.
- К концу этого года подготовить руководство по дизайну, которое будет гибким для разных платформ и эффективно позиционирует бренд компании на каждой платформе.
Когда формулировка задачи будет готова, повесьте её на видном месте, чтобы видеть во время работы. Вам придётся постоянно к ней обращаться, возможно, даже обновляя или изменяя её в ходе проекта.
Подтверждение проблемы
Следующий шаг — изучить задачу и узнать о ней больше. Вам нужно выяснить, насколько верно понимание проблемы вашей командой. Довольно часто мы смотрим на проблемы с собственной точки зрения, что опасно, поскольку большинство из нас, работающих в сфере технологий, на самом деле являются опытными пользователями, хотя на самом деле составляют меньшинство. Мы — активное меньшинство, и нас можно обмануть, приняв что-то за проблему, хотя это не так.
Существуют различные методы сбора данных для подтверждения правильности задачи. Каждый из них зависит от вашей команды и наличия у вас доступа к пользователям. Цель — лучше понять суть решаемой задачи.
Внутренние интервью с заинтересованными сторонами
Процесс собеседования включает в себя интервьюирование каждого члена команды и заинтересованных лиц вашей компании, от отдела маркетинга до бухгалтеров. Это поможет вам выяснить, в чём, по их мнению, заключаются реальные проблемы и какие, по их мнению, могут быть решения. Под решением я подразумеваю не технические решения, а наилучший сценарий развития событий и конечную цель для компании или продукта. Например, если использовать вышеприведённые задачи, например, «внедрение нашего программного обеспечения для лечения косолапости в 80% медицинских учреждений к концу года», это будет отличной целью.
Есть один нюанс. Этот метод проверки наименее популярен, поскольку он препятствует командному обсуждению и сотрудничеству, что потенциально создаёт разобщённую атмосферу в организации. Тем не менее, он может дать полезную информацию о клиентах и задаче проектирования, которую вы могли бы упустить.
Молниеносные переговоры
Это похоже на внутренние интервью, но на этот раз вы собираете всех заинтересованных лиц в одной комнате. Затем вы выбираете пять или шесть из них (маркетологи, отделы продаж, дизайн, бухгалтеры, аналитики и т.д.) для выступления, каждый из которых расскажет о проблеме со своей точки зрения максимум 10 минут. В своей презентации они должны осветить следующие темы:
- Цели бизнеса
- Проблемы проекта с их точки зрения (это могут быть технические проблемы, проблемы сбора исследовательских данных, создания дизайна и т. д.)
- Исследования пользователей, которые у вас есть в настоящее время
Оставьте 5 минут в конце для вопросов, а выбранный вами человек будет вести записи. После этого вы можете обновить задание, отразив в нём новые знания. Цель — составить список ключевых моментов, которые могут стать основой для функции или процесса, помогающего достичь цели вашего продукта.
Интервью с пользователями
Это, пожалуй, лучший способ узнать о пути пользователя, его болевых точках и потоке взаимодействия. Организуйте как минимум пять интервью с пользователями, а если у вас есть к ним доступ, то и больше. Вопросы, которые вы им зададите, должны быть следующими:
- Как они выполняют текущую задачу? Например, если вы хотите решить задачу для финансового приложения, представленную выше, вы можете спросить их: «Как вы сейчас покупаете акции и облигации?»
- Что им нравится в этом потоке?
- Что им не нравится в этом потоке?
- Какие похожие продукты пользователь использует в настоящее время?
- Что им нравится?
- Что им не нравится?
- Если бы у них была волшебная палочка и они могли бы изменить что-то в этом процессе, что бы это было?
Идея интервьюирования — заставить пользователя рассказать о своих проблемах. Это не тема для обсуждения, поэтому вы должны сохранять максимальную тишину. Это верно даже тогда, когда пользователь замолкает: всегда подождите немного, чтобы он мог собраться с мыслями. Вы удивитесь, как много человек может продолжать говорить после того, как он замолчал на несколько секунд.
Делайте заметки по ходу обсуждения и, по возможности, записывайте разговор, чтобы не пропустить ничего, что вы могли упустить. Цель — сравнить задачу с полученной информацией от пользователей. Совпадают ли они? Узнали ли вы что-то, что поможет вам обновить формулировку задачи?
Этнографические полевые исследования
Здесь вы наблюдаете за пользователем в полевых условиях, в контексте того, как он делает что-то, например, совершает покупки, ездит на работу, отправляет SMS и т. д. Причина в том, что в некоторых случаях люди говорят вам то, что, по их мнению, вы хотите услышать. Но если вы наблюдаете за тем, как пользователи выполняют действия и задачи самостоятельно, это может быть познавательно. По сути, вы наблюдаете, не вмешиваясь, отмечая то, что для них легко или сложно, и то, что они могли упустить. Цель — погрузиться в среду пользователя, чтобы лучше понять его болевые точки.
Этот метод обычно предполагает определённую работу, выполняемую в течение длительного периода времени, и требует, чтобы эту часть проекта возглавлял исследователь. Но, пожалуй, он наиболее информативен, поскольку позволяет увидеть группу людей, которых вы изучаете, в их естественной среде обитания.
Собираем всё вместе
После завершения этапа обучения в вашем проекте вам необходимо в последний раз взглянуть на свою задачу. На правильном ли вы пути? Нужно ли что-то скорректировать? Запишите всё, чему вы научились, и сгруппируйте по категориям. Это может стать основой для функции или потока, в зависимости от решаемой проблемы. Их также можно использовать для обновления и корректировки задачи.
Как только вы получите достаточно отзывов и информации, настанет время применить эти знания для создания карты проекта.
Карта проекта
Проблема, которую вы пытаетесь решить, обычно состоит из разных типов людей (или игроков), каждый из которых заинтересован в ходе проекта. Основываясь на полученных знаниях, вам необходимо составить список возможных игроков. Это может быть тип пользователя или заинтересованная сторона, например, «врач, лечащий косолапость», «пациент с косолапостью», «медбрат, ухаживающий за пациентом» и т. д. Запишите каждого игрока на левой стороне листа бумаги или, если у вас есть доступ, на доске. С правой стороны запишите цели каждого игрока.
Наконец, для каждого игрока запишите количество шагов, необходимых для достижения цели. Например, для «врача, лечащего косолапость» целью будет «вылечить пациента с косолапостью», поэтому шаги могут быть такими: «зарегистрировать пациента в системе», «начать его лечение», «создать цикл проверки состояния его здоровья» и «выполнить медицинскую процедуру».
В результате получается карта проекта с основными этапами процесса. Рассматривайте её как обзор проекта без лишних подробностей. Она также позволяет членам команды оценить, соответствует ли карта поставленной задаче. Позже, когда вы разберёте каждый этап, деталей будет больше. Но пока карта проекта даёт вам общее представление о шагах, которые пользователь должен выполнить для достижения своей конечной цели.
Каркасирование и раскадровка
Безумные восьмерки
Для этого я рекомендую метод «сумасшедших восьмёрок», который заключается в том, чтобы сложить лист бумаги вдвое так, чтобы получилось восемь панелей. Затем на каждой панели вы рисуете идею, основанную на всём, что вы уже изучили. Дайте себе десять минут на то, чтобы придумать идеи для заполнения всех восьми панелей. Если вы дадите себе больше 20 минут, вы можете начать откладывать дела на потом, сварить себе кофе, проверить почту, пообщаться с командой и, по сути, уклониться от выполнения работы. На этом этапе нужно создать ощущение срочности, поскольку это заставит вас работать быстрее и эффективнее.
Если вы работаете в команде, пусть каждый сделает свой собственный. Это запустит ваш мозг и заставит вас задуматься о задаче. Как правило, набросок представляет собой каркас дизайна интерфейса.
После этого вы и все члены вашей команды представляете свои идеи группе. Каждый должен подробно объяснить каждую из восьми идей и объяснить, почему они выбрали именно этот путь. Напомните каждому члену команды использовать полученные знания для обоснования своих идей. После того, как все представили свои идеи, наступает время голосования. Каждый участник получает два стикера и может проголосовать за любую идею. Если идея ему действительно нравится, он может отдать оба голоса за одну идею.
Усовершенствуйте свой дизайн
После голосования выберите идею, набравшую наибольшее количество голосов, и набросайте её окончательный вариант. Вы также можете позаимствовать другие идеи, которые вы услышали от коллег. Уделите этому заданию ещё десять минут. После этого снова представьте идеи своей команде и проголосуйте, как и раньше.
Раскадровка идеи
Имея готовый дизайн, пора заняться раскадровкой его взаимодействия с пользователем. К этому моменту вы уже должны были продумать различные шаги, которые будет выполнять пользователь. Довольно часто в процесс также включаются проекты ваших коллег. Вам нужен чёткий пошаговый процесс, учитывающий некоторые моменты, где пользователь может отклоняться. Сверьтесь с картой проекта, чтобы сверить свой дизайн с поставленной целью.
Создание прототипа
Создание прототипа — это не просто создание идеального кода, а создание чего-то, что будет выглядеть правдоподобно при использовании. Инструменты для создания прототипа у каждого свои. Некоторые, например, Keynote или PowerPoint, заставляют думать о процессе, а не о деталях дизайна. Возможно, стоит потратить время на изучение таких инструментов, как Balsamiq, Marvel или Framer, которые дают больше возможностей для управления поведением. Какой бы инструмент вы ни использовали, убедитесь, что он позволяет вам сосредоточиться на процессе и выглядит реалистично. Вам необходимо протестировать прототип на реальных людях, чтобы он был максимально правдоподобным, но в то же время его создание не должно занимать недели.
Создание прототипа — это баланс между временем и реалистичностью, поэтому будьте осторожны и не впадайте в крайности. В любом случае, вы можете потратить время впустую.
Проверьте удобство использования своих проектов
Отлично, если у вас есть тестовая лаборатория. Если её нет, создать её несложно, главное — создать комфортную среду для пользователей, не отвлекающую от процесса. В тестировании обычно участвуют пользователь и два человека из вашей команды: один делает заметки, а другой задаёт вопросы. Хорошей практикой будет использовать приложение, например, Hangouts, и записывать их действия. Это также удобно, если вы хотите, чтобы остальная часть команды наблюдала за процессом из другой комнаты. Нам, разработчикам приложений, это может быть довольно страшно, поскольку мы видим свои проекты в действии. Это может быть одновременно и освежающим, и отрезвляющим опытом.
Вопросы, которые следует задать
При тестировании дизайна просите пользователя выполнять действия в вашем приложении и заставляйте его проговаривать вслух, что он делает и почему. Это может показаться странным, но это помогает услышать его мысли. Старайтесь не перебивать и не указывать, что делать, если он застрял. Просто спросите, почему он выбрал тот или иной путь после того, как он его завершил (или НЕ завершил).
Вот что вам нужно выяснить:
- Что им нравится в прототипе?
- Что им не нравится в прототипе?
- Каковы болевые точки?
- Почему поток сработал?
- Почему поток не сработал?
- Что бы они хотели улучшить?
- Соответствует ли общий дизайн/поток их потребностям?
Пересмотр конструкции и еще один раунд тестирования
У вас есть рабочий прототип с обратной связью. Теперь пришло время доработать дизайн и проанализировать, что сработало, а что нет. Не бойтесь создать совершенно новую раскадровку и создать новый прототип. Начать всё заново может создать лучший поток, чем пытаться что-то изменить в предыдущем прототипе. Не будьте слишком дорожите им, ведь это всего лишь прототип.
Как только вы будете довольны своим дизайном, вы можете снова протестировать его и доработать. Если прототип совсем не удался, вы можете подумать, что проект провалился. На самом деле, это не так. Вы, вероятно, потратили меньше времени на разработку, чем если бы сами создали дизайн, и знаете больше о том, что на самом деле нравится пользователям. В дизайн-спринтах мы придерживаемся философии, согласно которой вы либо побеждаете, либо учитесь, поэтому не стоит слишком сильно себя корить, если идея не сработала так, как планировалось.
Сделай это!
Вы протестировали свои идеи. Пользователю они понравились. Заинтересованные стороны заинтересованы, поскольку участвовали в проекте с самого начала. Теперь пора приступить к реализации. К этому моменту у вас должно быть чёткое представление о том, что нужно сделать и каковы приоритеты в плане удобства использования. На каждом этапе проекта вы можете проводить юзабилити-тестирование, чтобы подтвердить свою работу и не сбиться с пути.
Я не могу не подчеркнуть, насколько важно узнать как можно больше, прежде чем вкладывать много сил, времени и энергии в то, что может оказаться неверным решением.
Эта статья даст вам базовые знания о UX и его важности. UX — это не то, что можно рассматривать как профессию дизайнера или исследователя. На самом деле, это ответственность всех участников проекта, поэтому я бы рекомендовал участвовать в нём при любой возможности.