Projektowanie interfejsu – od czego zacząć?

Niezależnie od tego, na jakim etapie swojej kariery jesteśmy, to pewne elementy są niezmienne. Mogą się one, oczywiście, z czasem nieco bardziej rozwinąć, poprawić czy też po prostu usprawnić w kontekście poświęconego czasu i pewnych automatyzacji, ale jednak baza i intencja jest podobna: aby zjeść posiłek, muszę nakryć do stołu. Tak też jest w przypadku rozpoczynania projektu – czy to strony internetowej, czy aplikacji. Musimy przygotować kilka elementów wspólnych, aby mieć jak później zjeść, to znaczy zaprojektować coś w łatwy sposób.Poradnik ten będzie bazował na moich własnych doświadczeniach, czyli osoby, która zajmuje się projektowaniem graficznym od 2005 roku i aktualnie pracuje jako Senior Product Designer w firmie posiadającej własną aplikację MarTech.

Zanim zaczniemy

Na początku warto zdefiniować podstawowe informacje, które będą dla nas kluczowe w procesie tworzenia aplikacji, a mianowicie standardowe składowe, które musi mieć nasz style guide lub design system.

Użyłem tutaj dwóch określeń nie ze względu na to, że są to synonimy, a dlatego, że nie każdy projekt musi zawierać aż bardzo rozbudowaną bibliotekę, by nazywać to design systemem.

Obrazując: kiedy tworzymy aplikację pokroju Salesforce, to mamy mnóstwo komponentów, wariacji, typografii czy zmiennych, ale kiedy projektujemy kalkulator, to już niekoniecznie jest nam potrzebny design system. W takim przypadku wystarczy nam style guide, czyli krótki przewodnik po stylistyce projektu i podjętych decyzjach projektowych.

Co powinno się zatem znaleźć w takim przewodniku?

• Typ urządzenia na jaki jest projektowany interfejs
• Kolorystyka
• Typografia
• Grid
• Marginesy
• Sposób prezentacji kluczowych komponentów

Dzięki temu każda osoba korzystająca z naszego projektu w przyszłości będzie miała znacznie łatwiej, by zrozumieć go i wykonać swoje zadanie bez konsultacji z autorem fundamentów.

Dobrą praktyką jest również tworzenie dokumentacji tekstowej, czyli dopisanie również wstępu, opisu dla każdej sekcji oraz dodanie na końcu fragmentu na zasadzie znanego nam FAQ, czyli najczęściej zadawanych pytań. Dzięki temu całość stanie się jeszcze bardziej zrozumiała.

Paleta kolorów

Dobrze, wiemy więc, że w projekcie będą potrzebne nam kolory (yay!). Nie zawsze jednak są one zdefiniowane ze względu na branding, bo czasem tworzymy PoC (proof-of-concept), aby np. dostać fundusze na zbudowanie biznesu, a czasem po prostu robimy coś dla siebie.

W takim przypadku warto sięgnąć po podstawy: po generatory palet i nieco fantazji. Z pomocą przyjdą nam tutaj darmowe narzędzia, które pomagają w tych zadaniach, a dodatkowo aplikacje innych projektantów, które mogą służyć za inspiracje.

Do zaprojektowania mamy kilka kategorii kolorów:

• główne – bazowe warianty kolorów naszej aplikacji,
• akcenty – uzupełnienia,
• barwy neutralne – szarości oraz mono.

Dróg do wypracowania palety jest wiele, ale my tutaj skupimy się na trzech opcjach:

1. korzystaniu z Adobe Color,
2. pracy z HSL,
3. inspiracji innym projektem.

Ad. 1: Korzystanie z Adobe Color

Wchodząc na stronę color.adobe.com, możemy zauważyć narzędzie, które widzicie na obrazku. Na pierwszy rzut oka wydaje się skomplikowane i może odrzucać, ale jeśli chwilę się nim pobawić, to zobaczycie, że dużo rzeczy dzieje się „pod maską”, co nam bardzo pomaga.

Źródło: color.adobe.com

Nikt też nie powiedział, że musimy wszystko ustawiać sami – ja bardzo często korzystam
z zakładki „Explore” na górze strony, która pozwala przeglądać palety zdefiniowane wcześniej przez innych użytkowników. Spójrzmy zatem, jak to wygląda.

Źródło: color.adobe.com

Dzięki wpisanym słowom kluczowym (w moim przypadku to: „blue, cyan, modern”), mamy możliwość eksploracji palet, które są już stworzone, a co za tym idzie – w ciągu jednej minuty możemy zweryfikować setki możliwości dla naszego projektu.

Po wybraniu tej jedynej, która będzie dla nas bazą, przechodzimy już do Figmy i tworzymy deklaracje kolorystyczne, o czym wkrótce.

Ad. 2: Praca z HSL

W kontekście pracy z HSL pomoże nam plugin „HSLuve” – jak widzicie na obrazku poniżej, to wtyczka, która pomaga nam w wizualny sposób dobrać poszczególne kolory wewnątrz Figmy.

Źródło: Figma Community

O co chodzi z HSL?

Litera „H” to hue (co oznacza odcień, barwę), „S” to saturation (co oznacza nasycenie koloru), a „L” to lightness (czyli jasność), co składa się w HSL. Dzięki dobraniu pierwszego koloru głównego jesteśmy w stosunkowo łatwy sposób dobrać kolejne, bazując na przesuwaniu dosłownie jednym wskaźnikiem – wskaźnikiem hue. Czasem jednak to nie wystarcza i musimy dotknąć również lightness, aby wszystko pasowało do siebie tak, jak należy.

Przykład:

po wybraniu swojego pierwszego koloru duplikuję go i – przesuwając tylko suwaki H oraz L – dobieram bardzo łatwo drugi kolor, który pasuje do pierwszego.

Dzięki takiemu rozwiązaniu nie potrzebujemy dużej wiedzy na temat barw czy też wieloletniego doświadczenia – jest tu dodany spory margines błędu, więc trudniej nam dobrać całkowicie niepasujące do siebie kolory.

Mając już wybraną podstawową paletę, tworzymy deklaracje, aby później w całym projekcie mieć spójność oraz w razie potrzeby bardzo ułatwioną możliwość edycji koloru na wszystkich elementach, które go używają.

Zatem kolejno:

1. zaznaczamy kolor,
2. klikamy na ikonkę czterech kropek koło nagłówka „Fill”,
3. w nowym okienku „Color Styles” klikamy na ikonę „+”, aby dodać styl.

Następnie wyświetla nam się okno, gdzie mamy wpisać nazwę naszego koloru.

Tutaj na moment się zatrzymamy, abym pokazał Wam jedną dobrą praktykę – grupowanie zbiorów.

Otóż możemy dodać kolory, jak leci, czyli napisać:

• fioletowy,
• zielony,
• zielony ciemniejszy,
• żółty,
• żółty jasny.

Jednak użyteczność będzie nieco zachwiana, bo czytelność takiej listy nie jest najlepsza. Możemy więc oddzielić nazwę od atrybutu, dodając między nimi znak „/”. Nasza nazwa wygląda wtedy następująco:

• „fioletowy / domyślny”,
• „fioletowy / ciemny”.

Dzięki temu utworzą nam się takie grupy, jak na poniższym załączniku:

Taka operacja znacznie ułatwia dalszą pracę.

Ad. 3 Inspiracja innym projektem

Jest oczywiście jeszcze opcja zainspirowania się paletą z innego projektu. Serwisy typu Dribbble nawet dbają o to, abyśmy mogli podglądać, jaka paleta została użyta w danym projekcie. Dzięki takiemu rozwiązaniu od razu wiemy, jak ukończony projekt prezentuje się z użyciem tych kolorów, ale musimy pamiętać, że warto je nieco dostosować pod siebie.

Źródło: Dribble.com

Typografia

Projekt bez typografii nie mógłby istnieć. Podobnie, jak wyżej: musimy stworzyć swój własny guideline, którym się będziemy kierować, tworząc aplikację. Ja staram się już na samym początku wypracować podstawowe style, takie jak np. nagłówki, paragraf domyślny i mały, do tego wielkość i krój fontów w buttonach – tak, by później już tylko rozbudowywać moją bibliotekę o kolejne wariacje.

Źródło: https://material.io

Do tworzenia typografii może się przydać również narzędzie Type-Scale.com, które w matematyczny sposób pomoże nam dobrać odpowiednie rozmiary fontów.

Źródło: type-scale.com

Idąc tą samą drogą, co poprzednio, stworzymy deklarację stylów, klikając kolejno na ikonę czterech kropek i plusa. Przykład wykorzystania predefiniowanych fontów na obrazku.

Gridy i marginesy

Grid w aplikacji to jedna z trudniejszych rzeczy, którą napotkasz na swojej drodze, bo dla wielu osób na początku nie jest łatwa do zrozumienia. O co zatem chodzi z tymi gridami i dlaczego one są takie ważne?

Do dyspozycji mamy mnóstwo różnych wariacji oraz nieskończoną liczbę możliwości ich modyfikacji, ale – jak zawsze – są pewne standardy i dobre praktyki, które ułatwiają nam budowę struktury. Chciałbym teraz przejść przez kilka bardzo popularnych typów, które mogą się Wam rzucać w oczy w różnych samouczkach, ale nie koniecznie być jasne w użyciu. Kiedy i jakiego gridu użyć?

12 kolumn

To klasyczny grid, który został wykorzystany na milionach stron internetowych, ponieważ użwają go najpopularniejsze frameworki CSS, na przykład Bootstrap. Nie przyda nam się on zbyt często w perspektywie aplikacji, ponieważ ma maksymalną szerokość 1320px (w przypadku col-xxl w bibliotece Bootstrap), a aplikacje zazwyczaj rozszerzają się do szerokości naszej przeglądarki.

Autor: Andrey Zhulidin

6/8 kolumn

W zależności od bazy i jej wersji, możemy zobaczyć, że gridy dla urządzeń mobilnych są dzielone na sześć lub osiem kolumn. No dobra, czasem też trafia się 12, ale uważam, że ciężko się pracuje w taki sposób, kiedy mamy do zaprojektowania aplikację mobilną na szerokość 375 pt/px, a musimy odjąć od tego jeszcze miejsce na odstępy od krawędzi ekranu.

Wracając do samych 6- i 8-kolumnowych gridów: jak mogliście się już domyślić po poprzednim akapicie, używane są one do mniejszych aplikacji i stron www, czyli głównie do responsive design, adaptive design oraz natywnych aplikacji mobilnych.

Jeśli zatem projektujecie aplikację webową, bez wsparcia urządzeń mobilnych, to nie musicie brać tego gridu pod uwagę. Jeśli jednak w przyszłości będziecie mieli za zadanie stworzenie nowej aplikacji mobilnej dla firmy, to przyjdzie taka potrzeba, choć web może powstać w inny sposób.

Autor: Andrey Zhulidin

Fluid/Stretch

Jest to najczęstszy sposób użycia w aplikacjach ze względu na to, że używamy po prostu szerokości ekranu, dodając tylko marginesy pomiędzy głównym elementami, na przykład górną belką nawigacji, sidebarem czy stopką. Reszta elementów w kontenerze, czyli w miejscu, w którym wyświetla się zawartość poszczególnych zakładek, jest już dostosowana do dostępnego czy wolnego miejsca. Zatem jeśli aplikacja będzie wymagać dwóch mniejszych komponentów obok siebie, to podzielą one się całą szerokością kontenera na pół, z uwzględnieniem zadeklarowanej przerwy pomiędzy elementami. Jeśli komponenty będą trzy, to 100% dostępnej szerokości zostanie podzielone na trójkę dzieci.

8 px/4 px grid

Autor: Andrey Zhulidin

Jest to popularne w dzisiejszych czasach podejście, które bazuje na multiplikowaniu wartości 8 lub 4. Na początek odpowiem dlaczego „lub”. Fundamentem tej idei był grid bazujący na liczbie 8, która w bardzo łatwy sposób pozwalała na mnożenie wartości poprzez 0.75 oraz 1.5, które występowały w aplikacjach mobilnych na Androida. Dzięki temu mogliśmy w łatwy i rytmiczny sposób skalować wszelkie elementy, utrzymując tym samym wielkości liczb całkowitych. Jednak z biegiem czasu ludzie zaczęli dostrzegać, że 8, 16, 24, 32 to nieco duże schody, jak na ich potrzeby, dlatego została wprowadzona idea multiplikacji wartości 4, która jednak pozwala na dużo większą granulację, a wciąż zachowuje ideę rytmu, liczb całkowitych i łatwego liczenia.

Przykładowo: 

możemy stworzyć nagłówek H1 w rozmiarze 32 pt, H2 w rozmiarze 28 pt, a akapit, wers (paragraph) w rozmiarze 16 pt – i w takiej kompozycji całość wygląda całkiem atrakcyjnie. W momencie utrzymywania wielokrotności 8 przeskoki były spore i o ile w typografi nie był to największy problem, tak w kontekście marginesów pomiędzy elementami już tak, bo jednak jest znacząca różnica na telefonie, żeby odsunąć kartę od karty albo o 8, albo o 16 pt.

Dla samych marginesów będziemy mogli używać również metodyki multiplikacji 4 px/pt. Jedna rzecz, o której jednak musimy pamiętać: to indywidualna decyzja. Co prawda możemy założyć, że 16 pt jest dobrą praktyką dla marginesów zewnętrznych, a 32 pt znajdzie zastosowanie przy marginesach wewnętrznych, niemniej finalna decyzja należy do nas, bo każda aplikacja jest inna i przy bardziej skomplikowanych interfejsach na pewno będziemy potrzebować więcej powierzchni użytkowej, co będzie skutkowało mniejszymi marginesami.

Przykłady użycia gridu w aplikacji możecie zobaczyć również pod adresem: https://ant.design/docs/spec/layout.

Najważniejsze komponenty

Źródło: carbondesignsystem.com

Projektując fundament naszego interfejsu, musimy uwzględnić również podstawowe komponenty, które wypełnią całą część wizualną naszej aplikacji.
Przedstawiam listę podstawowych komponentów, które warto stworzyć na początku, aby było nam łatwiej później budować wizję zgodną z naszymi oczekiwaniami.

• Lista buttonów
  • Primary
  • Secondary
  • Ghost/Outlined
  • Focus
  • Hover
  • Disabled

• Typy formularzy
  • Text Input
  • Textarea
  • Search
  • Checkbox + Radio Button
  • Switch
  • Dropdown
  • Slider
  • Datepicker
  • Upload plików

• Komunikaty sukcesu, błędu, informacji
  • Tooltip
  • Modal
  • Flash

• Tabele z danymi

Dzięki takiemu rozwiązaniu całą aplikację możemy składać w dalszych krokach niczym klocki Lego. Pobieramy po prostu zdefiniowany wcześniej – np. – button, wklejamy go w artboardzie i ustalamy jego warianty: czy ma być domyślny, czy wciśnięty, a może jeszcze innego typu.

Źródło: https://designerup.co/blog/ui-design-pro-tips-buttons/

W momencie, w którym potrzebujemy jednak coś zmienić, możemy to zrobić w głównej instancji (podobnie jak było w przypadku zdefiniowanych kolorów), a kiedy to zrobimy, nasza nasza zmiana zaaplikuje się do wszystkich użytych elementów (dzieci pochodzących od głównego komponentu).

Warto jednak pamiętać, że niezależnie od tego,nad jaką aplikacją czy stroną www pracujemy, to przydadzą nam się również deklaracje w kontekście rozmiarów samych komponentów. Przykład buttonów na obrazku.

Źródło: https://designerup.co/blog/ui-design-pro-tips-buttons/

Jak tworzyć warianty, mogliście dowiedzieć się z poprzedniego wydania magazynu Product Design Magazine, w którym został dokładnie opisany ten krok.

Prawdziwe dane

Ostanim krokiem, który jest już wskazówką bazującą na mojej praktyce, jest to, by zawsze starać się odzwierciedlić prawdziwe dane aplikacji. Chodzi głównie o to, by nie używać wszędzie jak leci „Lorem ipsum dolor sit amet enim”, a jednak dodać prawdziwe dane, nazwy, tabele, które znajdą się w naszej aplikacji, bo tylko wtedy będziemy w stanie zaprojektować rozwiązania, a nie generować kolejne problemy użytkownika.

Ponieważ jest to samouczek do pierwszych kroków przy tworzeniu UI aplikacji, to chciałbym, aby dane, które będą wykorzystywane, również pojawiały się w naszym zbiorze predefiniowanych elementów – łatwiej sięgać po nie w momencie, kiedy są potrzebne.

Do tego wystarczy po prostu narzędzie tekstu i wklejenie poszczególnych zbiorów tekstów.

Zakończenie

Rozpoczynając każdy projekt od stworzenia wyżej wymienionych kroków, będziecie w stanie w bardzo łatwy sposób skalować swoje interfejsy, migrować z style guide’u do design systemu oraz zabezpieczać się przed ewentualnymi poprawkami na każdym artboardzie z osobna. Takie zabezpieczenie zaś zapewni Wam spokojny sen i łatwe wdrożenie nowych członków zespołu w przyszłości.