Pull to refresh
0
True Engineering
Лаборатория технологических инноваций

Как мы делали экосистему – единый «язык» дизайна для front end десятков связанных систем

Reading time 10 min
Views 9.7K
В этом посте мы расскажем о том, как учились разговаривать с пользователем на «языке» дизайна UI/UX и пришли к необходимости создания единой экосистемы для разных приложений одного заказчика. А также о том, какие технологии в этом помогли.

Что мы подразумеваем под единой экосистемой? Это комплекс разных IT-решений, веб- и мобильных приложений, объединенных единым «языком», на котором они разговаривают с пользователем. Такой язык есть, например, у всех продуктов Microsoft или у всех устройств Apple. Какое бы приложение одного и того же производителя вы не открыли, оно будет повторять логику своих «сородичей», показывать вам знакомые иконки.
Для компаний, создающих цифровые продукты, единая экосистема – ключевое конкурентное преимущество. Для нецифровых компаний, которые переходят «в цифру», создание аналогичных единых экосистем становится необходимостью, поскольку дает много преимуществ. В первую очередь, конечно, обеспечивает пользователям однородный UX и UI во всех системах, облегчает поддержку и обновление систем, повышает конверсию и удовлетворенность клиентов.
Разработка такой экосистемы стала для нас итогом длинного пути, о котором мы и расскажем.

1) Начнем с теории. Зачем нужен единый «язык» дизайна для разных связанных систем


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

Проблема с UX


Неоднородность неудобна для пользователей. Когда одному и тому же человеку приходится использовать несколько систем с неоднородным UX и в каждой из них элементы управления ведут себя немного по-разному, неизбежно возникают “трения” (frictions), количество которых и характеризует UX как хороший или плохой. Такого рода “трения” воспринимаются пользователем очень болезненно, потому что не дают работать “в потоке”.
Неоднородность неудобна и самому владельцу, потому что разнородные системы более сложны и неуклюжи в обновлении. Грубо говоря, задача «сделайте мне такую же кнопку» в другом приложении решается более сложно из-за того, что в этом другом приложении может быть реализована вообще своя логика, другой UI.
Вот пример небольшого отличия в UX между двумя веб-приложениями, которыми пользовались одни и те же люди. Отличие небольшое, но, тем не менее, раздражающее пользователя.





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

Проблема с UI


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


Каталог METRO:


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

2) От красивых картинок к созданию экосистемы



Этап 1. Красивые картинки


Первым этапом на пути к созданию по-настоящему удобных интерфейсов стала борьба с “красивыми картинками”, которые не выполняют полезной функции. На заре становления принципов работы с интерфейсами у нас встречались ситуации, когда дизайнеры предлагали решения, которые были правильными только с точки зрения требований графического дизайна. Но то, что хорошо для графического дизайна, порой для UX-дизайна просто смерть. Можно нарисовать фееричную загогулину, которая будет приводить в творческий экстаз дизайнера, но при этом отвлекать пользователя от кнопки «Оплатить» и загубит всю страницу. Поэтому в нашей работе ключевым приоритетом стала функциональность каждого элемента.

Этап 2. Проактивный дизайн


На следующем этапе мы поставили задачу сделать дизайн проактивным, направляющим пользователя, помогающим быстро найти нужную опцию, по факту перейти к собственно UI/UX-дизайну.
Один из примеров проактивного дизайна – использование ассоциаций из реальной жизни, которые подсказывают, например, какую нужно ввести информацию. Не каждый пользователь интернета сразу вспомнит, что такое CVC-код, но всем понятно, что такое «три цифры на обороте карты», поэтому на страничках онлайн-оплаты размещают изображение банковской карты.



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


Этап 3. Создание собственного «языка» дизайна


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

3) «Язык» дизайна: Основные принципы


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

1. Единое расположение ключевых элементов управления в разных приложениях одной экосистемы.


Чтобы пользователь быстро ориентировался, “выход”, “помощь”, “имя пользователя” всегда должны находиться в одном месте на сайте, в мобильном приложении и т.д.
В нашем UI KIT всем разнообразным вариантам хедера посвящен целый раздел. И наглядно видно единообразие и преемственность.


Аналогично “запротоколировано” расположение любых информационных блоков:

  • Страница с боковым меню
  • страница со списком в основной части
  • Страница с большой формой
  • Страница с большой формой без шагов
  • Страница с большой формой с шагами
  • Страница с поисковой формой
  • и т.д.


2. Единые обозначения для типовых данных внутри каждой экосистемы.


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



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



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


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



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



Мы пришли к пониманию того, что пиктограммы зачастую не облегчают пользователю жизнь, а заставляют играть в «угадайку». 10 лет назад было очень популярно рисовать пиктограммы в интерфейсах. Это было настолько общераспространенной практикой, что пользователи считали неизбежным злом необходимость «изучать» новое веб-приложение и запоминать, что стоит за той или иной пиктограммой. Однако на практике есть всего несколько десятков пиктограмм, которые абсолютное большинство пользователей интернета понимают однозначно, например, крестик в значении “закрыть” или знак больше в значении “листать дальше”
Мы, конечно, тоже в свое время пробовали для каждой опции придумывать пиктограмму:


Но догадаться, что стоит за каждой из них, можно было только благодаря всплывающим подсказкам:




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

И список таких пиктограмм-иллюстраций четко определен в UI KIT.



5. Всегда расставляем акценты одинаковым образом для разных систем.







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

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


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





4) Живое воплощение: UI_Kit_библиотека для экосистемы продуктов заказчика


UI Kit


Практическим воплощением принципов единства экосистемы стало создание единого UI Kit для всех приложений одного из наших заказчиков. Для типизации всех элементов интерфейса наши дизайнеры провели анализ всех сделанных ранее для заказчика проектов и спроектировали UI Kit, основанный на фирменном стиле заказчика, который будет актуален в ближайшие несколько лет. В нем собраны все типовые страницы, элементы управления и их возможные состояния, а также полный сет необходимых иконок. При проектировании UI Kit’а ключевым моментом было обеспечение единого UX для всех систем.
Фактически UI Kit – это продолжение бренд-бука заказчика, только для цифровых носителей. Он позволяет выполнять те же задачи, что и обычный бренд-бук: повышать узнаваемость бренда, создавать определенный образ компании.
На основе UI Kit можно делать любые новые или дорабатывать старые приложения. Дальнейшие проекты дизайнеры строят на основе данного каталога, продумывая лишь уникальные для конкретного проекта вещи. Как следствие, дизайнер теперь больше времени тратит именно на проектирование приложения, проработку вопросов эргономики и usability, а не занимается стайлингом.
Ниже примеры элементов в UI Kit:





Важная особенность UI Kit’а в том, что он не только регламентирует, какие элементы должны быть обязательными, но и оставляет пространство для творчества, сохраняя единство стиля и однородность UX.
Вот пример новогоднего оформления с сохранением однородности UX.







Теперь разные системы выглядят более предсказуемо и понятно с точки зрения пользователя.
Было — стало:





От дизайна к разработке


Естественно, что на разработке нового дизайна дело не закончилось. Спроектированные дизайны еще нужно внедрить в конечные приложения. А единая концепция дизайна означает, что и в коде от проекта к проекту будет много общего. Такой код можно написать один раз, сэкономив время на внедрение.
Помимо экономии времени на внедрение, такой подход имеет и еще одно преимущество. UI Kit – это не железобетонная плита и его обновление будет продолжаться и после того, как реализованы конечные системы. Иногда даже после того, как они ушли в фазу сопровождения из фазы активной разработки. Поэтому важно сделать так, чтобы разработчики имели возможность узнавать об обновлениях UI Kit, понимали, что именно изменилось и насколько сложно будет внедрить эти изменения в их проект, могли оценивать и планировать работу по внедрению этих изменений.
И последний момент. Помимо изменений в дизайне возможны и ошибки в css, воплощающем спроектированный дизайн. И эти ошибки хорошо бы делать и исправлять в одном месте, а не в каждой системе.
Решение данных вопросов достаточно очевидное — создать библиотеку, реализующую концепции разработанного дизайна, что мы и сделали.

Если не усложнять и называть вещи своими именами, то мы просто разработали тему для bootstrap и упаковали ее в приватный npm-пакет. Далее, разработчики устанавливают ее “поверх” bootstrap и получают нужный им дизайн.



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



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

Итого



  1. Мы научились создавать собственный «язык» дизайна, адаптированный под специфику экосистемы ИТ-сервисов заказчика.
  2. На опыте ИТ-сервисов конкретного заказчика превратили зоопарк в единую экосистему. Разработали единую концепцию UX, что позволит минимизировать “трение” при работе с нашими системами.
  3. Создали UI Kit, который позволяет заказчику поддерживать и развивать все свои системы в едином стиле, а для наших дизайнеров сокращает временные затраты при работе над дизайном.
  4. Реализовали распространение обновлений библиотеки в виде npm-пакета, что в сочетании с грамотным версионированием помогает исправлять огрехи и актуализировать дизайн безболезненно и изолированно на каждом проекте.
  5. Исчерпывающе проиллюстрировали работу библиотеки через демо-приложение, что позволяет разработчикам нередко обходиться не только без дизайнеров, но даже без верстальщиков.

А дальше…


Разрабатываем UI Kit для следующего нашего заказчика и продолжаем учиться говорить с пользователями в терминах реального мира и делать наш софт продолжением этого мира, простым и удобным инструментом.
Tags:
Hubs:
+4
Comments 5
Comments Comments 5

Articles

Information

Website
www.trueengineering.ru
Registered
Founded
Employees
101–200 employees
Location
Россия