System design что это
Netflix за 45 минут: Краткий рассказ о system design-интервью, чего ожидать + подборка полезных ссылок
В нашем блоге мы много пишем о построении карьеры в ИТ в разных странах, поиске работы, отличиях в процессе собеседований крупных компаний. В сегодняшней статье мы пойдем дальше и раскроем тему так называемых интервью по system design – это один из этапов собеседований известных технологических компаний, на котором отсеиваются многие кандидаты.
Итак, что такое system design и как пройти интервью такого типа?
Что это такое
В современном мире ИТ-системы стали крайне сложными. Каждая новая «фича» в продукте должна соответствовать множеству требований, всегда есть ограничения, между которыми приходится балансировать инженерам. То, что для обычного пользователя выглядит супер-просто – как например, отправка поискового запроса через Google или Яндекс – на самом деле несет в себе огромный уровень сложности.
Отличие интервью по проектированию систем от обычных технических собеседований в том, что здесь от кандидата ждут не четких ответов на вопросы по структурам данных и алгоритмам. Как правило задачи на этом этапе таковы, что для них не существует однозначно верного или неверного решения, они провоцируют мыслительный процесс – именно в нем и раскрывается кандидат.
Грубо говоря, интервью по system design – это что-то типа сессии мозгового штурма, где человек мыслит вслух, перебирает возможные решения и анализирует недостатки каждого из них в режиме реального времени. В этом трудность, но и главный плюс – мыслительный процесс здесь важнее результата. Как правило, такие интервью проводят крупные компании, разрабатывающие масштабные системы (FAANG и подобные).
Как же проходить интервью по проектированию систем? Ниже – несколько практических советов.
Чтобы попасть на интервью в компании, где инженеры действительно проектируют масштабные системы, используйте бота @g-jobbot. Это сервис, который найдет и бесплатно пришлет вам прямо в Telegram вакансии, которые подходят вам лучше всего – в том числе удаленная работа, в том числе с релокацией.
Самое важное – четко разобраться с задачей
Поскольку в интервью по system design самое важное – это то, как вы решаете задачу, крайне важно на самом первом этапе четко ее для себя уяснить. Бывший инженер Microsoft и Facebook в своей статье на практическом примере показывает важность этого факта.
Обычно задача звучит примерно как «Как бы вы спроектировали Netflix за 45 минут?» На первый взгляд, такие вопросы – полный бред. Подобные масштабные системы проектируют и реализуют сотни и тысячи инженеров на протяжение многих лет. Сорока пяти минут будет недостаточно даже чтобы начать обсуждать хоть один из компонентов такого продукта!
Как раз здесь очень важно понимание задачи. Нужно понять, чего хочет интервьюер. А он очевидно хочет, чтобы ему:
На каких-то из этих компонентов можно остановиться чуть подробнее – вам укажут на это, или нужно будет спросить. Обычно на интервью по проектированию систем даже код писать не нужно, а если вы сразу углубитесь в технические дебри, без того, чтобы сначала обсудить всю систему в целом – это будет минусом.
Задавайте уточняющие вопросы
Главная цель интервью по проектированию систем – дать кандидату возможность продемонстрировать свои знания и опыт. Как уже было сказано выше, нет правильных и неправильных ответов. Гораздо важнее не решить задачу как таковую – тем более, что это может быть просто невозможно за отведенное время – а показать свой мыслительный процесс во всей красе.
Поэтому крайне важно задавать вопросы, даже если вдруг получилось так, что вы четко знаете ответ на поставленный вопрос. В такой ситуации не нужно просто писать решение задачи, это противоречит целям интервью. Нужно забыть известное решение, и начать искать новое, по ходу дела задавая вопросы.
Это позволит интервьюеру понять сразу несколько вещей:
Вопросы могут быть такими:
Информации стало заметно больше, теперь уже можно думать о решении такой уточненной задачи.
Не пытайтесь произвести впечатление
Частая ошибка на интервью по проектированию систем – многие кандидаты думают, что раз на этом этапе нужно работать на уровне абстракции, то достаточно будет накидать в ходе разговора крутых терминов и названий модных технологий, чтобы сойти за эксперта. Так это не работает.
Во-первых, на интервью по системному дизайну наверняка будет не просто рекрутер, а инженер, который ищет человека себе в команду. Такому человеку недостаточно просто услышать слова вроде No-SQL, Mongo DB и Hadoop. Он явно начнет задавать уточняющие вопросы, и если у вас на самом деле нет особого опыта в работе с упоминаемыми технологиями, это все очень быстро станет ясно.
Будьте честными
Интервью по проектированию систем – это как раз тот случай, когда не страшно чего-то не знать наверняка. Поэтому ответы вида «Я с этой конкретной технологией никогда не работал, но знаю, что ее часто используют для решения подобных задач» – это хороший вариант. Помимо честности, здесь кандидат показал определенные знания и дал интервьюеру понять, с чего он начнет решение задачи (попробует известное решение, если не получится, будет «копать» дальше).
Помимо этого, не стоит выдавать свое решение за идеальное и не содержащее никаких минусов. Ограничения есть всегда, и опытный инженер-интервьюер это понимает как никто другой. Поэтому в ходе интервью стоит честно говорить о том, что в решение есть такие и такие узкие места, но их можно попробовать обойти таким и таким способом, использовать дополнительные инструменты или провести еще больше исследований.
Так станет понятно, что кандидат не просто придумывает решение и затем жестко пытается его продавить, но может быть гибким, вносить корректировки, и вообще адекватен и понимает, что всегда можно сделать лучше.
Вот прекрасный вымышленный диалог на интервью по проектированию систем, который показывает, как НЕ надо делать:
Интервьюер: Давайте сделаем свой Twitter. Как вы будете хранить твиты?
Кандидат: Я использую NoSQL-базу MongoDB.
Интервьюер: Почему не MySQL?
Кандидат: СУБД не масштабируются. Для нашей задачи точно понадобится MongoDB или BigTable.
Интервьюер: Но мы тут в Twitter храним все твиты в MySQL, все нормально масштабируется.
Кандидат: Ну, тогда, возможно, у вас просто еще пока недостаточно большой объем. По-настоящему огромные системы типа Facebook используют NO-SQL.
Интервьюер: Но Facebook также использует MySQL.
Кандидат: Хм, не знаю, как они его масштабируют, надо разобраться. Возможно, у них MySQL только на фронтенде, а на бэке BigTable.
Интервьюер: Неважно. А где будем хранить аналитические данные?
Кандидат: Очевидно, что в MySQL.
Интервьюер: Но не слишком ли их много для MySQL? Сейчас у нас для этого HDFS.
Кандидат: Похоже, что вы начали разрабатывать Twitter еще до того, как MongoDB достаточно развился. MongoDB может легко вместить и твиты и аналитические данные.
Интервьюер: Супер, спасибо за ваше время. Было приятно пообщаться.
Как подготовиться к интервью: полезные ссылки
Несмотря на то, что проектирование систем – один из наиболее нечетких этапов интервью, к нему можно подготовиться. В помощь кандидатам мы собрали список полезных материалов:
Что еще почитать
Чтобы попасть на интервью в компании, где инженеры действительно проектируют масштабные системы, используйте бота @g-jobbot. Это сервис, который найдет и бесплатно пришлет вам прямо в Telegram вакансии, которые подходят вам лучше всего – в том числе удаленная работа, в том числе с релокацией.
Дизайн-система: что это, кому нужно и как её создать
Объясняем на примерах, зачем нужна дизайн-система, какие преимущества она даёт и почему нужна далеко не всем.
Глава дизайнерского отдела в LogoDesign.net. Любит рассказывать о тонкостях разработки, графическом и веб-дизайне.
Перевожу, пишу, редактирую. Люблю живую речь.
Уважаю букву Ё.
Формализм мастдай.
Если вы следите за миром дизайна, то наверняка слышали про дизайн-системы. О них не сказал лишь ленивый. Одни дизайнеры в восторге от нового тренда, а другие как-то не очень. «Опять придётся что-то учить», — сетуют они. Но как раз дизайн-системы того стоят.
Почему же дизайн-системы стали актуальны? Чтобы понять это, рассмотрим типичный сценарий: нам нужен новый интерфейс для продукта.
Чтобы приступить к разработке, вы собираете требования, беседуете со своей командой, проводите мозговой штурм, и наконец каждый из вас усаживается за проектирование своей части.
Но постойте, какие шрифты мы выбрали? Какой цвет взять, чтобы дизайн создавал нужное настроение? Если я выберу синий, то ощущения будут не такими, как от красного. Мы вообще определились с тональностью сайта? Как насчёт самих компонентов: мы договорились о размерах карточек 1 и их элементах?
Очевидно, что при разработке продукта приходится следить за множеством его частей. Это одна из задач, которую решают дизайн-системы.
Они ускоряют процесс проектирования и дают его участникам много дополнительных преимуществ.
В дизайн-системе Google (Material Design) карточка представляет собой контейнер для целостной единицы контента и действий с ней. Может включать изображение, текст, ссылки и так далее.
Что такое
дизайн-система?
Джереми Кит (Jeremy Keith), ирландский веб-дизайнер и писатель, говорит о дизайн-системе так:
« …Она включает в себя библиотеки шаблонов, руководства по стилю и другие объекты. Но не обманитесь: даже самый полный набор шаблонов никогда не станет для вас дизайн-системой. Потому что система — это не сами компоненты, а то, что связывает их воедино. Это правила и ограничения, которые указывают, как эти шаблоны работают вместе, когда и где целесообразно использовать каждый».
В этом смысле дизайн-система — это структура, которая приводит в порядок все инструменты и процессы проектирования. Это больше чем цвета, шрифты, изображения, макеты и руководства по стилю. Дизайн-система — это философия и язык, которые направляют дизайнеров, помогая создавать продукты более осмысленно.
Преимущества
дизайн-системы
А. Расширение полномочий разработчиков
Иногда программисту что-то неясно в переданном дизайне, а порой возникают особые случаи, про которые дизайнер забыл.
Например, он отрисовал только интерфейс, но разработчику не обойтись без загрузочного экрана и экранов-заглушек (для вывода ошибок и возможных решений). Где взять дизайн отсутствующих элементов? Если сослаться на дизайн-систему, то программиста ничто не задержит — он сразу сможет кодировать. А всё благодаря тому, что последнее слово при разработке — за источником, который доступен сразу всем.
Разработчику не приходится переспрашивать у дизайнеров, правильно ли он реализовал какой-то элемент, ведь команда уже согласовала их все и внесла в систему дизайна — только бери и делай.
Б. Централизация знаний
Как работает дизайн вашего продукта? Может статься, что хорошо это знает один-единственный человек в команде. Тогда всем приходится спрашивать его мнение о дизайнерских решениях. Это замедляет производительность, утомительно, а кроме того, рискованно.
Что делать, если человек этот вдруг уволится со скандалом и обидами? Он унесёт свои знания с собой — и взять их будет уже неоткуда. Отразите эти же знания в дизайн-системе — и они станут доступны любому человеку в любое время.
В. Имидж и маркетинг
Дизайн-системы привлекают отраслевую прессу. Если вы создадите такую для своей компании, не скрывайте её от дизайн-сообщества: поделитесь своими идеями и процессами — и люди о вас заговорят.
Большинство крупных игроков, таких как Shopify, Google, IBM и Atlassian, гордятся собственными дизайн-системами. Они общедоступны, не пугают своим языком и оформлены по-современному. Например:
«Netflix за 45 минут»: что ждать на system design-интервью + подборка полезных ссылок
Интервью по system design – это один из этапов собеседований известных технологических компаний, на котором отсеиваются многие кандидаты. Итак, что это такое и как пройти интервью такого типа?
В современном мире ИТ-системы стали крайне сложными. Каждая новая «фича» в продукте должна соответствовать множеству требований, всегда есть ограничения, между которыми приходится балансировать инженерам. То, что для обычного пользователя выглядит супер-просто – как например, отправка поискового запроса через Google или Яндекс – на самом деле несет в себе огромный уровень сложности.
Отличие интервью по проектированию систем от обычных технических собеседований в том, что здесь от кандидата ждут не четких ответов на вопросы по структурам данных и алгоритмам. Как правило задачи на этом этапе таковы, что для них не существует однозначно верного или неверного решения, они провоцируют мыслительный процесс – именно в нем и раскрывается кандидат.
Грубо говоря, интервью по system design – это что-то типа сессии мозгового штурма, где человек мыслит вслух, перебирает возможные решения и анализирует недостатки каждого из них в режиме реального времени. В этом трудность, но и главный плюс – мыслительный процесс здесь важнее результата. Как правило, такие интервью проводят крупные компании, разрабатывающие масштабные системы (FAANG и подобные).
Как же проходить интервью по проектированию систем? Ниже – несколько практических советов.
Поскольку в интервью по system design самое важное – это то, как вы решаете задачу, крайне важно на самом первом этапе четко ее для себя уяснить. Бывший инженер Microsoft и Facebook в своей статье на практическом примере показывает важность этого факта.
Обычно задача звучит примерно как «Как бы вы спроектировали Netflix за 45 минут?» На первый взгляд, такие вопросы – полный бред. Подобные масштабные системы проектируют и реализуют сотни и тысячи инженеров на протяжение многих лет. Сорока пяти минут будет недостаточно даже чтобы начать обсуждать хоть один из компонентов такого продукта!
Как раз здесь очень важно понимание задачи. Нужно понять, чего хочет интервьюер. А он очевидно хочет, чтобы ему:
На каких-то из этих компонентов можно остановиться чуть подробнее – вам укажут на это, или нужно будет спросить. Обычно на интервью по проектированию систем даже код писать не нужно, а если вы сразу углубитесь в технические дебри, без того, чтобы сначала обсудить всю систему в целом – это будет минусом.
Главная цель интервью по проектированию систем – дать кандидату возможность продемонстрировать свои знания и опыт. Как уже было сказано выше, нет правильных и неправильных ответов. Гораздо важнее не решить задачу как таковую – тем более, что это может быть просто невозможно за отведенное время – а показать свой мыслительный процесс во всей красе.
Поэтому крайне важно задавать вопросы, даже если вдруг получилось так, что вы четко знаете ответ на поставленный вопрос. В такой ситуации не нужно просто писать решение задачи, это противоречит целям интервью. Нужно забыть известное решение, и начать искать новое, по ходу дела задавая вопросы.
Это позволит интервьюеру понять сразу несколько вещей:
В этой статье инженер Twitter, поделился своим опытом прохождения интервью. В частности, он дал хорошее описание того, как надо задавать вопросы. Представим, что на интервью вам дали задание спроектировать коробку. Больше никакой информации сходу не дают.
Вопросы могут быть такими:
Ответы на них позволят понять, что нужно создать желтую коробку с нарисованным на ней смайликом, в которую поместится хотя бы один теннисный мяч. Однако, мяч не совсем обычный – его радиус составляет полметра, а вес около 1 кг. Коробку будут просто переносить, держа за дно, так что ручки на ней не нужны.
Информации стало заметно больше, теперь уже можно думать о решении такой уточненной задачи.
Частая ошибка на интервью по проектированию систем – многие кандидаты думают, что раз на этом этапе нужно работать на уровне абстракции, то достаточно будет накидать в ходе разговора крутых терминов и названий модных технологий, чтобы сойти за эксперта. Так это не работает.
Во-первых, на интервью по системному дизайну наверняка будет не просто рекрутер, а инженер, который ищет человека себе в команду. Такому человеку недостаточно просто услышать слова вроде No-SQL, Mongo DB и Hadoop. Он явно начнет задавать уточняющие вопросы, и если у вас на самом деле нет особого опыта в работе с упоминаемыми технологиями, это все очень быстро станет ясно.
Интервью по проектированию систем – это как раз тот случай, когда не страшно чего-то не знать наверняка. Поэтому ответы вида «Я с этой конкретной технологией никогда не работал, но знаю, что ее часто используют для решения подобных задач» – это хороший вариант. Помимо честности, здесь кандидат показал определенные знания и дал интервьюеру понять, с чего он начнет решение задачи (попробует известное решение, если не получится, будет «копать» дальше).
Помимо этого, не стоит выдавать свое решение за идеальное и не содержащее никаких минусов. Ограничения есть всегда, и опытный инженер-интервьюер это понимает как никто другой. Поэтому в ходе интервью стоит честно говорить о том, что в решение есть такие и такие узкие места, но их можно попробовать обойти таким и таким способом, использовать дополнительные инструменты или провести еще больше исследований.
Так станет понятно, что кандидат не просто придумывает решение и затем жестко пытается его продавить, но может быть гибким, вносить корректировки, и вообще адекватен и понимает, что всегда можно сделать лучше.
Вот прекрасный вымышленный диалог на интервью по проектированию систем, который показывает, как НЕ надо делать:
Интервьюер: Давайте сделаем свой Twitter. Как вы будете хранить твиты?
Кандидат: Я использую NoSQL-базу MongoDB.
Интервьюер: Почему не MySQL?
Кандидат: СУБД не масштабируются. Для нашей задачи точно понадобится MongoDB или BigTable.
Интервьюер: Но мы тут в Twitter храним все твиты в MySQL, все нормально масштабируется.
Кандидат: Ну, тогда, возможно, у вас просто еще пока недостаточно большой объем. По-настоящему огромные системы типа Facebook используют NO-SQL.
Интервьюер: Но Facebook также использует MySQL.
Кандидат: Хм, не знаю, как они его масштабируют, надо разобраться. Возможно, у них MySQL только на фронтенде, а на бэке BigTable.
Интервьюер: Неважно. А где будем хранить аналитические данные?
Кандидат: Очевидно, что в MySQL.
Интервьюер: Но не слишком ли их много для MySQL? Сейчас у нас для этого HDFS.
Кандидат: Похоже, что вы начали разрабатывать Twitter еще до того, как MongoDB достаточно развился. MongoDB может легко вместить и твиты и аналитические данные.
Интервьюер: Супер, спасибо за ваше время. Было приятно пообщаться.
Несмотря на то, что проектирование систем – один из наиболее нечетких этапов интервью, к нему можно подготовиться. В помощь кандидатам мы собрали список полезных материалов:
Чтобы попасть на интервью в компании, где инженеры действительно проектируют масштабные системы, используйте бота @g-jobbot. Это сервис, который найдет и бесплатно пришлет вам прямо в Telegram вакансии, которые подходят вам лучше всего — в том числе удаленная работа, в том числе с релокацией.
Дизайн-система. Определение понятия
В российском дизайн-сообществе сформировалось и все чаще встречается мнение о том, что возникший в последние годы хайп вокруг дизайн-систем — не более, чем пузырь, раздутый вокруг давно существующей темы, а вовлеченные в это дело авторы спекулируют на старых понятиях.
Одним из наиболее распространенных заблуждений является чрезмерно узкое понимание термина “дизайн-система”, когда за неё принимают какой-то один из составляющих элементов, например, визуальный язык или дизайнерские шаблоны.
Регулярно в своих выступлениях я затрагиваю определение понятий и говорю о том, что в действительности понимается под дизайн-системой в наше время.
Однако, споры продолжаются, а значит точка ещё не поставлена.
Я серьёзно беспокоюсь о том, что эта неопределенность может негативно отразиться на нашей отрасли, попросту затормозить нас, поэтому беру на себя смелость попытаться в этой заметке максимально чётко определить, что же такое современная дизайн-система, почему она существует в таком виде и, что едва ли не важнее всего, чем она отличается от статичных гайдлайнов прошлого. Для удобства, часть заметки будет оформлена в формате ответов на часто задаваемые вопросы.
Откуда ноги растут
Способность к передаче опыта и знаний была одним из толчков к развитию человечества, однако, формализованной системы для этого не существовало в течение очень долгого времени. Всё происходило довольно стихийно, буквально из уст в уста.
Центрами знания были, как правило, библиотеки и культовые места, где не только хранилась информация, но и происходило обучение.
Прекрасным примером подлинной реформы в систематизации знания можно считать изобретение в средние века Гвидо Аретинским системы нотного письма, которая впоследствии эволюционировала в то, чем мы пользуемся и сейчас. Она позволила существенно упросить процесс обучения певчих, и сократить его с 10 лет до 2!
Огромный толчок к развитию возможностей передачи опыта, безусловно, дало изобретение книгопечатания. Даже сам процесс книгопечатания можно считать неплохим примером, т.к. он требовал очень чёткого соблюдения принципов.
Чем сложнее и многограннее система, тем значимее точность передачи опыта. Поэтому, громадный технологический рывок XX века потребовал усовершенствовать то, как мы формализуем знание и контролируем результат.
В середине 50х с активным ростом коммерческого графического дизайна для корпораций возникает понятие визуальной идентификации бренда (слово «дизайн-система» появляется примерно в то же время).
Классическим (и наиболее близким к нашей теме) примером является исключительно подробная инструкция для метрополитена Нью-Йорка, где досконально объясняются все детали создания графики, принципы навигации и т.п.
С такого рода документами разной степени подробности приходилось (и по сей день приходится) работать дизайнерам, делающим что-либо для компаний в оффлайне. Возможно, в этом и кроется причина того, что очень часто под дизайн-системой в целом понимают именно визуальные гайдлайны и руководства по фирменному стилю.
Чтобы не затягивать рассказ, сразу перейду к последнему десятилетию, когда произошёл совершенно невероятный рост и развитие технологических стартапов.
Невиданная ранее динамика рынка и особенности digital-среды потребовали по-новому взглянуть на вопрос консистентности и масштабируемости решений. Для новых компаний это стало одним из ключевых факторов для успешного роста.
К сожалению, существовавшие ранее гайдлайны не могли отвечать новым требованиям, т.к. являлись статическим артефактом и предполагали прохождение любого дизайн-решения через цепочку: «гайдлайн → макет → верстка → реализация». Юра Ветров в одной из статей цикла «UX стратегия» указал на то, какие это порождает проблемы: на каждом из этапов цепочки теряются детали и генерируются баги, реализовать задуманное на 100% становится крайне сложно.. Только перенося референсный дизайн из статической документации на уровень реализации, можно сократить цепочку до «гайдлайн = дизайн = верстка → реализация», а значит — избавиться от кучи геморроя по внедрению, улучшению и поддержке продуктов.
Итак, технологическим компаниям нужно было соответствующее решение на стыке дизайна и технологий.
Идеальным примером такого решения станет библиотека Bootrstap, позволившая молодым стартапам быстро собирать лендинги с адаптивностью и простой библиотекой компонентов из коробки — то, что нужно!
Однако, это было лишь технической частью. Необходимой, но недостаточной для того, чтобы называться «дизайн-системой».
Последней вехой на пути к дизайн-системам в современном их понимании хочется выделить появление методологии Atomic Design.
Существует понятие модульного дизайна, когда мы рассматриваем наш процесс в контексте абстрактных слоев, уровней. Это облегчает восприятие комплексного дизайн-процесса и дробит его на понятные составляющие.
Atomic design, безусловно, не был первым и лично я не могу назвать себя сторонником парадигмы Брэда Фроста, т.к. он выбрал довольно специфичные метафоры для описания слоев, однако, нельзя отрицать, что именно эта методология стала наиболее известным примером, в целом популяризировавшим направление.
Как обещал в самом начале, часть, посвящённая определению понятия дизайн-системы, для удобства восприятия, будет подана в формате вопросов и ответов.
Вопросы и ответы
Что такое дизайн-система в двух словах?
В качестве ёмкого определения я бы предложил следующее:
Дизайн-система — это целостный визуальный язык и его техническое отражение в виде библиотеки компонентов на едином репозитории, а также сопутствующих дизайнерских шаблонов.
Из чего состоит настоящая дизайн-система?
Чтобы называться таковой, дизайн-система должна включать в себя четыре необходимых элемента:
Что такое «визуальный язык»?
Визуальный язык — это парадигма, определяющая то, как мы создаём интерфейсы продуктов, основа-основ.
Целостный визуальный язык включает в себя:
Примерами целостно описанного визуального языка можно считать Polaris от Shopify и язык IBM.
Что такое «библиотека компонентов»?
Библиотека компонентов в коде — техническая реализация всего того, что было заложено в вашем визуальном языке. Вся необходимая логика буквально «зашивается» в компоненты, они становятся основным отражением вашей системы.
Очевидным плюсом использования библиотеки является то, что она существенно упрощает поддержание консистентности продуктов и стабильный уровень качества дизайна.
Хорошая библиотека включает в себя:
В качестве примера такой библиотеки как части системы можно назвать AtlasKit от Atlassian.
Подробнее узнать о преимуществах работы с библиотекой можно в одной из статей цикла “UX стратегия” Юры Ветрова.
Что такое дизайнерские шаблоны в дизайн-системе?
Несмотря на то, что единственно значимым отражением вашей системы являются компоненты в коде (т.е. то, что непосредственно видят ваши пользователи), у дизайнеров должна быть возможность свободно прототипировать, используя все необходимые элементы. В идеальной картине мира у дизайнеров есть среда прототипирования с использованием боевых компонентов и реальных данных, однако, это довольно трудно достижимо. Достаточным является наличие актуального и поддерживаемого шаблона (или группы шаблонов) для любого используемого вами дизайнерского инструмента.
Подробнее о том, как устроены шаблоны в Портальной команде Mail.Ru можно почитать здесь.
Важно помнить, что дизайнерские шаблоны — это лишь часть дизайн-системы и сами по себе, без привязки к библиотеке компонентов, они являются лишь статичными артефактами.
Слышал определение «единый источник правды». Что это и зачем оно нужно?
Критически важно, чтобы существовал (и поддерживался в актуальном состоянии) ресурс, где будет всецело отражёна дизайн-система со всеми её составляющими. Этот ресурс будет являться вашим единым источником правды о системе — местом, с которым можно будет регулярно сверяться в процессе работы.
Существование такого ресурса кардинально упрощает взаимодействие вокруг дизайн-системы, т.к. все участники процесса имеют под рукой единую точку, куда можно обратиться за ответами на все распространённые вопросы. Особенно ярко это ощущается при взаимодействии с аутсорсом — именно тогда вы понимаете, насколько доступно всё описали!
Дизайн-системе нужна команда?
Команда дизайн-системы — последний составляющий элемент нашего определения. Как и любой другой серьезный долгосрочный проект, дизайн-система должна иметь своих идеологов, которые заложат и будут поддерживать философию и базовые принципы, менеджеров, которые сделают так, чтобы проект случился, и исполнителей, которые будут работать над ней руками. Зачастую случается так, что эти роли совмещаются и перемешиваются. На определенном уровне зрелости компания может создать выделенную команду системы, но как правило, работа ведётся параллельно с основной деятельностью. Cамое главное, чтобы в принципе существовали люди, регулярно и систематически удаляющие внимание проекту. Только в этом случае он имеет шанс обрести жизнь.
Полезную информацию об устройстве команды дизайн-системы можно почитать у главного идеолога этой темы — Nathan Curtis.
Не понимаю: чем дизайн-система отличается от гайдлайна?
Гайдлайн в традиционном понимании — статичный документ, в котором фиксируются правила работы с визуальным стилем компании. Дизайн-система может включать в себя эту информацию, но она гораздо шире. Гайдлайн — лишь один из элементов системы.
В отличие от классического статичного гайдлайна, дизайн-система — «живая », т.е. не только описана, но реализована в библиотеке компонентов. Таким образом, в дизайн-системе (в отличие от гайдлайна) есть динамическая связка между исходными правилами и реализацией. Гайдлайн можно обновлять, не будучи уверенными в том, что это изменение на чём-то отразится. В дизайн-системе изменения могут раскатываться на всю цепочку продуктов.
Мы собрали крутейший UI Kit в Sketch/Figma/etc. и активно используем его в работе. Можно сказать, что у нас есть дизайн-система?
Можно сказать, что вы сделали шаг к унификации дизайна. В идеале этот процесс начинается не с графических артефактов, но осознания и формулирования принципов, которыми вы руководствуетесь в дизайне продуктов. Без этого унификация будет происходить только на визуальном уровне.
Также важно помнить, что сам по себе UI Kit вне системы — не более, чем статичное изображение элементов, которое будет неизбежно устаревать и никак не отражать реальность. Чтобы этого избежать, ваш UI Kit должен быть реализован в виде «живых » компонентов в коде, используемых на реальных продуктах.
Иными словами, от схемы, при которой ваш дизайн никак не связан с итоговым результатом, необходимо прийти к той, когда ваш дизайн “вшит” в библиотеку компонентов и результат предсказуем.