Използване на библиотеки на Sketch и примитиви за изграждане на още по-добра система от бутони

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

Компоненти, споделящи един и същ радиус на границата, съхранявани в „примитивен“ файл на библиотеката на скицата.

В предишна статия споделям процес, който използва Sketch Libraries за изграждане на основните градивни елементи на система за проектиране. Освен ако не живеете под скала, най-вероятно библиотеките ще са на радара ви, ако не вече са част от работния ви процес.

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

Можете да посочите тези абстрахирани свойства като „UI Primitive“, термин, познат (според мен) от Бенджамин Уилкинс от Airbnb и Дан Едън от Facebook.

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

Дизайнерско мислене в Примитиви

Помислете за примитивите като за най-гранулирани елементи от нивото, от които е съставена останалата част от вашия дизайн. Ако някога сте работили със SASS, тогава примитивите са вашите променливи. По същия начин тези, които са запознати със Lighting Design System, ще разберат примитивите като дизайнерски символи.

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

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

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

Прилагане на примитиви на практика, за да подобрим нашия процес на проектиране в Sketch

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

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

И така, как можем да възприемем тази идея за примитиви на потребителския интерфейс - като най-основните съставки в дизайна - и да ги използваме за изграждането на по-големи, разпознаваеми компоненти в дизайнерската система?

Примитивни библиотеки за един-единствен източник на истина

Разделяне на вашия потребителски интерфейс на частични библиотеки за скициране

Сигурен съм, че досега трябва да сте запознати с идеята за използване на UI комплект, където всички компоненти за многократна употреба живеят в един файл на Sketch. „Единствен източник на истина“, както мнозина се позовават на него.

Въз основа на тази идея, сегашният ми процес включва разделяне на компоненти на потребителския интерфейс и примитивните стилове, които се състоят - които може би някога сте съхранявали в един файл на скица, наречен „UI kit.sketch“, в няколко независими Sketch файла.

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

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

Папка на истината, съдържаща примитивни библиотечни файлове

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

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

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

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

„Единният дизайн език не трябва да бъде само статичен набор от правила и отделни атоми - той трябва да бъде развиваща се екосистема“ - Кари Сааринен.

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

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

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

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

Следващата част на тази статия ще разгледа използването на тези „примитивни“ библиотеки за изграждане на по-сложни структури. Ще ви преведа през текущия процес, който използвам за изграждането на гъвкава система от бутони, използвайки възможно най-малкия брой уникални символи

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

Анатомията на бутон

Разгледайте бутоните в дизайна си и най-вероятно ще забележите шепа повторно възникващи свойства. Можете да идентифицирате прилики във всяко от следните:

  • Фонова форма
  • Цвят на фона
  • Ширина на границата
  • Граничен радиус
  • Текстова фамилия
  • Цвят на текста
  • Размер на текста
  • Подплънки (отляво, отдясно, отгоре, отдолу)

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

Илюстрирана анатомия на бутон, обозначен с различни примитивни свойства

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

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

Одитиране на текущите стилове на бутони

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

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

4 стила на бутони в най-различни цветове и форми

Идентифициране на видовете бутони

Въз основа на одита изглежда логично да се групират четирите типа в следните категории:

  • бутон соло
  • бутон с икона
  • само икона на бутона
  • група бутони (вляво, в средата и вдясно)

Всеки тип бутон се появява в нашите дизайни в 3 различни размера, които са базирани на ритъм, свързан с решетката 8pt и се отнасят до тяхната височина. Тези размери са 48px, 40px и 32px. В името на простотата приех оразмеряване на тениска при именуване на всеки размер; Малки, средни и големи.

3 размера на бутоните въз основа на решетката 8pt

Идентифициране на примитивите

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

  • цвят
  • граница
  • икона
  • форма
  • текст
  • състояние

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

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

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

Справяне с текст на бутона

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

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

С това идентифицирах 4 различни цвята на текста: Марка, тъмно, бяло и деактивирано. Текстът също се използва в 3 различни размера, по един за всеки размер на бутона; голям, среден и малък.

Създадох отделни Artboards във файл на скица, наречен AIN-бутони (префиксът „AIN -“, отнасящ се до проекта на системата за проектиране) за всяка от тези свойства на текста и ги преобразих в Symbols. Когато изградя крайния компонент на бутона, ще мога да заменя стила на текста, когато е необходимо, като вмъкна тези текстови символи.

За да работят тези отменения, уверих се да спазва конвенцията си за именуване в Artboard последователна, следя основна система за именуване: име на компонент, свойства (която съдържа всички свойства в папка, специфична за свойството), тип на свойството, размер и цвят на свойството. Изглеждаше така:

бутон / свойства / текст / голям / марка

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

Справяне със състояния на бутони

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

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

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

бутон / свойства / състояние / деактивиран

Всеки символ се състои от един правоъгълен слой с леко различни запълвания. Състоянието на курсора, който направих, използвах Artboard с правоъгълно запълване от 20% бяло. За натиснато състояние направих същото, но с 10% черно запълване. На хората с увреждания имаше 80% бяло и още 100% черно отгоре, този път с режим на смесване, зададен на „Hue“. Това гарантира, че всеки цветен бутон изглежда ненаситен, когато пренасочването на състоянието е зададено на „деактивирано“.

Sidenote: Размерите на Artboard не са важни, тъй като те могат да бъдат оразмерени по-късно, просто се уверете, че всички ваши състояния Artboards са с еднакъв размер, това позволява на Overrides да работи. Ще трябва обаче да се уверите, че размерите се различават от вашите полета Text Symbol. Това е така, за да не се показват в падащото меню Text Overrides. Това е леко досада при работа с Overrides в Sketch и не е от съществено значение, но ще запази вашите опции Override хубави и чисти.

Справяне с форма на бутон

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

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

Създаване на уникални символи за всяка от 5-те форми на бутона, които да бъдат използвани по-късно като отмяна

Нарекох 5-те фигури, използвани в системата: Запълване (4px радиус от всяка страна), закръглено (100px радиус от всяка страна), радиус наляво (4px радиус отляво), радиус вдясно (радиус 4px вдясно) и радиус няма (0px радиус от всички страни). Тези три фигури ще бъдат използвани за моите групи бутони - вляво, в средата и вдясно, в случай че не беше ясно.

След това превърнах всяка форма в маска „ctrl click> Mask“ и вмъкнах цвят от моята библиотека с цветове. Тъй като цветът седи над маска, формата отдолу ще изрязва цвета, разкриващ формата.

Маскиране на формата и добавяне на цвят от цветовата библиотека

Тогава вмъкнах символа „състояние“, който направих по-рано върху цвета.

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

бутон / свойства / форма / запълване

бутон / свойства / форма / заоблен

Влагане на държавния символ и граница от гранична библиотека

Sidenote: Уверете се, че вашите Shape Artboards са еднакви по размери един с друг, но различни по размер както на вашите Text, така и на State Artboards. Това ще попречи на всички да се показват в едно и също падащо меню Override и ще поддържа нещата организирани.

Изграждане на компонента на основния бутон за всеки тип бутон

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

Забележка: помислете за основния символ като този, който вмъквате във вашите дизайнерски макети, използвайки Sketch Runner.

Само за да обобщим това означава, че трябва да направим главен символ за всеки от следните типове бутони:

  • бутон соло
  • бутон с икона
  • само икона на бутона
  • група от бутони вляво
  • средна група бутони
  • бутон група вдясно

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

Изграждане на основния символ за соло бутони

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

Изграждане на основния символ за соло бутони

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

Накрая превърнах Artboard в символ.

Филтрирането надолу в менюто Вмъкване показва нашите 3 нови главни бутона Символи:

бутон> бутон соло> малък

бутон> бутон соло> среден

бутон> бутон соло> голям

Изграждане на основния символ за бутони с икона

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

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

Запомнете: „Ctrl + кликнете> Създаване на символ“ прави нашите бутони за икони приложими, ако още не сте превърнали Artboard в символ.

Изграждане само на бутони за главния символ само

Отново, много прости бутони само с икони следват същите правила като преди, но този път премахнахме вложен текст символ. Както можете да видите в GIF по-долу, сега имам само 2 слоя, икона и символ на формата.

Както и преди, направих уникален символ за всеки от необходимите ми размери. Един за малки, средни и големи бутони с икони.

Създаване на главните символи за бутони само за икони

Изграждане на основния символ за групови бутони

Изграждането на груповите бутони изисква общо 9 символа. Един за ляв, среден и десен във всеки от 3-те различни размера; малки, средни и големи. С изключение на тяхната форма, която използва малко по-различно Override, груповите бутони са идентични с нашите солови бутони.

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

Създаване на 9 базови символа за групови бутони

Използване на новите ни бутони и преобладаващи стилове

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

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

Поставяне на бутони с Runner и използване на отмените за промяна на стиловете на бутоните

Като осмивам различните ми стилове на бутони на нова страница във файла с бутони AIN, сега имам визуална справка за всеки бутон в системата.

Различни стилове на бутони, изградени с помощта на системата с бутони

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

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

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

Демонстрация на мащабируемост с помощта на библиотеки; добавяне на икони и използването им в различни файлове в системата.

Обобщавайки

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

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

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

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

Какво следва?

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

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

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

ресурси

  • Ограниченията са основна част от дизайна на Стивън Брадли.
  • Методология на атомния дизайн на Брад Фрост.
  • Изграждане на визуален език в Airbnb.
  • Мислене в символи за универсален дизайн от Бенджамин Уилкинс.
  • Dan Eden относно структурата на дизайна.
  • По-добър начин да направите бутони по скица от Джон Мур.

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

Аз съм Хари Cresswell Съосновах indtl.com и работя като UX / UI дизайнер и преден разработчик в Angel Investment Network. Проектирам тип през нощта си и изпращам бюлетин за дизайн и типография.

Намерете ме в Twitter, ако искате да поздравите.