Когда дизайн встречается с инжинирингом в Traveloka

Это не обычная история любви.

Примечание. Это только одно из взаимодействий между проектированием и проектированием. Я говорю из одного небольшого спектра всех взаимодействий между проектированием и проектированием в Traveloka. И это моя история.

Со временем Traveloka существует уже 6 лет. В этом путешествии мы признаем, что у нас есть много визуальных ошибок, которые были там в течение долгого времени, таких как различные оттенки оранжевого для кнопок или несовместимое поле между картами.

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

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

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

Когда они впервые встретились?

Переговоры начались в начале 2018 года, когда команда инженеров провела некоторые исследования React Native и React Native Web (React Native - это платформа для создания мобильных приложений с использованием JavaScript). Когда началось это исследование, к работе подключились разработчики веб-интерфейса из команды дизайнеров.

В ходе этого процесса у команды инженеров возникла идея использовать React Native в качестве основы для кроссплатформенной разработки. Это включает разработку Mobile Web, в которой Web UI Developer может задействовать создание компонентов на нем.

Когда началась эта инициатива, мы были так взволнованы, изучая React Native и извлекая из него максимум пользы, поскольку мы можем оказать более существенное влияние и создать компоненты для всех доступных платформ из единого источника кода. И здесь мы впервые узнаем друг друга.

Как выросла любовь?

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

Этот стажер является инженером React Native, и ему поручено создавать все, что может сгладить сотрудничество между проектированием и разработкой. Он начал создавать библиотеку компонентов, несколько умопомрачительных плагинов для эскизов для дизайнеров, а также исследовал другие возможности сотрудничества между Дизайном и Инжинирингом.

Помимо этого, команда разработчиков также выступила с инициативой создания единого источника правды на основе кода (SSOT) для токенов и компонентов проектирования. Эти два движения вдохновили нас на сотрудничество в этой миссии. Вот где любовь искрится, и мы верим, что вместе мы сталкиваемся с более светлым будущим.

Куда нас привела любовь?

После нескольких встреч (читай: встреча) мы наконец соглашаемся перевести наши отношения на новый уровень. По дороге было нелегко идти, но мы верили, что это то, что нам нужно. Понимание друг друга - важный ключ к хорошим отношениям, верно? И это то, что мы сделали, когда решили сотрудничать.

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

1. Кодовая система проектирования.

Сотрудничество между проектированием и разработкой было довольно сложным. Мост между дизайном и кодом недостаточно силен, и это сделало трудной работу между нами.

Затем у нас появилась идея создать систему проектирования на основе кода. Мы поместили наш маркер дизайна в JavaScript, который является самым простым способом для инженера, но все же достаточно простым для управления дизайнером.

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

2. Эскиз плагинов.

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

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

3. Дизайн линтера и комплексное визуальное тестирование.

После работы с пользовательским интерфейсом и кодом, следующий шаг - убедиться, что они оба стандартизированы. Именно здесь приняли участие дизайнерские линтеры и комплексные визуальные тесты. В настоящее время мы изучаем возможность разработки дизайна линтера и интегрированного визуального тестирования, чтобы они работали как защитная сетка для нашего пользовательского интерфейса и кодов. Со стороны дизайна, дизайн линтер будет стимулировать UI Designer использовать стандартизированные компоненты. Между тем, с технической точки зрения визуальное тестирование уменьшит вероятность визуальных аномалий при выпуске продукта. Это сделает жизнь дизайнера и инженера легче в будущем.

4. Проектирование системной документации.

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

Иллюстрация Ралисту Хаю Пративи

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

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

«Дизайн - это не только то, на что он похож и что чувствует. Дизайн - это то, как он работает ».