Смерть каркасу. Прямо к высокой точности!

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

Существует широкий спектр используемых инструментов, сгенерированных артефактов и результатов, обнаруженных в процессе проектирования UX/UI, и они зафиксированы в различных документах или даже в прототипе. Наш самый узнаваемый артефакт — это старый добрый вайрфрейм.

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

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

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

Проблема с вайрфреймами

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

Давайте рассмотрим процесс проектирования на примерах, когда каркасное проектирование может быть узким местом:

Причина 1: клиенты не понимают, на что смотрят

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

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

Проблема в том, что вайрфреймы очень абстрактны.

Они описывают то, что похоже на вещь, но не саму вещь, которая будет построена. На этом этапе вайрфреймы будут содержать изображения-заполнители и всевозможные ТЗ (будущие), ТЗ (только для размещения) и ТЗ (будет определено), как в примере ниже.

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

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

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

Было несколько клиентов, которые специально просили просмотреть аннотированные визуальные проекты, потому что им намного проще соединить точки, провести вдумчивое обсуждение и дать взвешенный отзыв.

Причина 2: они не всегда подходят для пользовательского тестирования

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

Один из типичных способов проверки такого рода вещей — прототипирование.

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

Это мудро? UX, визуальный и копировальный дизайн влияют друг на друга. Их сложно разделить и изолировать в тестовой среде. Подобно научному исследованию, результаты одной изолированной проверки функции не могут контролировать или предсказывать, как она будет вести себя в естественных условиях.

Иногда более эффективно тестировать все эти вещи вместе.

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

Более того, поскольку копируемый контент влияет на UX, сам перевод может повлиять на UX.

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

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

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

Причина 3: они превращают жизнь разработчиков и QA в ад

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

Это нормальная часть процесса визуального дизайна. Что также нормально, так это то, что любые изменения, сделанные в визуальном дизайне, не будут отражены в вайрфреймах, потому что вайрфреймы были «подписаны».

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

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

Почему бы просто не дать разработчикам один точный документ, включающий все? Большинство клиентов также были бы признательны за копию, которую можно использовать в качестве полного справочника по работе.

Решение: пропустить вайрфреймы

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

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

Имеется солидный справочный материал.

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

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

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

Используйте как можно больше стилей и шаблонов, чтобы ваши высококачественные результаты были максимально точными.

Вы запланировали множество циклов прототипирования и тестирования.

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

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

Ваши участники теста очень буквальны.

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

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

Чтобы понять финансовые концепции, участники теста в этой аудитории должны были чувствовать, что они действительно совершают сделки. И чтобы понять, как работает продукт, он должен был выглядеть и ощущаться как настоящее приложение.

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

У вашего клиента ограниченное время и/или бюджет.

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

Если у вас есть клиент, который не может позволить себе (или вряд ли купит) полную проработку UX, могу ли я предложить сократить время создания макета? Создайте что-то внутри, если вам нужно, но держите проект в движении для вашего клиента. Протестируйте реальные, осязаемые проекты и попросите вашего клиента отреагировать на реальную работу.

Как убить фазу каркаса

Эта часть довольно субъективна, так как будет зависеть от вашего личного рабочего процесса и конкретных потребностей вашего клиента.

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

Шаг 1: Начните с вашего обычного процесса исследований и открытий.

Интервью, полевые наблюдения, кабинетные исследования, конкурентный анализ — чем бы вы ни занимались (или планировали) — завершите этот этап как обычно.

Шаг 2: Нарисуйте немного по пути.

Пока вы проводите исследование, вы, вероятно, получаете идеи для полезных макетов и шаблонов, привлекательных потоков и тому подобного. Запишите их, как обычно. Мне нравится делать миниатюрные наброски в своем блокноте с письменными заметками рядом с ними. Возможно, вы предпочитаете делать наброски на доске или делать скриншоты интересных шаблонов пользовательского интерфейса. Что бы ни помогало вам запоминать хорошие идеи, делайте это.

Шаг 3. Подготовьте высококачественный документ

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

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

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

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

Шаг 4: Начните проектирование.

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

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

Точно так же не создавайте список имен, в которых все говорят «Джон Смит» с номером телефона 555-1212. Используйте генератор случайных списков или подключаемый модуль, чтобы создавать разные имена и числа, или создавайте любой набор данных, который вам нужен для отображения. Это может показаться излишним, но это позволяет решить проблемы с макетом и шириной символов, а также помогает вашему зрителю понять, что все эти пять записей разные.

Шаг 5: Знайте, когда прекратить проектирование.

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

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

Обратите внимание, что это может зависеть от того, что нужно вашим участникам пользовательского тестирования для правильной оценки работы. Для низкограмотной целевой аудитории, о которой я упоминал выше, ничто не было лишним. Для каждого участника я сделал вариант прототипа с их настоящим именем и номером телефона, чтобы приложение действительно чувствовало себя «своим». Чем меньше им приходилось предполагать, тем легче им было следовать и тем лучше были мои результаты.

Шаг 6: Наслаждайтесь высококачественной обратной связью и результатами тестирования.

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

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

Подведение итогов

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

Однако в правильных случаях переход прямо к высокой точности может улучшить ваш процесс:

• Улучшить обратную связь с заинтересованными сторонами . Клиенты, разработчики, другие дизайнеры и участники тестирования из целевой аудитории могут точно видеть, что они получат, что позволяет им давать более качественные отзывы.
• Ускорьте рабочий процесс прототипирования . Мало того, что ваши проекты будут сразу готовы к тестированию, вы сможете получить отзывы сразу по ряду вещей: UX, текст и визуальные эффекты.
• Предоставляйте единый документ клиентам и разработчикам . Устраните необходимость перекрестных ссылок и проверки различных документов, чтобы понять, как должна работать кнопка. Это также отличный способ для вашего клиента обсудить работу со своими внутренними заинтересованными сторонами, чтобы получить от вас еще больше отзывов.
• Экономьте время и деньги . И это почти всегда хорошо!

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

• • •

Дальнейшее чтение в блоге Toptal Design:

• UX электронной коммерции — обзор лучших практик (с инфографикой)
• Важность ориентированного на человека дизайна в дизайне продукта
• Лучшие портфолио дизайнеров UX — вдохновляющие тематические исследования и примеры
• Эвристические принципы для мобильных интерфейсов
• Упреждающий дизайн: как создать волшебный пользовательский опыт