Как да изградим система за проектиране

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

Без съмнение ме питат за дизайнерските системи повече от всичко друго. И така, прекарвайки по-голямата част от последните няколко години в размисъл как да проектирам, изграждам и представям системи за проектиране на продукти като Marvel, Bantam и Modulz, реших, че ще споделя някои от това, което научих по пътя.

Какво е система за проектиране?

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

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

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

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

Проектиране на стилова палитра

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

Дори най-простият компонент на заглавието е колекция от множество стилове за многократна употреба ...

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

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

цвят

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

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

Цветове на марката

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

Цветове за успех и неуспех

И накрая, имаме нужда от някои сиви цветове. Повечето потребителски интерфейси ще се нуждаят от поне следните сиви цветове:

  • Много светло сиво за фонове
  • Малко по-тъмно сиво за граници, линии, щрихи или разделители.
  • Средно сиво за подпозиции и поддържащо копие на тялото.
  • Тъмно сиво за основни заглавия, копие на тялото и фонове.

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

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

Нашата финална цветова палитра

сенки

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

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

Тези четири сенки трябва да са достатъчни за стилизиране на всеки компонент в нашата система:

  • Една фина сянка за повишаване на интерактивните компоненти и добавяне на принуда.
  • По-ясно изразена сянка за ефект на задържане на компоненти.
  • Силна сянка, която дава перспектива на падащите / поповите и други подобни компоненти.
  • Далечна сянка за модални компоненти.
Нашата гама от сенки от фини до далечни.

Тип скала

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

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

Следващата стъпка е да решим приблизително кои размери на шрифта ще ни трябват, след което да ги начертаем на нашата скала тип „Основни трети“.

  • По подразбиране (1ем) за стандартен текст, който ще се показва на много места в нашия маркетинг сайт, потребителски интерфейс и т.н. 16px е размерът на шрифта на браузъра по подразбиране, така че нека да работи с това.
  • Малко по-голям размер за голямо копие на тялото например в блог.
  • Няколко по-големи размери за заглавия и подзаглавия.
  • Много голям размер за заглавия на секции.
  • Нелепо голям размер може би за цените на страница с ценообразуване например.
  • Ще ни трябват и по-малки размери за по-малки копия на тялото, съвети за въвеждане и друг вторичен текст.
Тип скала

Гранични радиуси

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

  • Малък радиус на рамката за миниатюрни компоненти като квадратчета, етикети и етикети.
  • Среден граничен радиус за бутони и входове и подобни компоненти.
  • Голям радиус на рамката за карти, модали и други големи компоненти.
2px, 4px и 8px гранични радиуси

Забележка: Ще имаме нужда и от 50% радиус на границата за изграждане на кръгови компоненти като аватари и т.н.

Разстояние между скалата

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

Подобно на типа, придържайки се към разстояние между скалата, можем да гарантираме, че всеки от нашите компоненти и оформления ще бъде еднакъв. Любимата ми скала за преминаване към разстоянието е 8dp решетка на Material design. Елиът Дал е написал страхотна статия за 8pt мрежовата система и нейните предимства.

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

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

Разстояние между буквите

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

3 или 4 буквени стойности трябва да направят трика.

Изграждане на компонентна библиотека

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

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

Дейв Рупърт проведе тази анкета на Twitter наскоро, питайки къде да поставите код, който отменя стила на компонент на бутон, ако този бутон е вътре в модален компонент, например.

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

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

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

Нека вземем няколко общи компоненти и да разгледаме как можем да ги изградим, използвайки само стиловете, които сме дефинирали в нашата палитра по-горе.

Скромният бутон

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

Повече компоненти

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

Нека да опитаме нещо по-фантастично ...

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

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

Съвети за пътя

  • Някои компоненти ще изискват стойности, които не са дефинирани в нашата стилова палитра, например ширината на страничната лента. Понякога тези стойности ще бъдат само 1/3 от ширината на екрана или нещо подобно. Друг път тези стойности ще бъдат произволни и не може да се използват повторно и това е напълно добре. Въпросът е да помислим кои стилове трябва да бъдат многократно използвани и кои стилове не трябва.
  • Оставете компонентите да вършат своето нещо. Не се опитвайте да добавяте полета към бутони, входове, заглавия или други компоненти. На ниво компонент трябва да дефинирате само стиловете, които изглеждат еднообразни във всеки отделен екземпляр на този компонент. Тъй като маржовете се различават за всеки отделен случай, по-добре е да ги приложите с помощта на обвивка div. Хари Робъртс написа отлична статия, засягаща тази точка.

Работя върху цялостен CSS инструментариум, базиран на рамката на Bantam CSS, който ще включва всички компоненти, показани в тази статия, както и много други. Проектът е за Modulz, продукт, върху който работя, но ако се интересувате сами да използвате този инструментариум на потребителския интерфейс, уведомете ме в Twitter. Ако получа достатъчно интерес, ще го отворя с отворен код.