«Больше науки, чем искусства»: изучаем практику UX-дизайна

Только что окончив колледж, я пошел в летний творческий курс стажера в одном из крупнейших рекламных агентств в мире. Мой новичок находил все впечатляющим, от военных комнат, заваленных визуальными концепциями, до зерновой машины на 7-м этаже. Каждую пятницу дизайнеры из моей команды распечатывали недельные макеты пользовательского интерфейса, наклеивали их на доски, обсуждали визуальные стили и выбрасывали любые макеты, которые считались некачественными. В конце концов, на каждой доске оставалось лишь несколько «лучших вариантов».

Вы, наверное, думаете: «Звучит как стандартная критика. Что случилось с этим?" Ничего, только сам метод.

Вопреки распространенному мнению, дизайн — это больше наука, чем искусство. Искусство предназначено для интерпретации, а дизайн — для понимания. Это фундаментальное отличие означает, что, хотя искусство можно критиковать, дизайн следует исследовать, тестировать и повторять.

Не поймите меня неправильно — абсолютно важно чтобы проект прошел экспертизу. На Kickstarter мы проходим три этапа проверки дизайна функции:

1. Студия: исследования и открытия
2. Критика: сойди на одном пути
3. QA: проверка работоспособности перед внедрением

Обратите внимание, что критика — это только одна часть процесса? Даже в этом случае мы тратим больше времени на анализ результатов тестов, чем на то, чтобы бросить имитацию на пол.

Вы не ваш пользователь

О дизайне так легко судить. Результаты основаны на наглядности, и люди любят комментировать, как все выглядит. Также так же легко предположить, как должны себя вести: «Средний пользователь заметит это первым» или «Как пользователь я предпочитаю X, а не Y». Предположения не следует принимать за абсолютные. Вы должны подтвердить их, потому что в конце концов они всего лишь мнения — да, верно? Тем не менее, как бы мир UX ни любил говорить о проверке предположений, они делают этого недостаточно. И когда они это сделают, их метод снова перекосится в сторону качественных методов, таких как обычное интервью с пользователем или когнитивный анализ. Возможно, гораздо легче начать разговаривать с людьми, чем запрашивать некоторые данные.

Количественные данные говорят вам, что; качественные данные говорят вам, почему — это исследование пользователей 101. И то и другое одинаково важны для проверки гипотез, но я бы сказал, что одно должно происходить раньше другого, для простоты процесса. Когда вы сможете начать с количественной оценки и вначале провести предварительное разделение и разделение ваших пользователей, вы сможете определить неравенство использования в различных пользовательских сегментах, проанализировать их характеристики и оценить влияние решения на каждый из них — объективно и с учетом масштабируемости. Затем вы можете использовать эти результаты высокого уровня для качественного исследования; например, убедившись, что пул интервью является репрезентативным для широкого круга пользователей, а не только для тех, кто кричит громче всех. Следовательно, я считаю, что обзоры дизайна намного полезнее, когда люди предлагают, какие данные собирать для подтверждения моих решений или как разработать тест, а не предлагают субъективную критику.

Прекратить проектирование для Dribbble

Количественные данные могут использоваться даже для принятия самых сложных решений пользовательского интерфейса. Как продуктовые дизайнеры, сколько раз вы завершали великолепный дизайн на Figma только для того, чтобы понять, что он не справлялся с большим объемом пользовательского ввода во время реализации? Быстрая прокрутка вниз Dribbble показывает множество привлекательных графиков на приборной панели. Да, я называю их графикой, а не мокапами, потому что они не репрезентативны для реальных продуктов.

Для разработки реальных приложений необходимо знать его ограничения и крайние случаи (проблемы, которые возникают на крайних концах рабочих параметров). Как сделать так, чтобы 80% исследовательских проектов работали хорошо, а остальные 20% работали не слишком плохо?

Ответ заключается в том, что нам нужно рассмотреть все возможные сценарии пользовательского интерфейса, задавая вопросы об использовании продукта, прежде чем даже спроектировать интерфейс . Недавно я помог Kickstarter выпускать дополнения — функцию, которая позволяет создателям предлагать спонсорам дополнительные «надстройки». Некоторые из самых первых вопросов, которые я задал, были: Каково максимальное / среднее количество наград, которые может получить создатель, с разбивкой по категориям и уровням финансирования? Сколько в среднем / максимум предметов в награде? Какой процент проектов детализирован? Затем, выполнив некоторое моделирование данных, я получил довольно хорошее представление о возможностях пользовательского интерфейса и о том, какие граничные случаи он должен покрывать.

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

Наблюдайте, собирайте, рисуйте!

Однажды я присутствовал на беседе со знаменитым итальянским информационным дизайнером Джорджией Лупи. К моему удивлению, она всегда начинала визуализировать данные вручную независимо от объема, будь то 50 или 50 000 точек данных. Лупи является соавтором книги «Наблюдать, собирать, рисовать!», В которой она разработала различные упражнения для исследования, сбора и категоризации необработанных данных. Если вы дизайнер и хотите окунуться в мир данных, вам следует начать именно с этого, просто задав как можно больше вопросов «сколько», «сколько» и «каков процент». Когда вам будет представлен набор данных, прокрутите и оцените данные. Получите представление о необработанных данных; ваш мозг может многое извлечь из этого.

Начните использовать инструмент поиска данных, такой как Looker или Metabase, если в вашей организации этого нет. Изучите архитектуру данных своего приложения и потренируйтесь выполнять запросы, используя исключительно графический интерфейс пользователя (GUI). Такие инструменты, как Looker, значительно снижают барьеры для доступа к запросам и анализу данных с помощью своих графических интерфейсов, что означает, что более сложной задачей здесь является навигация по уникальной структуре данных вашего приложения. Я предлагаю прочитать веб-документацию Mozilla, чтобы получить базовое представление о массивах, объектах и ​​типах данных. Это строительные блоки приложения — разберитесь с ними, и вы откроете для себя совершенно новый уровень дизайна продукта.