18 апреля в 18:30

Создание Tinkoff Design System. Первые шаги

В цикле статей Tinkoff Design System я расскажу, как мы строим нашу дизайн-систему по методологии Atomic Design.


Необходимость дизайн-системы


Дизайн-система — довольно широкое понятие и применяется в разных сферах: от полиграфии до архитектуры. Для пользовательских интерфейсов она включает в себя:

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

В небольших компаниях с одним продуктом можно обойтись без дизайн-системы. Одно небольшое приложение, один дизайнер, небольшой Sketch-файл, в котором можно всё увидеть.
Но что делать, если у вас больше десяти продуктов, сотни Sketch-файлов, а в дизайн-команде больше десяти человек? Нужно вводить правила построения интерфейсов и распространять их среди команд дизайнеров и разработчиков. Иначе новые фичи некогда будет придумывать: два дизайнера нарисуют разные отступы для одного элемента, и всё время уйдет на приведение дизайна к одному знаменателю…

Отсутствие дизайн-системы ведет к:

  • десинхронизации внутри дизайн-команды и между командами дизайнеров и разработчиков;
  • увеличению времени обучения новых участников дизайн-команды;
  • несостыковке дизайн-макетов и верстки;
  • постоянному исправлению созданных макетов;
  • медленному внедрению новых фич.

Система хороша тогда, когда она работает.

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

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


Для создания нашей дизайн-системы мы выбрали методологию Atomic Design, которую в 2013 году предложил Брэд Фрост (http://bradfrost.com/blog/post/atomic-web-design/). Идея методологии пришла из химии: атомы собираются в молекулы, молекулы — в организмы, а организмы собираются в страницы по заданным правилам (шаблонам, лэйаутам).

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

  • Контроль использования элементов. Четкое разделение на атомы, молекулы и организмы позволяет следить, где и какие элементы используются, из каких атомов и молекул состоят организмы.
  • Отличная читаемость и консистентность кода. Атомарный дизайн — заранее подготовленные атомы и молекулы, используемые на разных страницах сайта или приложения. Поэтому элемент редко бывает продублирован или изменен.
  • Не надо постоянно думать о пикселях. Заранее подготовленные элементы уже отвечают заданным требованиям, нет необходимости проверять новые сверстанные страницы на pixel perfect design. Все элементы уже использовались ранее.
  • Быстрое создание страниц. Созданные наборы элементов (атомы, молекулы и организмы) позволяют быстрее собирать страницы дизайнерам и разработчикам.
  • Компонентный апдейт, тестирование и внедрение. Атомарный дизайн имеет модульную структуру. Мы можем изменить элемент в одном месте, протестировать его и распространить апдейт на все страницы, где этот элемент используется.

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

Перед нами стояла непростая задача: понять, из каких атомов и молекул состоят работающие элементы. Мы разбивали большие элементы на элементы поменьше, пока не дошли до элементов, которые разбить на части нельзя.

Разбивайте до тех пор, пока можно разбивать.

Мы разобрались с атомами и молекулами. Перед нами встал следующий вопрос: как сделать все организмы универсальными, чтобы мы могли применять их в любом продукте?

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

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

Любая методология — это только фундамент.

Мы ввели дополнительный продуктовый уровень в методологию атомарного дизайна и получили гибкую структуру, в которой все продукты состоят из одних и тех же атомов и молекул. При этом во всех продуктах есть общие организмы (Base Organisms). А есть уникальные — те, которые относятся к отдельно взятому продукту (Unique Organisms). Поэтому для каждого продукта созданы собственные шаблоны, по которым собираются страницы из общих и уникальных организмов.

Синхронизация. Дизайн и разработка


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

Дизайнеры и разработчики — это одна команда.

Нужно достичь полной синхронизации в:

  • базовых принципах: текстовые стили, цвета, сетка, размеры и типы иконок — всё должно быть идентично;
  • нейминге элементов: должна быть принята единая система нейминга. Если в дизайне это «btn_alert», значит, и в коде это «btn_alert»;
  • количестве элементов: если в дизайн-макете всего два варианта кнопки (primary и secondary), то и у разработчиков должно быть всего два варианта кнопки;
  • Состоянии элементов: у каждого элемента есть определенное количество состояний (default, hover, pressed, disabled и так далее). Количество состояний должны совпадать для каждого элемента;
  • внешнем соответствии: верстка элемента должна соответствовать дизайн-макету;
  • лэйаутах: элементы идентично располагаются и ведут себя на страницах продукта или приложения;
  • версионность: разные версии дизайн-системы поддерживаются и разработчиками, и дизайнерами.

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

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


Для каждой системы создается документация. Неважно, как это будет сделано — главное, это должно быть записано и согласовано. Вы можете использовать Google Документы с картинками или собрать с разработчиками живой GUI с версткой. Создание документации — это долгий процесс, но на выходе получится огромная библиотека знаний, которая будет ежедневно помогать дизайнерам, разработчикам и менеджерам.

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

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

Можно добавлять в документацию то, что считаете необходимым.

Что получится в итоге?


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

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

В следующих статьях я расскажу о создании UI Kit, контроле версий и необходимых для успешной работы дизайн-системы регламентах.
Автор: @iamnickparker
Tinkoff.ru
рейтинг 132,11
Самый большой онлайн-банк в мире
Похожие публикации

Комментарии (29)

  • +2
    А разве так кто-то не делает?
  • +8
    Не увидел статье ничего про скорость работы.
    На макбуке про 2015 года от нажатия на кнопку «Войти» до появления боковой панели с формой логина проходит около секунды. От ввода в адресную строку tinkoff.ru до попадания на форму оплаты телефона (с использованием шаблонов конечно) с легкостью проходит до полуминуты сумарно.
    Пользоваться же сайтом на стареньком (относительно) компьютере с intel celeron поколения Ivy Bridge вообще ужасно. Часто от нажатия символа в строке ввода например телефонного номера до появление самого символа с легкостью проходит больше секунды.

    Зато по экрану красиво летают какие-то бесполезные кружочки в шапке.

    Мало того. Иногда банк просто не логинится как вот в данный момент и пишет Timeout of 3000ms exceeded (Код ошибки: TAPI, undefined)
    • +3
      Полностью поддерживаю, скорость работы просто ужасная и мой комп порвет макбук описанный выше, кому нужны всё эти анимашки, вы вправду верите, что вашим клиентам именно это нужно? А если еще добавить медленный канал, сталкивался когда был за бугром, плохая поддержка браузеров отличный от хрома в них банально не пишет код ошибки, знаю это ибо более чем пол года назад, когда не работали переводы на карту, меня попросили использовать другой браузер и из нескольких только там было хоть какое то сообщение об ошибки, а не банальное неактивная кнопка перевода.
    • +2
      Пользуясь случаем, тоже предаю лучи негодования по поводу скорости работы. Нормальное приложение под WP появилось, сравнительно недавно. А до этого приходилось с телефона пользоваться сайтом. Так, чтобы перевести деньги с накопительного счёта на карту уходило 10-15 минут.

      А в статье вообще какие-то общие слова из которых я так и не понял, или это очевидные вещи названные красивыми словами, или за этим действительно что-то кроется полезное. И примеров нет.

      И кто-нибудь может объяснить, что за мода вытащить на пол-экрана баннер с парой кнопок, а весь функционал распихать по краям? Это и есть «атомный» дизайн?
    • 0

      Бесполезных кружочков в шапке уже с полгода примерно нет.

      • 0
        Но быстрее не стало :) Наверное программисты много кушают.
    • +2
      Такое чувство, что банки в последнее время соревнуются в том, кто сделает свой сайт «тормознее». Тинькофф Банк, Альфа Банк, ВТБ 24…
      • +1
        Вот только Тинькофф развивает свои технологии лично, а Альфа, если верить плашке нескромного размера в футере, отдалась аутсорсу.
    • 0
      При всем при этом одно время в консоль писались ошибки со скоростью 100-150 в секунду, что «добавляло» уверенности переводить этим сервисом свои деньги ))))
    • +1
      На адресе my.tinkoff.ru можно найти старый интерфейс интернет-банка, без обилия анимаций.
      • 0
        Там тоже не всё гладко, только на вскидку не вспомню, но именно через старый вариант получилось в итоге сделать нужную операцию.
  • +2
    Ну так выложите ее на гитхаб, все сайты(ну может не все, но часть точно) сразу станут в стиль тинкова как когдато все ставли в стиле твиттер
  • +1
    Являюсь вашим клиентом. Приложение действительно хорошо выглядит.

    Есть в мобильной версии UX проблема, которая заключается в том, что крайне сложно найти Спец-предложения и категории кеш-бека. Не только я это заметил, но многие из моих знакомых, которые также являются вашими клиентами. Я по старой привычке смотрю эти данные в веб-версии.
  • +2
    Пишите поконкретнее, почитаем. В том числе, про оптимизацию кода, про систему сборки и непосредственно генерацию страниц — интересно было бы посмотреть на детали реализации и выбранные тулзы (собственноручно жопиленные или уже существующие).
    • 0
      Я извиняюсь — «допиленные».
      • +9
        Не, так тоже хорошо.
        • 0
          Вы сделали мой день! Впрочем, и ночь тоже…
    • 0

      Есть обзорная статья, написанная чуть меньше года назад https://habrahabr.ru/company/tinkoff/blog/303580/

  • +1
    Спасибо за статью, всегда интересно узнать о практической стороне таких концепций. То есть, аналогия понятна и более ли менее знакома, однако, по своему опыту сталкивался часто с тем, что суммы частей не всегда дают нужное целое. Собственно, одна из причин почему в БЭМ есть последняя буква «М» — модификатор. В известной мне (по работе) дизайн системе, у каждого атома начинают появляться вариации, что уже ломает красивую аналогию. Как вы решаете данную проблему?

    ЗЫ: Будем ждать перехода на субатомный уровень, квантовые веб-интерфейсы и Schrödinger box layouts =)
    • 0

      Вся практика будет в следующих статьях. Хранение и распространение элементов, версионность и так далее)

  • +1
    Не увидел собственно ответа, как осуществляется синхронизация дизайна и верстки. Это самое сложное. Вот потребовалось передвинуть кнопку на одном из экранов — можете описать процесс, типа «дизайнер правит макет, скидывает правки девелоперу, девелопер вносит правки»?
    • 0

      Конечно, эта статья была вводной. В следующих статьях будут подробнее рассмотрены все процессы)

  • +5
    У меня к вашему интерфейсу есть одна претензия: пока все данные асинхронно не подгрузились, вы показываете «ничего нет». Вот был у человека вклад у вас в банке на миллион рублей. Заходит он в банк клиент, дальше хронология событий:

    загружается интерфейс
    интерфейс выводит «нет никаких счетов или вкладов»
    Человек седеет/срёт кирпичами (в зависимости от темперамента)
    подгружается информация о счетах
    Информация о счетах показывается
    Человек думает, что ему делать с сединой (или куда девать кирпичи)
  • +1
    Я так понимаю, что данная статья вводная и, большей частью, состоит из выписок из книги. К сожалению не многие компании понимают важность создания подобных систем. Да и не хотят тратить деньги на их разработку. Они работают по старым понятиям и меркам. Это приходится ломать. Но ломаются консервативные взгляды тяжело. Я бы добавил, что необходим контроль за итоговым результатом. И очень сильный контроль. В моей практике были случаи когда другие дизайнеры брали киты и документацию выдавая на выходе продукт который не соответствовал требованиям. Очень хотелось бы в будущих статьях видеть примеры, как это все работает у вас. Например, недавно смотрел небольшое видео о том, как взаимодействуют дизайнеры и разработчики в Альфа-банке.
    • +1
      Лучше не смотрите такие видео — всё равно у них там бардак…
    • 0

      Практика и более подробный разбор будут в следующих стаьях)

    • 0
      можно ссылку на видео? интересно посмотреть
  • 0
    Спасибо за статью!

    Расскажите, как вы держите sketch-файл с дизайном в актуальном состоянии?

    Например, над дизайном продукта работает несколько дизайнеров. Оба одновременно делают задачи, связанные с проектом. Не представляю, как можно мержить .sketch-файл? Если только вручную. Было бы здорово, если расскажите как это можно автоматизировать (если можно).

  • 0
    Для создания нашей дизайн-системы мы выбрали методологию Atomic Design, которую в 2013 году предложил Брэд Фрост (http://bradfrost.com/blog/post/atomic-web-design/). Идея методологии пришла из химии: атомы собираются в молекулы, молекулы — в организмы, а организмы собираются в страницы по заданным правилам (шаблонам, лэйаутам).

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

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

Самое читаемое Дизайн