Перестаньте создавать интерфейсы, начните создавать опыт

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

Беспорядочный процесс – плохой результат

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

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

Для работы со страницей или пользовательским потоком они импортировали скриншоты в Sketch, обрезали их, непосредственно обрабатывали, скрывали одни элементы, создавали другие , обращались к старым файлам для того, чтобы скопировать компоненты, которые они создавали раньше… И все это сопровождалось вопросами «какой правильный отступ?», «какой правильный размер кнопок?», «какой правильный цвет?» и так далее. Мне приходилось постоянно спрашивать коллег-дизайнеров о том, какой файл нужно открыть, чтобы взять кнопку или верхнее меню… просто потом создавать новое…. только для того, чтобы обнаружить, что результаты вообще ни к чему не подходят.

От беспорядка к гармонии

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

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

Мы договорились решить нашу проблему и решение придумали очень простое:

LEGO! Вы наверняка слышали о метафоре Lego в дизайне, блоки Lego это эквиваленты наших компонентов. Если просто взять коробку кубиков Lego, то я могу сделать все это…

… гидросамолет, спорткар и даже гребанного динозавра!

Так что мы сделали библиотеку элементов UI Lego Bricks, которые позволили нашим дизайнерам делать тоже самое! Теперь, с нашими UI Lego блоками,….

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

Сколько времени это на самом деле сэкономило?

Вам, наверное, интересно узнать, сколько времени мы можем реально сэкономить с помощью этого метода. У нас тоже были некоторые сомнения, так что мы решили провести простой тест. Мы вязли страницу личного профиля и попросили дизайнеров переделать ее — с и без UI Lego Bricks.

Мы замерили время работы и результаты оказались обнадеживающими – в среднем дизайнеры тратили 24 минуты без UI Lego Bricks и 13 минут с ними. Мы не говорили им, что пытаемся сосредоточиться на продуктивности, не в этом дело, но наши дизайнеры на самом деле потратили на 50% меньше времени на размышления о пикселях и на 50% больше времени на размышления об опыте – именно этого мы и хотели достичь.

Больше нет повторяющейся работы

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

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

Мы все знаем, как это раздражает – сделайте страницу для iOS, а потом снова ее же для Android и еще для мобильного веба. Мы упорно работали над созданием библиотеки компонентов, которые были бы идентичны для всех платформ и в тоже время оставались платформено-ориентированными. Сейчас наши дизайнеры могут разрабатывать только для одной платформы будучи уверенными в том, что, например, фронт-энд разработчик может использовать iOS или Android дизайн для создания той же страницы мобильного веба.

Срезайте путь

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

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

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

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

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

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

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

Мы использовали эту методологию с мощной метафорой (LEGO), которая была глубокой и важной в понимании, она помогала нам общаться и люди быстро понимали ее и связывали с идеей. Работники любого направления в компании могли легко понять эту идею даже без нашего объяснения.

После нескольких месяцев работы над нашей системой дизайна я смог сформулировать несколько важных правил. Это не rocket science, но они правда помогают нам не потеряться.

Метафора: выберите сильную метафору, которая поможет людям понять то, о чем вы говорите, даже не объясняя это. Мы выбрали LEGO, но есть и другие идеи, которые вы можете использовать (химия, фордизм, экология…).

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

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

Правила: для каждого выбора в области UI у вас должны быть четкие правила. Если вы не можете объяснить выбор, задайте правило.

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

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