Редизайн

Часто сталкиваешься с ситуациями, когда редизайн понимается исключительно как изменение «шкурки» продукта. Притом, что проблемы, из-за которых возникает необходимость редизайна, имеют куда более глубокие корни: они могут происходить из-за сложной структуры; запутанной логики; устаревших технологий, которые или не выдерживают уже проверки временем, или выводят данные в формате, который сложно оптимизировать (взяли давным давно какой-то первый попавшийся модуль, кое-как решающий нашу задачу, при отсутствии альтернатив и желании написать своё) и так далее. Просто сменой «шкурки» эти проблемы не решить.

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

Анализ

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

  1. Описываем структуру сервиса или сервисов для дальнейшей её оптимизации.
  2. Определяем все их контентные сущности для дальнейшей их оптимизации.
  3. При наличии нескольких сервисов, которые будут объединены общим дизайном, необходимо подробно расписать всё, что их объединяет, и всё, чем они отличаются друг от друга для создания фундамента к проектированию универсальных принципов общего дизайна (фреймворка).
  4. Описываем взаимодействие сервиса внутри себя, сервисов между собой или со сторонними продуктами.
  5. Определяем структуру хранения данных.
  6. Отвечаем на вопрос «Нужно ли переписывать серверную часть?». Прогресс на месте не стоит и оптимизировать сервис нужно не только с помощью Фотошопа. К сожалению, встречаются случаи, когда именно эта часть принимается в штыки и выдвигаются требования в духе «давайте решим это как-нибудь на уровне CSS — мне тяжело переписывать вывод данных в другом шаблоне, пусть останутся эти пять табличек одна в другой».

Формирование портрета аудитории

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

Определение аудитории сервиса — это не придумывание описательных портретов из общих слов без всякой конкретики: мужчина-женщина, от 18 до 50, хипстер-пенсионер… Это всё не говорящая ни о чем вода, которая нам никак не поможет.

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

По результатам этого этапа оптимизируем описанную на предыдущем этапе структуру сервиса и контентные сущности.

Параллельно с этой частью, backend-программисты могут переписывать серверную часть и организовывать хранилище данных, доступ к ним и инструментарий для всякого взаимодействия (API).

Проектирование пользовательского взаимодействия (UX)

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

В достаточной для представления форме (кто на листке бумаги, кто в Axure или аналогах) мы формируем прототип сервиса страница за страницей и алгоритмы взаимодействия пользователей, исходя из их задач: как, например, частному лицу максимально легко найти информацию о тарифах (и как их представить так, чтобы был выгодный акцент на том, что выгодно компании, конечно же) на денежные переводы; а владельцу бизнеса максимально легко и понятно подключить свой бизнес к сервису приема платежей за свои товары или услуги; какие интерфейсные элементы будут обеспечивать эту функциональность (select тут будет или suggestion input); как общие структурные правила будут работать на разных сервисах с разным набором и количеством данных; как это будет учитывать изменения режима отображения сервиса на клиенте (адаптивность) и так далее. А так же продумываем обратную связь сервиса в сторону пользователя: как он будет реагировать на те или иные действия пользователя.

Этот этап, хоть мы и не детализируем сильно, фокусируясь в первую очередь на поведенческих алгоритмах и логике, важно разрабатывать полностью осознавая как все принципы графического дизайна: модульная сетка, типографика, акценты, соотношение размеров элементов, принцип «фигура-фон» и так далее; так и сторонние рекомендации и требования к дизайну (например, iOS Human Interface Guidelines от Apple), если мы на них опираемся, разрабатывая для этих платформ.

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

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

После формирования прототипа, frontend-разработчики могут работать с ним для описания структуры документов с помощью HTML/CSS и для программирования динамики на JavaScript.

Проработка элементов графического дизайна (UI)

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

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

А дальше что?

А дальше мы продолжаем работать над сервисом/продуктом. Отслеживается статистика и реакция пользователей. Пытаемся понять, как его сделать ещё удобнее и как повысить эффективность: проводим A/B, сплит и мультивариантные тесты — оставляем то, что эффективнее работает. И продолжаем так постоянно — над дизайном сервиса нужно работать и после его запуска. Потому что дизайн продает.

+1
Share
Pin
Like
Send