25 юни 2018 г.

Намирам се в An Event Apart Бостън, където Уна е на път да говори за дизайнерски системи, следвайки разговора за отличните дизайнерски системи на Yesenia. Ще се опитам да го публикувам на живо ...

защо

Уна работи в Bustle Digital Group, която публикува много различни свойства. Преди е работила в Уотсън, в Bluemix и в Digital Ocean. Всички те имат нещо общо (освен да имат синьо в логата си). Всички те имаха системи за проектиране, които се проваляха.

В момента дизайнерските системи са толкова горещи. Те ни позволяват да мислим по компонентни начини и да растеме бързо. Има много примери, като Polaris от Shopify, системата за дизайн на Lightning от Salesforce, Garden от Zendesk, Gov.uk и Code For America. Вижте отличните стилови ръководства на Anna за още примери.

Какво точно представлява системата за проектиране?

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

Стилови ръководства

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

Инструменти за проектиране

Праймърът на Github е добър пример за това. Можете да изтеглите предварително направени икони, цветове и т.н.

Библиотека на компонентите

Тук получавате кода. Уна работи върху BUI в Digital Ocean, който описва състоянията на взаимодействие на всеки компонент и как да персонализирате взаимодействията с JavaScript.

Указания за използване на кода

AirBnB има наистина добър пример за това. Това е последователен стил на кода. Можете дори да го включите в стъпката си за изграждане с eslint-config-airbnb и stylelint-config-airbnb .

Документация за използване на дизайна

Carbon от IBM върши чудесна работа за това. Той описва критериите за вземане на решение кога да се използва шаблон. Води се от съображения за потребителски опит. Те също така имат общи насоки за зареждане в компоненти - празни състояния и др. И включват насоки за анимация (отделно от Carbon), изградени върху историята на машините на IBM за магнитни ленти и пишещите машини.

Указания за глас и тон

Разбира се, Mailchimp е класическият пример тук. Те разбиват гласа и тона. Гласът не е само това, което е компанията, но и това, което компанията не е:

  • Забавно, но не глупаво,
  • Уверен, но не нахакан,
  • Умен, но не копривен,
  • и така нататък.

Voiceandtone.com описва чувствата на потребителя в различни точки и как да комуникира с тях. Има насоки за потребителите на приложения, както и насоки за читателите на фирмения бюлетин, както и насоки за читателите на блога и т.н. Те дори имат примери, когато нещата се объркат. Насоките предоставят съвети как да помогнете на хората ефективно.

Защо системите за проектиране се провалят?

Сега Уна пита кой в ​​стаята е правил диета. И кой някога е завършил диета? (Много ръце слизат).

Никой не го използва

В Digital Ocean имаше система за проектиране, наречена Buoy версия 1. Una помогна за изграждането на система за дизайн, наречена Float. Имаше и версия на BUI 2. Буй беше за продукт, Float беше за маркетинговия сайт. Класически пример за 927. Никой не ги използва.

Una провери CSS на крайния изход и кодът на системата за проектиране представлява само 28% от кодовата база. Повечето от CSS превъзхождаха CSS в системата за проектиране.

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

Инвестиция

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

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

Трябва да започнеш някъде.

Комуникация

Комуникацията е многоизмерна; не е еднопосочен. Собственикът на системата за проектиране (или екипът) трябва да действа като мост между дизайнери и разработчици. Никой не обича да му се казва какво да прави. Хората трябва да бъдат включени и да се чувстват сякаш техните нужди са адресирани. Накарайте хората да се чувстват така, сякаш имат контрол над процеса ... дори и да не го правят; това е като възприемано изпълнение - това е възприемано участие.

Питам. Слушам. Накарайте потребителите си да се чувстват чути. Включете обратна връзка.

Закупете в

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

Показването е по-мощно от разказването. Хакатоните са като бонбони за начинаеща система за дизайн - шанс да демонстрирате предимствата на системата за дизайн (и да получите обратна връзка). След хакатон в Digital Ocean всички говориха за системата за дизайн. Седмици след това един от разработчиците замени Bootstrap с BUI, премахвайки 20 000 реда код! След като видят въздействието на системата за проектиране, разработчиците ще разкажат на своите колеги всичко за това.

Солидна архитектура

Трябва да градите с мисъл за композиране и промяна. Primer, от Github, има основен пакет и след това добавки за, да речем, маркетинг или продукт. Това разделяне на опасенията е страхотно. BUI използва подобен модулен подход: основна кодова база, отделно от иконографията и мрежата.

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

Използвайте същата конвенция във вашите дизайнерски файлове, като Sketch.

Какво ще кажете за избора на технологичен стек? Всяка компания има различни нужди, но едно нещо, което Уна препоръчва, е: не чакайте пространство за имена! Всички ваши компоненти трябва да имат някакъв префикс в имената на класовете, за да не се сблъскват със съществуващия CSS.

Уна споменава Solid от Buzzfeed, което лично според мен е страшно (пребройте броя! Важни декларации - можете да го наречете „неизменим“ всичко, което искате).

AtlasKit от Atlassian влиза all in в React. Те се опитват да интегрират Sketch в него, но инструментариумът за проектиране все още не е решен (AirBnB също работи по това). Все още се опитваме да разберем как да обединим света на дизайна и кода.

Намалете триенето

За това става въпрос. Използването на системата за проектиране трябва да бъде пътят на най-малкото съпротивление. Ако новата система за проектиране е по-трудна за използване от това, което хората вече правят, те няма да я използват.

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

Започнете рано, актуализирайте често. Системите за проектиране могат да бъдат изградени ретроспективно, но е по-лесно да се направи, когато се изгражда нов продукт.

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

И така, петте стълба за осигуряване на успешна система за проектиране са:

  1. Инвестиция
  2. Комуникация
  3. Закупете в
  4. Солидна архитектура
  5. Намалете триенето

Когато започвате, започнете с цел:

Изграждаме система за дизайн, защото ...

След това прегледайте това, което вече имате (съществуващата ви кодова база). Например, ако целта на системата за проектиране е да се увеличи производителността на страницата, използвайте Web Page Test, за да измерите как се представя текущият сайт. Ако целта е да се намалят проблемите с достъпността, използвайте webaim.org за измерване на достъпността на текущия ви сайт (вижте също: pa11y). Ако целта е да намалите количеството CSS във вашата кодова база, използвайте cssstats.com, за да тествате как се справя текущият ви сайт. След като вече имате статистика, използвайте ги, за да получите бай-ин. Можете също да започнете, като направите инвентаризация на интерфейса. Разпечатайте страници и ги изрежете.

След като получите покупка и ангажимент (в писмена форма), можете да вземате технически решения.

Можете да започнете с вашите атомни елементи. Бутоните са като „Здравей, свят!“ на системи за проектиране. Имате цветове, тип и различни състояния.

След това можете да композирате елементи, като съберете основните елементи заедно.

Включвате ли оформление в системата? Това е предизвикателство и зависи от вашия екип. Ако все пак включите оформление, до каква степен?

Независимо от оформлението, все още трябва да мислите за пространството: пространството между базовите елементи в рамките на даден компонент.

Изпечете в достъпността: всяко състояние на навъртане трябва да има равно (а не противоположно) състояние на фокус.

Помислете за състояния, като зареждане на състояния.

След това можете да започнете да документирате. След това информирайте потребителите на системата. Carbon има табло за управление, което показва кои компоненти са нови, кои компоненти са остарели и кои компоненти се актуализират.

Поддържайте последователна комуникация. Трябва да се случи дизайн и комуникация с разработчиците. Непрекъснатото повторение, поддръжка и комуникация са най-важните фактори за успеха на системата за проектиране. Кодът е само 10% от системата.

Освен това не чувствайте, че трябва да копирате други системи за дизайн там. Вашите нужди вероятно са много различни. Както казва Даяна, сравняването на вашата дизайнерска система с полираните обществени е все едно да сравните живота си с нечий акаунт в Instagram. За тази цел Уна казва нещо потенциално противоречиво:

Може да не ви е необходим системен дизайн.

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