Read-only: как и зачем мы внедряли его в дизайн-систему
Привет, VC! На связи Настя (продуктовый дизайнер в ecom.tech) и Иван (дизайнер дизайн-систем в ecom.tech). Сегодня расскажем, как мы проектировали и внедряли состояние Read-only: зачем оно нам, как мы искали решение и что в итоге получилось.
Зачем дизайн-системе Read-only
Read-only — это состояние компонента, в котором содержимое доступно для чтения и копирования, но недоступно для изменения. При этом Read-only — не синоним Disabled.
Ключевые отличия Read-only от других состояний:
Default — полностью интерактивный: фокус, ввод, подсказки.
Disabled — визуально и поведенчески «выключен»: нельзя редактировать, кликать или копировать; часто служит признаком временной блокировки. Disabled часто исключается из таб-порядка и может быть скрыт для скринридеров
Read-only — содержимое нельзя редактировать, но удобно читать или копировать (при необходимости). Read-only также доступен для скринридера.
Когда использовать Read-only
- Просмотр данных (read-only режим для документов, профилей, отчётов).
- Ролевые ограничения, когда у части пользователей есть доступ только к просмотру.
- Статусные ограничения, когда объект переходит в статус, при котором редактирование запрещено навсегда или на длительный период.
А в чём проблема?
Если у нас нет готовых Read-only-компонентов, любой «просмотровый» интерфейс приходится собирать вручную. Допустим, нужно отобразить форму из 10–20 полей в режиме «только для чтения». Без Read-only состояний приходится каждый раз пересобирать форму либо из текстовых блоков, либо из альтернативных компонентов. Это лишняя трата ресурсов как дизайнера, так и разработчика.
И раз нет единого решения, каждая команда реализует Read-only по-своему. От этого может страдать консистентность не только в рамках всего продуктового ландшафта, но даже внутри отдельно взятого продукта.
Процесс реализации
Обкатывать будущее решение мы решили в рамках только одной дизайн-системы Rampa (одна из основных наших дизайн систем, на ней основано несколько десятков внутренних сервисов: коммерческих, операционных, HR и др. Десктопная.), и уже после масштабировать на остальные.
Для начала изучили, как задачу с Read-only решают в крупных дизайн-системах: Carbon, Ant, Material Design, Human Interface.
Подробнее всего Read-only состояние описано в Carbon: там есть и документация к компонентам, и отдельно описанный паттерн. На его примере и покажу, что общего у большинства подходов к Read-only:
- Компонент в состоянии Read-only визуально мало чем отличается от его дефолтной версии.
- Наличие информера. Он предупреждает о том, что редактировать контент на странице не получится. Возможно, что необходимость в информере вытекает из первого пункта.
В наших продуктах встречались и другие решения. Мы заметили, что многие дизайнеры просто убирали все интерактивные элементы и оставляли на экране только текст: подписи и значения. Такой подход фокусирует внимание пользователя на данных, упрощает восприятие и делает контент гораздо компактнее.
Наше решение
Изучив существующие на рынке кейсы, и те решения, которые есть внутри наших продуктов, мы собрали финальную концепцию Read-only состояния для дизайн системы Rampa по двум основным принципам:
- Максимум статичности. Компонент в режиме «только для чтения» не должен выглядеть кликабельным. Например, Select превращается из поля ввода с иконками в простой лейбл с текстом — остальное исключается.
- Простое переключение состояний. Мы хотели, чтобы коллеги-дизайнеры могли в пару кликов переключить свою форму в состояние «только для чтения», сохранив структуру страницы и контент.
Но не обошлось без исключений. В предварительной концепции мы предполагали эту механику использовать для Radiobutton и для Checkbox. Но после многократных обсуждений с разработкой пришли к выводу, что такое решение будет болезненным обновлением, поэтому пришлось искать компромисс.
Мы уже писали, что все наши дизайн-системы построены на токенах, и благодаря им нам удалось быстро собрать новые состояния компонентов не только в Figma, но и в коде. Специально для Read-only мы добавили два новых цветовых токена: для шейпов и обводок (они пригодились для Radiobutton, Checkbox и Toggle).
Документация и формирование паттерна
Перед тем как презентовать Read-only дизайнерам, мы обновили документацию Rampa: для каждого компонента добавили описание нового состояния и показали отличие Read-only от Default и Disabled.
Финальный этап перед презентацией Read-only всем продуктовым дизайнерам — обновление документации по каждому компоненту: добавили информацию о новом стейте, отдельное внимание уделили его отличию от Default и Disabled.
Паттерн применения Read-only мы сформировали в виде рекомендаций:
- Исключить интерактивность. Если форма (или страница) доступна только для чтения, убедитесь, что не осталось интерактивных элементов (даже в состоянии Disabled): кнопок сохранения изменений, добавления или удаления полей.
- Read-only vs Disabled. Если поле вообще недоступно для изменений в рамках роли или сценария, используйте Read-only. Если же оно может стать активным (например, при выборе других полей), используйте Disabled — так вы показываете, что блокировка временная.
- Группировка полей. Не размещайте в одной строке редактируемые и Read-only-поля. Это стоит учитывать заранее, например, если одной группе пользователей для изменения доступны все поля, а другой — только их часть.
- Доступно только копирование и чтение скринридером. Read-only не предполагает подсказок по ховеру или всплывающих тултипов. Если нужно пояснить что-то пользователю, можно добавить описание в Description
Внедрение состояния Read-only в нашу дизайн-систему стало важным шагом на пути к созданию более продуманной и удобной экосистемы для наших продуктов. Теперь, когда у нас есть единое решение для отображения данных в режиме "только для чтения", мы можем значительно упростить работу дизайнеров и разработчиков, обеспечивая консистентность и ускоряя процесс разработки. Это позволяет нам сосредоточиться на улучшении пользовательского опыта и развитии фичей.