Хаос в процессах, хаос в результате

Проведя 8 месяцев в различных агентствах, я решил принять новый для себя вызов и с гордостью присоединился к команде дизайнеров BlaBlaCar.

Вспоминая первые недели работы, скажу, что я был потрясен их образом работы… Их инструменты, в большей или меньшей степени, составлял пустой файл Sketch с пустыми рабочими областями и 2 тестовых телефона для скриншотов приложения.

Инструменты дизайнеров в BlaBlaCar: пустой файл Sketch и 2 тестовых телефона.
Инструменты дизайнеров в BlaBlaCar: пустой файл Sketch и 2 тестовых телефона.
Для работы над страницей, они импортировали свои скриншоты в Sketch, обрезали их и работали только с этим. Они скрывали некоторые элементы, создавали новые, открывали старые файлы, чтобы взять оттуда необходимые компоненты, созданные ранее… На протяжении всего процесса, они задавали себе вопросы типа: какой отступ будет правильным?, какой правильный размер кнопки?, какой правильный цвет?, и т. д. Я словил себя на мысли, что я постоянно спрашиваю своих коллег о том, какой файл мне открыть для того, чтобы найти кнопку или верхнюю панель… чтобы закончить начатое… и в итоге получить нелогичный результат.
Страница профиля пользователя на Android, iOS, MWeb и Web. Почему они такие разные?
Страница профиля пользователя на Android, iOS, MWeb и Web. Почему они такие разные?

Хаос для гармонии

Я вспоминаю, как задавал себе вопрос: Как они управляют одной страницей с разной логикой на разных платформах? Ответ оказался очень прост: Они не управляют.

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

Мы очень хотели найти решение нашей проблемы, и оно оказалось очень простым:

Метафора Лего в дизайне: кубики равняются компонентами нашего UI.
Метафора Лего в дизайне: кубики равняются компонентами нашего UI.
ЛЕГО! Вы, возможно, слышали о метафоре Лего в дизайне. Кубики лего означают элементы наших компонентов. Если я возьму коробку с конструктором, я могу построить все это:

1-rOkcMUYTg-GuqdKf1UrEeQ

… самолет, машину и даже тиранозавра!

Итак, мы создали коллекцию UI кубиков лего, чтобы наши дизайнеры сделали тоже самое! И вот наш UI с кубиками лего…

Пример компонентов UI в BlaBlaCar.
Пример компонентов UI в BlaBlaCar.
… они могут быстро создать страницу, процесс и таким образом работать с ними и тестировать их быстрее.
Теперь процесс создания, правок и тестирования стал быстрее.
Теперь процесс создания, правок и тестирования стал быстрее.
Сколько это сэкономило реального времени?

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

Эту страницу дизайнеры создавали с и без использования кубиков Лего.
Эту страницу дизайнеры создавали с и без использования кубиков Лего.
Мы засекли время, которое они потратили на выполнение данной задачи и результаты нас приятно удивили: в среднем, дизайнеры тратили 24 минуты на создание страницы без использование лего и 13 минут с лего UI. Мы не говорим, что они уделяли особое внимание продуктивности, не в этом суть. Дизайнеры тратили на 50% меньше времени думая о пикселях и на 50% больше думали о UX.

Больше никакой скучной работы

В BlaBlaCar мы никогда не останавливаемся и после использование кубиков UI (внеся некоторые небольшие правки), мы сказали себе: Конечно мы можем экономить время еще больше!

Мы пересмотрели на их самые рутинные и затратные по времени задачи. Как минимум одна из них: множество платформ!

Один компонент=много платформ.
Один компонент=много платформ.
Мы все знаем, как раздражает создавать страницу для iOS, затем для Android и мобильную версию сайта. Мы долго работали над созданием совокупности компонентов, которые будут одинаковыми для каждой платформы и будут совместимыми с ними. Теперь, наши дизайнеры могут рисовать только для одной платформы, подразумевая, что фронтэнд разработчик сможет взять дизайн под iOS или Andriod и использовать его для мобильной версии сайта.

Простой путь

Мы смогли добиться того, что наши дизайнеры экономят 50% времени на создание интерфейсов, мы также попытались уменьшить количество платформ, для которых создается дизайн. Но мы все равно хотели бы еще больше снизить затраты времени. Если мы посмотрим на процесс создания интерфейсов в BlaBlaCar на сегодняшний день, он будет выглядеть так:

Дизайнеры делают наброски → далее делают макет → затем прототип → финализируют дизайн → приступают к разработке.

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

1-EbgfUlo0iolc4tfllCTruA

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

1-fxjoQN3wIGeFIuKOfyUfYg

Мы не хотим, чтобы наши дизайнеры тратили время на создание интерфейса, пусть они уделяют внимание только UX.

Правила, которым мы следовали

В нашей системе, мы основывались на методике Атомного Дизайна, созданную Брэдом Фростом, любителем химии (сложные организмы созданы из молекул, в свою очередь, состоящие из атомов). Если вы еще не знакомы с этой методикой, настоятельно рекомендую вам ознакомиться с ней здесь.

Мы применили эту методику к сильной метафоре (конструктор Лего), и это помогло нам в коммуникации со специалистами. Это позволило нам быстрее донести наши идеи и мысли.

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

  • Метафора: выберите сильную метафору, чтобы люди смогли быстро понять, о чем вы говорите, без детального объяснения. В нашем случае, это было Лего, но вы можете использовать все, что вам придет в голову (химия, система Форда, экосистема…)
  • Коммуникация: важное правило, чтобы не допустить провала вашего проекта. Общайтесь с коллегами на самых ранних этапах: менеджерами, аналитиками, дизайнерами, СЕО… Дайте им возможность стать частью проекта.
  • Общий язык: предметов без названия не существует. Необходимо быть уверенным, что все правильно понимают названия компонентов. Не нужно вдаваться в технические детали, важно, чтобы каждый называл компоненты одинаково.
  • Правила: для каждого выбора UI, необходимо создать прозрачное правило. Если вы не можете объяснить выбор, придумайте правило. (Расскажу об этом в другой статье).
  • Никаких исключений: Исключения приводят к появлению серьезных противоречий. Придерживайтесь ваших правил и компонентов даже, если они выглядят странными на первый взгляд. Не делайте исключений.

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