Дизайн-система для рентген-оборудования

01Что было до

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

1. 01Разные визуальные приёмы внутри одной компании
2. 02Печатный мануал для медицинских работников как точка входа в интерфейс
3. 03Каждый компонент пишется разработчиками вручную по PNG-макетам
4. 04Дизайн-долг растёт, провести быстрый аудит невозможно

02Дизайн-аудит

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

03UI-кит и переход к системе

Вместе со вторым дизайнером сделали редизайн первых экранов и утвердили направление у стейкхолдера. Дальше я собрала UI-кит, который закрывал все компоненты этих экранов. Во время работы я осознала, что необходимы масштабные изменения, поэтому решила утвердить проект дизайн-системы. Провела презентацию перед руководством, в которой рассказала о необходимости создания единой дизайн-системы для ускорения производственных процессов и масштабирования бренда. Далее я пообщалась с разработчиками, объяснила, как система может положительно повлиять на их рутинные задачи, и почему производству нужно уйти от легаси. Были те, кто поддержали идею, но некоторые всё-таки настаивали на привычной работе. Мною было принято решение: начать работу над ДС, перевести несколько экранов полностью на компоненты, предложить положительно настроенной команде разработки провести тест-драйв и, если всё пройдет хорошо, презентовать данный переход вместе с ними скептически настроенной команде.

1. 01Редизайн первых экранов, утверждение направления
2. 02UI-кит на полное покрытие компонентов
3. 03Защита перехода от кита к системе перед стейкхолдером

Часть набора

Система на реальном экране

БЫЛО СТАЛО

• Те самые первые экраны, по которым собирался кит
• Кнопки, поля и селекты на них — уже из библиотеки, а не нарисованные заново
• Подробный разбор этого редизайна — в кейсе 02

04Компоненты через вайбкодинг

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

1. 01Причина: нехватка разработчиков и долгий код-аудит
2. 02Рутина по заводу компонентов — на нейросети
3. 03Решения и правила остаются за дизайном