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

Задача — переосмыслить и создать дизайн-систему в Figma на основе существующих артефактов и наработок.

Вводные

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

• Разработка начала сильно обгонять дизайн.
• Многие решения по краевым сценариям стали приниматься разработчиками.
• Дизайнер тратил много времени на поиск UI и UX багов на поздних этапах.
• Итоговая фича могла сильно отличаться от нарисованного макета.

Отдельной проблемой была сложность каждого компонента:

• Разные темы. В разных темах компонент не только меняет цвет, но и начинает обладать другими визуальными свойствами.
• Несколько размеров. Каждый компонент линейки представлен в трёх размерах.
• Дополнительные стили. Большой набор стилистических вариантов для компонентов-атомов.

Например, одна только кнопка состоит из 150 вариантов компонента:

Было принято решение менять подход — разработать стандарты, правила постановки задач и проектирования.

Задачи

Перед новой дизайн-системой поставили следующие задачи:

1. Оптимизация работы команды на этапах дизайна и разработки.
   Раньше, эти процессы были довольно хаотичны. Дизайнер брал в задачу в работу и изображал примерную реализацию компонента. Многие краевые сценарии не учитывались. Какие-то решения в процессе разработки менялись на ходу. В итоге, разработка затягивалась, фичи резались и итоговый результат сильно отличался от исходной картинки.
2. Автоматизация и консистентность.
   Большой размер и сложность компонентов сильно затрудняли внесение любых изменений в дизайн. Даже небольшие стилистические изменения в базовом компоненте, типа кнопки, приводили к огромному количеству работы со стороны дизайнера. Так как нужно было учесть разные темы, размеры и стили.
3. Консистентность цвета.
   Отдельно стоит отметить проблему с цветом. Многие цвета компонентов в коде рассчитывались с помощью миксинов. Это приводило ко многим проблемам, в том числе, проблемам с контрастностью.
4. Доступность.
   Пользователи продукта стали всё чаще интересоваться, насколько компоненты доступны для разных категорий пользователей. Нужно было сформировать подход, когда дизайнер на этапе проработки компонента учитывает все WCAG 2.2 AA требования.
5. Централизация знаний.
   Многие знания о тех или иных дизайн-решениях нигде не фиксировались. Единственным источником знания были участвующие в работе на фичей члены команды. Нужно было сформировать систему документации.
6. UI Kit.
   Всё чаще стали приходить запросы на UI Kit от пользователей. К тому же, это уже давно было у конкурентов.

Результат

Компоненты в Figma переработаны с нуля

Дизайн компонентов теперь полностью повторяет функционал кодовой реализации. Учтены все редкие сценарии и краевые состояния. Перед отрисовкой каждого компоненты изучались спецификация+API компонента и все сценарии его использования.

Пример реализации компонента Grid

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

Основную сложность представляет его размер:

Компонент достаточно гибок в настройке. Так как пользователи используют его по-разному. Всё это отражено в дизайне.

Чтобы отрисовать такой компонент в Figma, задачу разбили на этапе:

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

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

Отрисованы новые компоненты

Создание новых компонентов включает следующие шаги:

• Обсудить требования с ПМом.
• Исследовать решения на рынке.
• Утвердить список фич.
• Найти грамотный подход по клавиатурной навигации (поддержка A11Y).
• Отрисовать компонент и все его составляющие.
• Описать компонент в дизайн-токенах.
• Проработать сценарии для демо-стендов.

Пример реализации компонента TreeList

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

При подготовке к работе был произведен ресёрч конкурентов, собран список идей и их примерные способы реализации. На каждом этапе приходили синхронизационные встречи с менеджером продукта, разработчиками и другими заинтересованными лицами:

Собранный в Figma компонент учитывает все сценарии использовании и состоянии:

Токенизация

Каждый компонент представлен в разных темах. Руками отрисовать или исправлять компонент в каждой теме очень дорого и ресурсозатратно.

Было принято решение использовать дизайн-токены:

• Чтобы быстро обновлять стили компонента под любую тему.
• Гарантировать единообразие решений.
• Использовать токены как мостик между дизайном и разработкой.

Была проведена большая работа над созданием архитектуры и структуры дизайн-токенов:

Каждый компонент имеет полное покрытие токенами:

• color,
• font-weight,
• letter-spacing,
• line-height,
• border-radius,
• border-width,
• font-size,
• text-transform,
• opacity,
• box-shadow,
• size.

Такой подход позволяет быстро создавать новые темы, просто выставляя новые значения в токенах. Для работы использовался плагин Tokens Studio for Figma. Потому что он позволяет покрыть большое количество типов токенов, в отличии от встроенного Figma Variables.

В итоге, любой компонент в Figma легко протестировать с другими стилистическими настройками. А разработчики могут передавать значения токенов из Figma напрямую в свои стили.

Документирование

Дизайн-система описывает себя тремя основными способами:

• Компоненты и сценарии в Figma. Главная точка входа в дизайн-систему.
• Дизайн-токены. Служат мостом между дизайном и кодом.
• Внутренняя документация. Содержит договоренности и рекомендации по разным аспектам дизайна: правила наименования, структура токенов, правила отрисовки иконок и так далее. Тут же можно найти результаты ресёрчей относящихся к различным дизайн-задачам.

UI Kit

Одним из результатов работы над дизайн-системой стал выпуск UI кита в Figma.

Результаты

• Получилось собрать крепкий каркас дизайн-системы в Figma.
• Сильно улучшилась коммуникация дизайна и продукт-менеджеров.
  • Появились еженедельные созвоны с продукт-менеджерами.
  • Работа над задачами стала идти быстрее, на всех этапах.
• Работа между дизайном и разработкой стала эффективнее.
  • Макеты стали намного подробнее.
  • Дополнительный слой информации передают дизайн-токены.
• Появилась внутренняя документация.
• Пользователи получили UI kit.

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

Со своей стороны, занимался проектированием, развитием и поддержкой UX/UI приложения в связке с ПМом. Разработкой новых фич, улучшение существующих, работой с обратной связью от пользователей.

Веб-приложение

Десктопное приложение

Общий вид

Авторизация

Пак иконок

DevExpress Documentation — одна из самый объемных документации на рынке. Содержит несколько сотен тысяч статей и АПИ. Внутри для её работы создана целая экосистема, включающая в себя множество отдельных компонентов.

Вводная

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

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

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

Задачи

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

• Огромное количество написанных топиков. Разные топики были написаны разными людьми, в разное время. Поэтому, сильно отличались по структуре. Нужно было найти такой подход к стилям, чтобы старые документы не ломали внешний вид страниц.
• Документацию читают с разных устройств. Нужно было сделать документацию такой, чтобы её можно было читать на любом экране.
• Навигация по проекту должна быть удобной. Структура каждого проекта документации древовидна, один проект может быть вложен в другой и так далее. Нужно сделать так, чтобы пользователь понимал, на каком уровне он находится и мог легко навигироваться между документами.
• Поиск по документу должен быть удобным. Документы внутри проекта могут быть большими и сложными. Нужно сделать так, чтобы пользователь мог быстро найти ответ на свой вопрос внутри конкретного документа.
• Сделать разводящую страницу по проектам. Новая система документации собирает все проекты в рамках одного сайта. Важно было сделать страницу, где пользователь может выбрать нужный ему проект.
• Содержимое документа может варьировать от версии продукта и его платформы.
• Совместно с техническими писателями подготовить гайдлайны по оформлению топиков.
• Учесть оффлайн документацию. Часть пользователей, в свете специфики бизнеса, используют активно оффлайн версию документации. А именно, CHM. Поэтому, нужно было подготовить стили для оффлайн документации. Учитывая, что CHM поддерживает CSS уровня Internet Explorer 7 (и то не всегда) — это было очень непростой задачей.
• Поддержать интеграцию с саппорт-центром. Сегмент пользователей читающих документацию и создающих тикеты в саппорт-центре тесно связан. Важно было найти такое решение, чтобы пользователь имел возможность создать тикет прямо из документации, если ему не понятен какой-то из топиков. И наоборот, если ссылку на топик дал сотрудник саппорт-центра, то нужно иметь возможность дополнительно уточнить у пользователя, помог ли ему этот топик.
• Сделать документацию доступной. Сайт документации должен удовлетворять требования A11Y, чтобы им было удобно пользоваться всем пользователям.

Результат

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

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

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

Примеры реализации

Разводящая страница

Доступность со всех устройств

Доступность

Система поддержки пользователей. Включает различные информационные ресурсы: вопросы от пользователей, статьи в базе знаний и истории версий.

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

Вводная

Система состоит из трёх основных порталов:

• Клиентский портал
• Внутренний портал для сотрудников
• Админ-панель

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

Клиентский портал

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

Перед редизайном ставились следующие задачи:

• Снизить нагрузку на саппорт-инженеров. Помочь пользователям находить ответы самостоятельно, если на вопрос уже отвечали ранее или решение описано в документации.
• Улучшить UX. Накопился список проблем, которые нужно было решать:
  • Пользователи выбирают неверный продукт при создании вопроса. DevExpress разрабатывает и поддерживает десятки продуктов. У каждого продукта могут быть разные платформы и версии. Иногда важно знать, какая ОС установлена у пользователя, каким IDE он пользуется. Нужно было сделать так, чтобы у пользователя не возникали проблемы при выборе нужных значений. Помочь ему на этом пути.
  • Возникают проблемы при форматировании текста. Пользователи приходят в поддержку с техническими проблемами. Описание проблемы содержит куски кода или целые архивы с проектами. В старой версии сайта пользователи путались в текстовом редакторе и отправляли не отформатированные куски куда, которые сливались с обычным текстом. Также, пользователи не всегда понимали как аттачить файлы. Всё это приводило к дополнительной нагрузке на саппорт-инженеров.
  • Пользователи не замечают уведомления об ответах в их тикете. Проблема касалась как веб-интерфейса, так и уведомлений приходящих пользователю на почту. Пользователи либо не замечали уведомления, либо не понимали к чему они относятся, либо ранее отключали уведомления и забывали об этом. В связи с этим, среднее время на решение таких тикетов значительно увеличивалось.
  • Клиенты из одной и той же компании не видят вопросы друг друга. Большинство клиентов предпочитает оставлять свои вопросы приватно. Чтобы их могли видеть только саппорт-инженеры. Из-за этого возникала проблема, что вопросы становились приватными полностью и их не могли видеть даже сотрудники одной и той же компании с разных аккаунтов.
  • Неудобные фильтры. Пользователи, что на странице со списком публичных тикетов невозможно ничего найти. Фильтров мало, а то, что есть не всегда работает очевидным образом.
• Переосмыслить встроенный инструмент “Version History”.
• Улучшить аналитику.
• Освежить внешний вид.

Подготовка к работе

Перед началом работы над редизайном была проведена подготовительная работы. Подготовлен общий план работы и проведены встречи со всеми заинтересованными лицами. Был подготовлен итоговый бриф проекта.

Часть работ, которые были проведены на этом этапе:

• Анализ текущего дизайна. UX-тестирование текущего сайта, поиск проблем.
• Ресёрч конкурентов. Изучение как прямых конкурентов, так и решений крупных платформ. Например, Zendesk, Freshdesk, Zoho Desk.
• Сбор и анализ существующего фидбека. За годы работы, накопилось большое количество тикетов, комментарием и другой обратной связи касаемо работы портала. Была проведена большая работу по сбору всей это информации в один документ, её анализу и приоритизации.
• Сбор информации от саппорт-инженеров. Инженеры поддержки активнее всего общаются с пользователями и знают детали и проблемы, которые могут быть неизвестны и неочевидны другим членам команды.
• Изучение текущих данных аналитики и список того, что хотим собирать ещё в новом дизайне. Для работы с данными использовались: Google Analytics (+Google Tag Manager), Matomo, внутренние инструменты.
• Сбор требований от заказчиков и всех заинтересованных лиц.
• Подготовка брифа. Описание проблем, целей и задач. Развёрнутый ответ на вопрос, что мы будем считать успешным редизайном.

Процесс

Работа над сайтом строилась 2-4 недельными спринтами. В конце каждого спринта проводились синхронизационные встречи с заказчиками.

В начале работы над дизайном была согласована общая концепция. Отрисованы низко детализированные прототипы с решением основных UX проблем. Найден общий подход к внешнему виду.

Чтобы работа над новым дизайном была эффективной и обратная связь поступала как можно быстрее был принят рад мер:

• Продукт менеджер продукта показывал прототипы и просто картинки небольшой выборке самых активных и заинтересованных пользователей саппорт-центра. Благодаря этому получалось очень быстро собрать много полезной информации, которая помогала намного быстрее замечать точки роста.
• Тесное общение с разработчиками. Так дизайн значительно обгонял разработку, нужно было сразу учитывать технические ограничения. Для этого проводились постоянные встречи между разработчикам, заказчиками и дизайнером. Так мы оценивали техническую сложность каждой фичи и на основе этого принимали решение, будем мы брать её в работу или нет.
• На этапе, когда появилась первая работающая версия сайта, его стали тестировать сотрудники. В первую очередь, к тестированию подключались саппорт-инженеры. На этом этапе было собрано большое количество фидбека как по техническим багам, визуальным багам, так и просто по неудачным UX-решениям.
• На следующем этапе снова к фидбеку снова были подключены активные клиенты. Которые были готовы дать развёрнутый фидбек.
• На одном из финальных этапов сайт стал доступен для всех пользователей, но в виде бета-версии. При этом, каждый пользователь мог вернуться к старой версии сайта. Со временем, пользователей вернувшихся на старый сайт становилось меньше. Также, мы старались собирать фидбек от таких пользователей. Чтобы понять, почему они вернулись на старую версию сайта.
• К новой версии сайта была прикручена продвинутая аналитика.

Примеры реализации

Релевантные подсказки при создании тикета

Упрощена навигация по дискуссии с ветвистой иерархией

Обновлены инструменты фильтра на странице со списком тикетов

Сделана мобильная версия под разные размеры

Внутренний портал и админ-панель

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

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

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

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

Так как решения внутренние, вдаваться в подробности и показывать скриншоты я не могу.

Результаты

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

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

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

• Уменьшилась нагрузка на саппорт-инженеров.
  • Пользователи стали чаще находить решения самостоятельно: улучшен движок поиска, предлагаются релевантные ссылки при создании тикета, улучшена фильтрация.
  • Пользователи стали реже ошибаться с выбором платформы/продукта и других деталей при создании тикета.
  • Во внутреннем портале появились инструменты, помогающие саппорт-инженерам быстрее отвечать на тикеты, ответ на которые уже давался ранее.
• Не отформатированные тикеты появляются гораздо реже. Решилась проблема с тем, что пользователи не понимали, как отправлять аттачи.
• Уменьшилось количество проблем, когда пользователи не получают уведомления вовремя.
  • В настройках уведомлений появился отдельный чекбокс, для получения уведомлений от саппорт-центра (раньше был единый чекбокс, для всех почтовых рассылок).
  • Даже если пользователь отключил уведомления от таких рассылок, то саппорт-инженер будет об этом знать. И, если у пользователя возникают с этим проблемы, подсказать варианты решения.
  • Сами почтовые уведомления стали понятнее, появилась возможность подключить браузерные уведомления.
  • Появилась возможность подписать на рассылку на любой тикет со страницы этого тикета.
• Более точечно настроена аналитика.
  • Саппорт-инженер теперь может видеть карточку пользователя с историей посещений тикетов и документов в документации. Так инженер поддержки сразу может понять, какие ссылки есть смысл советовать, а какие — нет, так как пользователь их уже посещал.
  • Добавлены ивенты на целевые действия.
  • Созданный внутренние дашборды с анализом различных данных, необходимых для оценки поступаемого количества тикетов и оценки эффективности саппорта.
• Поиск по тикетам стал гибче и проще.
  • Были докручены мета-теги, чтобы тикеты лучше искались поисковиками.
  • Переосмыслены фильтры, добавлены готовые пресеты и возможность подписаться на созданный фильтр.
  • Оптимизирована внутренняя страница поиска.
• Сделана мобильная версия клиентского портала.