Конспект по дизайн-системам

by Hissing Booth
Конспект по дизайн-системам

Терпеть не могу сумбур, равно как терпеть не могу терять какую-то важную инфу, статьюшечки и прочее. Может так поможет.



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

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

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

Создаем перечень всего вышеописанного для верности.

Основа:

1 — Инструменты, используемые на данный момент,

2 — Нейминг папок, файлов, слоев, даже систему названий символов и стилей в Figma.

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

4 — Руководство по стилям.


Инструменты

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


Нейминг:

1.1 Папки

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

Приложу скрин статьи на ux пабе по теме, чтоб не забыть:

*ну не знаю, я пока в поисках своего идеального решения

1.2 Файлы

Тут тоже предпочту обсудить и решить с командой - особенно с фронтом. Если использовать Фигму и Реакт в тесной связке, то нейминг в Фигме должен быть аналогичен неймингу в коде, а значит - просто решить, что мы там используем. БЭМ или своё-другое.


Насую примеров из всё той же статьи:

Иконки: icons/interface/normal/instance_name (использование / при экспорте элементов поможет автоматически распределять по папкам).

«icons/interface/state/name of instance "

«Primary-Accent/(colourname) «

Символы:

Buttons/Btn50px/teal/icon-right/hover



Все еще немного сырая, зато моя

1.3 Документация

Если есть необходимость создавать документацию собственными силами, то пока наверное это будет ГуглДокс. Как только я упорядочу весь этот хаос знаний, будет значительно легче получить более конкретное представление о возможностях и необходимостях.

Пока, конечно, я все же считаю эталонным такой способ - как у Альфа Банка, у Мэйла, да много у кого.


Руководство по стилям

2.1 Интерфейсная сетка

К примеру, 8 dp. Она, кстати, используется в Дизайне Гос. систем РФ.

Сеточная система 8pt. Используйте инкременты 8 для размеров и отступов элементов на странице. Это означает, что любая заданная высота или ширина, граница или отступ должна быть кратной 8.

2.2. Шрифт


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

Сначала вы выбираете коэффициент пропорции, затем базовый размер текста, например, 16px. После этого вы умножаете базовый размер на коэффициент для получения последовательной шкалы размеров: 16px, 26px, 42px, 68px, 110px.


Шкала шрифтов Diatonic

Модульная шкала

«Модульная шкала — это последовательность чисел, которые связаны между собой определенным образом. Используя золотую пропорцию, например, мы сможем получить модульную шкалу, умножая каждый предыдущий размер на 1.618, или деля на 1.618, чтобы получить предыдущий размер».

2.3. Мудборды

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

2.4. Библиотека паттернов и Флоу

Атомарный дизайн

Проще некуда реализовать в Фигме. Библиотека стилей, компонентов, все это может быть сразу же перенесено в продакшн, возможность работать командой над одним продуктом в рамках одного документа. Еще бы попробовать командную работу в Фигме.. Ну да ладно, соло тоже очень даже недурно.

Для юзер флоу пока не нашла себе идеального сервиса/программы. На данный момент использую Фигму с шаблонами uxflow, буду искать дальше. Возможно проще всего действительно сделать удобный фигма-шаблон и не множить инструменты.


Продукт и все-все-все

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

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

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

  • Как мы общаемся с пользователем - письменный стиль, особенные обороты, тут можно вообще отдельно по пунктам все расписать.
  • Как мы приветствуем польз-ля, как мы прощаемся с польз-м.
  • Какие местоимения используем и как формулируем базовые интерактивные конструкции ("Благодарим за ваш отзыв! Модерация займет 24 часа").
  • Особенности изображений - тут уже не технические подробности, а смысловые. К примеру, мы не используем изображения свиней, петухов и лакрицы (потому что лакрица отвратительна).
  • Особенности движения - тайминг, скорость прокрутки, скорость анимаций и проч. интерактивные штучки.
  • Ко всему прочему можно составить список коммуникаций с пользователем и прописать правила для отдельных вещей, к примеру, имейлов. В интернет-магазинах обычно развит имейл-маркетинг, и важно не переутомлять пользователя и не надоедать ему, чтобы получать стабильную прибыль и чтоб все были довольны.


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


Статья на uxпабе


January 14, 2019
by Hissing Booth