Изграждане на визуален език: зад кулисите на нашата система за дизайн на Airbnb

Работейки в разработването и дизайна на софтуер, от нас често се изисква да доставяме еднократни решения. Понякога работим в рамките на времеви ограничения, а понякога просто още не сме се договорили за път напред. Тези еднократни решения не са по своята същност лоши, но ако не са изградени върху солидна основа, в крайна сметка се оказваме, че трябва да изплатим начислените технически и дизайнерски дългове.

Визуалният език е като всеки друг език. Недоразуменията възникват, ако езикът не се споделя и разбира от всички, които го използват. С нарастването на даден продукт или екип, предизвикателствата в тези модалности се съединяват.

Дизайнът винаги е бил до голяма степен за системите и как да създавате продукти по мащабируем и повтарящ се начин. От цветовете на Pantone до винтовете на Philips, тези системи ни позволяват да управляваме хаоса и да създаваме по-добри продукти. Дигиталните продукти са може би най-плодотворната основа за внедряване на тези системи и въпреки това често не се считат за приоритет.

Единната система за проектиране е от съществено значение за изграждането на по-добра и по-бърза; по-добре, защото сплотеното преживяване се разбира по-лесно от нашите потребители и по-бързо, защото ни дава общ език за работа.

Защо имаме нужда от системи за проектиране

Airbnb през годините претърпя много голям растеж. В момента дизайнерският ни отдел се състои от близо дузина функции и екипи за резултати. Стана ясно, че се нуждаем от по-систематични начини да ръководим и да използваме своите колективни усилия. Въпреки че разпознахме тези предизвикателства в компанията, вярвам, че те са симптоми на по-големи проблеми в софтуерната индустрия.

Твърде малко ограничения
Софтуерният дизайн има малко физически ограничения в сравнение с много други дизайнерски дисциплини. Това дава възможност за разнообразни решения на всяко предизвикателство, но също така го отваря за разединени потребителски изживявания. Като собственици на продукти и дизайнери, ние трябва да създаваме и следваме собствените си ограничения.

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

Множество платформи
Трябва да доставим нашия продукт на множество платформи и устройства. Поддържането на синхронизирани функции и дизайни отнема значителни усилия, като често се изисква една и съща работа да се повтаря във всички тези платформи.

Софтуер като континуум
Друго уникално нещо за софтуера е, че въпреки че може да се счита за продукт, той всъщност не се износва и не се заменя като традиционните потребителски продукти. Кодът и дизайните, създадени преди години, все още съществуват на много места, дори след като пейзажът на една компания и нейният продукт са се изместили значително. Това изисква постоянна поддръжка и надграждане.

Първи на работа

За да работим над тези предизвикателства и да поддържаме бързо процеса на вземане на решения, събрахме малка група дизайнери и инженери [2]. Изчистихме нашите календари, резервирахме външно студийно място непосредствено извън централата на Airbnb и се посветихме на проектирането и изграждането на Design Language System (DLS).

Целта, която си поставихме за DLS, беше да създадем по-красив и достъпен дизайн език. Нашите дизайни трябва да бъдат унифицирани платформи, които осигуряват по-голяма ефективност чрез добре дефинирани и многократно използвани компоненти. За да насочим усилията си, намалихме първоначалния обхват до създаването на системата първо на родните платформи (iOS и Android).

Започнахме с одит и отпечатване на много от нашите дизайни, както стари, така и нови. Поставяйки потоците един до друг на дъска, можехме да видим къде и как пречупването преживява и къде трябва да започнем да правим промени. Решихме, че най-добрият начин да започнем е чрез решаване на проблемите. Всеки от нас се съсредоточи върху дизайна на екрана или продукта, и създадохме няколко принципа, които да ни ръководят с тези индивидуални дизайни:

Унифицирано: Всяко парче е част от по-голямо цяло и трябва да допринесе положително за системата в мащаб. Не трябва да има изолирани функции или отстъпки.

Универсален: Airbnb се използва по целия свят от широка световна общност. Нашите продукти и визуален език трябва да бъдат приветливи и достъпни.

Иконичен: Ние сме фокусирани по отношение както на дизайна, така и на функционалността. Нашата работа трябва да говори смело и ясно на този фокус.

Разговорно: Използването на движение вдъхва живот на нашите продукти и ни позволява да общуваме с потребителите по лесно разбираеми начини.

Полагане на основата

Преди да започнем този спринт в дизайна, ние вече бяхме създали основно ръководство за стил, което нарекохме фондация. Тази основа дефинира слабо нашата типография, цветове, икони, разстояния и информационна архитектура. Фондацията се оказа от съществено значение за насочване на нашата работа в единна посока, като същевременно ни дава възможност за индивидуално проучване на креативни дизайнерски решения.

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

Създаване на компоненти

Традиционно много ръководства за стил определят компонентите като атомни компоненти, които след това се използват за изграждане на по-сложни молекули. На теория това работи добре за създаване на съгласувани и гъвкави системи. На практика обаче често се случва, че тези повторно използваеми атоми се използват по много различни начини, което позволява създаването на всички видове молекули. Отново, това отваря вратата за всякакъв вид разединени преживявания и прави системата по-трудна за поддържане.

Вместо да разчитаме на отделни атоми, ние започнахме да разглеждаме нашите компоненти като елементи на жив организъм. Те имат функция и личност, определят се от набор от свойства, могат да съществуват съвместно с другите и могат да се развиват независимо. Единният дизайн език не трябва да е просто набор от статични правила и отделни атоми, а развиваща се екосистема.

Единният дизайн език не трябва да бъде само набор от статични правила и отделни атоми; тя трябва да бъде развиваща се екосистема.

Например, нашият потребителски аватар елемент може да бъде първоначално дефиниран от ръководство за стил, но неговата крайна употреба в платформата може да поеме стотици пермутации, което затруднява успешно актуализирането на аватарния елемент по пътя. “Ако искаме да променим някоя от двете от тези неща можем да сме сигурни, че не разбиваме други екрани.

Всеки компонент се определя от необходимите му елементи (като заглавие, текст, икона и картина), а понякога може да съдържа и незадължителни елементи. Тези елементи са дефинирани както в документа Sketch, така и в кода. Вместо да позволяваме на самите линии на разделител, ние изискваме всеки компонент да има разделител, който след това да е видим или скрит въз основа на логиката на изгледа.

Съставяне на библиотеката

Докато създавахме тези компоненти, ги събрахме в главен файл, наречен библиотека, към който се позовавахме през целия процес на проектиране. След седмица-две започнахме да забелязваме огромни скокове в производителността, използвайки библиотеката при повторение на дизайни. Един ден, докато съставяше прототип в последната минута, нашият екип успя да създаде близо 50 екрана само за няколко часа, като използва рамката, която ни предоставя библиотеката.

Докато библиотеката се разрастваше, ние започнахме да организираме отделни компоненти в табла с изображения, съдържащи подобни елементи. След това тези платки бяха организирани от обща категория в: Навигация, Маркети, Съдържание, Образ и Специалност.

Създадохме един набор от тези компоненти за телефони (iOS и Android) и ги приспособихме към размерите на таблетите от там. Компонентите на таблетите до голяма степен са същите като тези за мобилни устройства и на техническо ниво кодът трябва да съществува само веднъж в два различни стила. С тази система компонентите могат да варират по своя външен вид и позициониране, подобно на начина, по който отзивчивият дизайн работи за уеб. След това дизайнерите могат да проектират екран веднъж с помощта на общи компоненти и той може лесно да бъде адаптиран към различни размери на екрана, както и към iOS и Android.

За таблет създадохме няколко прости концепции за оформление, като Focus Views, която фокусира съдържанието върху страницата, модалите и оформлението на 2 колони и мрежи.

Всички компоненти и изгледи са изградени със собствена техническа рамка на изгледа, която се справя с тези стилове, състояния и адаптивност. [2]

Поуки

Знаехме, че това е предизвикателен проект. Това означаваше препроектиране и възстановяване на по-голямата част от гледните точки в нашето приложение. Успяхме да постигнем целта си да създадем системата и да пуснем новите приложения на 17 април. Както при всеки проект, има неща, които бихме искали да направим по различен начин.

Не всички компоненти са създадени равни. В повечето приложения има набор от компоненти, които се повтарят често. За нас тези компоненти са редове (или клетки от таблица). Поглеждайки назад, бих искал да сме отделили повече време да помислим за редовете и да измислим по-силен набор от модели и компоненти. В крайна сметка се завъртяхме с много различни видове с някои несъответствия.

Скица. Първоначално се опитахме да създадем тези компоненти като символи в Sketch, което доведе до бъркотия. Дори сега нашите Sketch файлове понякога са трудни за поддържане. Движейки се напред, се надяваме да намерим по-добри начини за поддържане и създаване на нови компоненти. [3]

Документация. Този проект изискваше да работим в строг график, което ни накара да пренебрегнем част от процеса на документация. Липсата на задълбочена документация създаде объркване, което би могло да бъде избегнато. Точно както при кодирането, системите за документиране, както са създадени, са от първостепенно значение за процеса. Това трябва да се направи рано или късно и документирането по време на процеса на създаване позволява по-плавно вземане на решения.

заключение

Тъй като езикът за дизайн и кодът често се споделят, сега можем да изграждаме и пускаме функции на всички родни платформи приблизително по едно и също време. Разработката обикновено е по-бърза, тъй като продуктовите инженери могат да се съсредоточат повече върху писането на логиката на функциите, а не върху кода на изгледа. Освен това инженерите и дизайнерите вече споделят общ език.

Дизайнерите също се вълнуваха от системата. Той дава възможност на прегледите на продуктите да се съсредоточат върху действителните концепции и преживявания на дизайна, а не върху подплънки, цветове и избор на тип. DLS ни предоставя споделено разбиране за нашия визуален стил и оптимизира приноса към една система. Тази система също така позволява на всички нас да прототипираме и да експериментираме с идеи с висока вярност по-бързо и на по-ниска цена.

Вярвам, че с помощта на тези системи можем да се съсредоточим повече върху реалните потребителски изживявания и концепции, които искаме да създадем в бъдеще.

Отговорих и на някои въпроси относно Designer News AMA.

Актуализация: За допълнителни подробности и по-нови разработки около нашата система за дизайн, гледайте моите разговори на конференцията Design Systems 2018, Хелзинки, Финландия.

Бележки под линия:

[1]: Много страхотни проекти са за екипи и винаги има твърде много хора, за които да благодаря, но исках да подчертая малко хора, които направиха този проект:

Бек Стоун, Адам Микела, Амбър Картрайт, Алекс Шлейфер, Майкъл Бачанд, Пол Комфнер, Шон Ейбрахам, Салих Абдул-Карим, Майкъл Сюи + много други в дизайнерските и инженерни екипи. Благодаря на Джош Леонг, Сола Биу, Катрин Уейт, че прочетете проектите на това.

[2]: Ще го оставя на един от нашите инженери да напише повече за техническата страна на DLS.

[3]: В нашия случай искаме хората да могат да променят размерите на символите (напр. Трябва да се впишете в повече съдържание в заглавието). Ако трябва да преоразмерите или случайно да преоразмерите нещо, Sketch (2.5) автоматично преоразмерява всеки екземпляр от този символ. Това би убило скицата ви за няколко мига и вероятно забърка трайно файла ви (понякога отмяната не работи). В крайна сметка поставихме компонентите в групи слоеве и оставихме хората да ги копират и поставят.

Ние също използваме git / github, за да улесним процеса на актуализиране на файлове. Ние ръчно създаваме и добавяме нови компоненти в нашия Sketch файл на основната библиотека и изпращаме заявки за изтегляне с журнал за промяна и генерирани png износ, които документират промените. След това файлът Sketch се озовава в споделена папка Box, която е свързана с шаблоните на Sketch, така че всеки има достъп до новите компоненти веднага.