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