Когда я начинаю работу над новым дизайном (целый проект или отдельная часть), я выключаю компьютер.

Я делаю все возможное, чтобы задержать запуск дизайн-приложения как можно дольше. Сначала мне нужно получить цельную картину того, над чем мне предстоит работать. Чтобы не отвлекаться на детали и не сойти с ума на визуальных аспектах, в то время как главный концепт еще не выработан.

В самом начале моего пути как дизайнера я сразу рвался в Photoshop. Обычно это вело к очень красивым экранам, с огромными ошибками.

Проблема в том, что если вы работаете с не-дизайнерами, красивые экраны — то, что нужно. Вы сможете предоставить “вау-эффект” клиенту, а как этот вау-эффект будет реализовываться, уже значения не имеет. А мы все-таки предпочитаем создавать нечто в духе “Все довольны”.

По мере моего профессионального роста как дизайнера, я изучаю новые подходы, внедряю их в свой рабочий процесс. Следующий описанный прием — мой любимый.

1 . Почему Почему Почему Почему Почему

(или 5 Почему)

5 Почему

Одним из принципов наших стандартов дизайна в Atlassian — всегда понимать глубинный смысл того, над чем мы работаем.

Разработка проекта сегодня рассматривается как решение определенной проблемы для людей. Имея определенный набор деталей, которые нужно решить с помощью проекта, очень легко потерять цельную картину. Вопросы “почему” помогают оставаться на верном пути, четко понимая, что мы делаем и для кого.

Задать такой вопрос пять раз подряд позволяет найти скрытый ответ, определить истинную задачу. Они нужны, чтобы выявить причины, вызывающие саму проблему, и на чем стоит сфокусировать внимание, чтобы ее решить.

Этот подход часто оспаривается. Очень распространена ситуация, при которой два (или больше) человека начинают с одной задачи, и в конце приходят к совершенно разным ее причинам. Лично я не рассматриваю это, как ошибку. Это скорее возможность открыть различные причины одной и той же проблемы. Такие, о которых я бы и не подумал, если бы не подобный ресерч. Это действительно может привести к решению проблемы под совершенно новым и оригинальным углом.

Пример

Проблема: Пользователь не разрешает уведомления.

  • Почему? Он нажимает “запретить”
  • Почему? Он не хочет получать уведомления
  • Почему? Он не видет в них смысла
  • Почему? Он еще не получал действительно нужных уведомлений
  • Почему? Он запускает приложение впервые

Это простой случай, согласен, но отталкиваясь от этих причин, можно уже обрисовать решение:

  • Подождите до второго запуска, чтобы спросить его об уведомлениях
  • Поясните смысл ваших уведомлений в процессе онбординга
  • Поясните этот смысл на вашем лендинге
  • И т.д.

Профессиональный совет: этот прием можно использовать также и в решении ваших проблем из повседневной жизни.

2. Временная шкала

(До Во время После)

Временная шкала UX

Первое, что я понял при изучении UX-дизайна:

Опыт пользователя выходит за рамки экрана. Это не только то, что пользователь делает с вашим продуктом, но и то, что бывает до и после этого.

Я всегда применял метод с временной шкалой в своих проектах. Целью такого подхода всегда является дизайн полного UX, от начала и до конца.

Продумывание частей До и После как раз и дает завершенность разрабатываемого вами проекта.

Вот некоторые из вопросов, которые я себе задаю:

До

  • Как пользователь получает доступ к моему приложению?
  • appStore, вебсайт, реклама, QR-код?
  • У него уже есть аккаунт? Нужен ли ему аккаунт для выполнения действий?
  • В каком контексте он запустит мое приложение? Будет ли это времяпровождение на уютном диванчике или же это будет поездка в переполненном метро?
  • Каков его уровень напряженнности?
  • Много ли у него есть времени?
  • Насколько быстрое подключение к интернету?

После

  • Как использовать опыт, который пользователь только что получил в приложении?
  • Нужна ли ему какая-то информация, доступ к которой он сможет легко получить?
  • Как оправдать его ожидания, если он чего-то ждет от продукта?
  • Если мой продукт работает на разных устройствах, как обеспечить переход из одного в другое?
  • Как узнать, что произошло месяц назад?

Каждый из этих вопросов поможет не забыть ни о какой возможности порадовать пользователя.

Примечание: радовать пользователя — это немного не о том, чтобы анимировать каждый фрагмент интерфейса или прыгать вокруг него в костюме пасхального кролика. Это больше о тех мелких, но важных деталях, которые делают жизнь немного легче: качественное ответное письмо, оффлайн-режим, предзаполненные формы, сообщение об ошибках и т.д.

Профессиональный совет: Чтобы лучше визуализировать UX, вы можете расписать его на временной шкале, сделать своеобразный чертеж, или проделать следующий прием!

3. Рассказ в картинках

Рассказ в картинках

Как дизайнеры, мы всегда передаем свои идеи в виде картинок, поэтому наброски UX всегда помогают лучше визуализировать все этапы, через которые проходит пользователь.

Чтобы это осуществить, один дизайнер однажды посоветовал мне разделить лист А4 на 6 частей, и затем нарисовать каждое действие как комикс.

Для меня это способ разложить жизнь пользователя по полочкам, визуализируя сценарий и понимая его привычки. На основе моего рисунка я нахожу болевые точки, через которые проходит пользователь, и подбираю наиболее подходящие технологии, чтобы упростить эти сложности.

Также, по возможности, я не рисую из своего воображения, я беру за основу результаты интервью пользователей.

Как только я определился с тем, как будет работать продукт, я начинаю заново и прорисовываю опыт пользователя еще раз, чтобы убедиться, что мой сервис покроет каждый аспект.

Когда я думаю, что я пришел к хорошему UX (и если проект это позволяет), я пытаюсь оживить свой комикс. На самом деле, очень полезно проверить, работают ли ваши взаимодействия в рамках определенного контекста.

Бонус: нет необходимости полностью разрабатывать продукт. Очень бюджетный прототип — более, чем достаточно, чтобы выполнить такой анализ.

Это всегда помогало мне понять, что есть такие простые взаимодействия, которые оказываются совсем непростыми:

  • На улице, зимой, в перчатках.
  • В бакалейном магазине с огромной сумкой в одной руке
  • На ярком солнце, темный интерфейс — не самая удачная идея.

Профессиональный совет: Разделите страничку на шесть частей маркером, сделайте фотокопию для использования в будущем.

4. Разговор

 

Разговор

Разговорный UI сейчас очень в тренде. И хотя я думаю, что этот концепт интерфейса подходит далеко не всем продуктам, в нем определенно есть кое-что очень интересное.

В самом деле, цель дизайнера — трансформировать технологию в что-то, что выглядит и ощущается натурально. Так что есть смысл использовать естественное взаимодействие, такое как разговор в чате, для запуска какого-то действия. SMS — самая старинная опция нашего мобильного телефона, в конце-концов.

Когда я создаю дизайн сложной части интерфейса, я начинаю представлять, что машина — это кто-то, кого я нанял выполнить работу.

Кто-то, с кем я бы мог поговорить.

Я думаю, какие вопросы нужно ему задать, чтобы получить определенную информацию, приказы, которые нужно отдать, чтобы что-то сделать, ответы, которые я получу.

Я прописываю весь разговор, выстраивая его в наилучшем порядке.

Это помогает мне определить и организовать лучший сценарий.

Узнать, как много информации нам нужно на странице.

Какую информацию нужно сгруппировать, и почему.

Какие действия будут доступны, и как определить главное.

А также, какая информация понадобится машине, чтобы реализовать мои потребности.

Профессиональный совет: Я не советую проделывать это громко в тихом, открытом месте.

5. Список

Список

Когда я получаю новый бриф, обычно в моей голове одновременно топчется уйма мыслей. Вдохновение, визуальная составляющая, взаимодействие, хорошие принципы построения UX, копирайтинг, конкуренты и т.д. Я знаю, что не нужно фокусироваться на мелких деталях на старте, но я также не хочу забывать что-то по ходу разработки. Чтобы быть уверенным в том, что ничего не потеряется, я просто выписываю все на стикеры.

Я пишу все, что всплывает в голове по поводу этого проекта, а также все остальное, что могло бы к нему относиться (каким-либо образом).

Например, когда я начинаю работу над каким-то мобильным проектом, я выписываю все компоненты смартфона:

  • Геолокация
  • Пуш-уведомления
  • Гироскоп
  • Камеры
  • Touch ID
  • И т.д.

Я делаю то же самое и для концептов интерфейса:

  • Карточки
  • Интерфейс чата
  • Snapchat
  • Yo
  • И т.д.

Или контекст:

  • Дома
  • Во время тренировки
  • В спортзале
  • В машине
  • В автобусе
  • И т.д.

Затем я категорирую эти слова.

Первая часть списка позволяет мне две вещи:

  • Вынуть все из собственной головы, и в то же время знать, где я могу это все найти при необходимости (Начало проекта может слишком перегружать мозг, так что я теряю ход процесса).
  • Убедиться, что я не упускаю ничего важного.

А теперь анекдот

В прошлом году я работал со стартапом Birdly.

В то время команда разрабатывала мобильное приложение.

В это время они работали над их UX, 2 версиями приложений (Android + iOS), запускали стартап, и все это руками 3 человек (включая всего одного разработчика).

Не стоит и говорить, что они, скорее всего, столкнулись с массой проблем.

Затем команда предприняла очень интересный стратегический поворот. Вместо продолжения работы с их мобильным приложением, они решили просто сфокусироваться над разработкой бота Slack. Это решение дает массу преимуществ — использование плюсов новой платформы, более простая интеграция в жизнь пользователей, возможно меньше технической работы для получения того же (или лучшего) результата, которого они пытались добиться с помощью 2 приложений и многое другое.

Перечисление всего, что напрямую/косвенно относится к проекту и постоянное держание этого списка перед глазами помогают открыть новые возможности и инновационные подходы.

Профессиональный совет: Пусть я и люблю стикеры, но вы можете использовать ПО для построения ассоциограмм, регулярно заполняя ваш список последними своими находками для следующего проекта.

Спасибо за чтение!

Нравятся вам мои подходы или не очень, есть ли у вас свои идеи — делитесь впечатлениями в комментариях!