Компонентен дизайн

Подобряване на вашия дизайн-процес за изграждане на потребителски интерфейс

Комуникация на естетическо без поведение

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

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

  • Дизайнерите създават първоначални макети на страница въз основа на въвеждането на клиента
  • Ръководителят на проекта и / или ръководителят на екип разделя макети в билети за разработчици
  • Има екип за разработка, който да изпълни създадения дизайн
  • С итерацията на дизайна се създават нови билети и процесът се повтаря

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

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

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

Трябваше ни по-добра система.

Въведете дизайн, базиран на компоненти

Няколко основни влияния ни доведоха до компонентна система за проектиране. Първият беше React, който нашият екип на frontend използва за разработване на нашите приложения. React е структуриран около компоненти и в резултат на това нашият екип за разработка мисли в тези термини. Моделът на атомния дизайн на Брад Фрост и BEM методологията също предоставиха значително вдъхновение. В същото време нашият дизайнерски екип откри, че изолирането на компоненти и различните им състояния им позволява по-ясно да формулират поведението и функционалността си. Те все още създават страници, за да опишат потребителския поток през приложението, но вече няма нужда да обясняват всяко състояние на задържане и грешка в контекста на тази страница. Първо създавайки изолирани, разтегателни компоненти, успяхме да премахнем много дублирани усилия и на двата екипа. Той също трансформира нашия процес. Има по-малко раздаване и по-продължително сътрудничество. Членовете на нашия екип по проектиране и разработка разбират по-добре намеренията и ограниченията на другия.

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

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

Текущ процес

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

Благодаря за четенето!

Можете да ме намерите в Twitter и GitHub. Ако ви хареса това, трябва да се абонирате и за бюлетина ми! https://tinyletter.com/alanbsmith