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

Оскар создает цифровые инструменты для ряда пользователей, включая членов, поставщиков, брокеров, работодателей и широкую массив сотрудников Oscar. Проектирование всех этих цифровых технологий параллельно, с небольшой командой, было непростым. Наши постоянные инвестиции в нашу систему проектирования, Anatomy, помогли нам подняться, чтобы справиться с этими проблемами. Для тех, кто не знаком, система проектирования определяет основной UI / UX бренда.

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

Начиная с начала работы над Anatomy в 2016 году, проектная группа внедрила систему почти в каждый веб-опыт, созданный с тех пор, как Оскар. За последние два года мы узнали несколько уроков о том, как успешно общаться, создавать и организовывать команду для создания системы проектирования.

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

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

2. Держите его простым, просто поддаваясь настраиваемости.

Выяснение того, как сбалансировать гибкость в компоненте, было одним из труднейших уроков, которые мы изучили при построении анатомии. Помимо вариантов настройки (например, цветов и размеров) некоторые компоненты имеют общие макеты, функциональные возможности и шаблоны взаимодействия. Должны ли они быть встроены в компонент? Сколько определения слишком много? Компонент, который слишком четко определен, может быть ограниченным, но слишком большая гибкость может вызвать зоопарк несогласованности. В конечном счете, мы принимаем это решение по отдельности, но мы обнаружили некоторые общие правила для жизни. Например, мы обнаружили, что лучше не создавать какую-либо настраиваемость превентивно. В то время как настройка может быть добавлена, сложнее отделить существующие компоненты. Кроме того, создание внутренних модулей контента для некоторых компонентов было эффективным способом управления конкретными макетами, в то же время предлагая экранирующий люк для особых случаев.

3.

Мы изначально создали Anatomy через два веб-продукта: веб-приложение участника и веб-приложение провайдера. С тех пор использование Anatomy более чем удвоилось благодаря множеству внутренних инструментов (включая управление данными поставщика, обработку заявок и веб-инструменты, используемые нашими командами Concierge), а также Oscar for Business. Кроме того, он разработал цикл обратной связи с Mobile Anatomy, Oscar's React Native для наших мобильных приложений. Хотя в потребностях много совпадений, каждое приложение отличается от своих пользователей, прецедентов и потоков. Раньше в марте мы дошли до того момента, когда, когда мы хотели изменить компонент, мы не решались переложить изменения на каждый экземпляр компонента. Чтобы решить эту проблему, мы недавно включили функцию пометки для включения определенных функций и обновлений в компонент вместо экосистемы «все или ничего». Эта гибкость уже зарекомендовала себя как полезная для таких вещей, как A / B-тестирование, и медленные откаты для больших изменений.

4. Решение не является постоянным. Все может быть изменено.

Иногда решения, которые мы принимаем о том, как компонент выглядит или создается, кажутся слишком постоянными, поскольку они сидят в кодовой базе в течение недель, месяцев, а затем и лет, медленно нарастают и больше времени. « Я хочу изменить его … но как я могу изменить его сейчас? Все уже используют его. Это повсюду. » Звучит знакомо? Прекрати это. Это изменчиво. Всегда лучше решать какие-либо вопросы раньше, чем позже, прежде чем они будут дополнительно рассеяны в экосистеме продукта. До тех пор, пока несколько месяцев назад все поля формы анатомии (входы, выделения, поля автозаполнения и т. Д.) Были компонентами первого поколения, созданными до изучения некоторых передовых методов и основанных на проектах из унаследованного кода. Предыдущие поля формы пришли к бессмысленному размеру и непоследовательной поддержке темы / размера. Набор компонентов был глобально пронизан во всех наших приложениях, но в феврале прошлого года мы взяли на себя обязательство запускать поля для полей второго поколения. Быстрая перемотка вперед через несколько месяцев, и многие из наших веб-приложений уже начали пожинать плоды более высокой согласованности, лучшего качества кода и более доступного дизайна.

5. Документация и эскизные символы — лучшие друзья дизайнера.

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