TL;DR:
- Dark mode wymaga innych decyzji niż light mode – nie można po prostu odwrócić kolorów, cienie i kontenery działają inaczej
- Inner shadows redukują visual noise – zamiast białych borders lepiej użyć subtelnych cieni, co zmniejsza ilość linii w interfejsie
- Opacity vs solid colors to fundamentalny wybór – każde podejście ma swoje konsekwencje dla całego systemu
- Border radius powinien skalować się z wysokością – 32px komponent → 8px radius, 36px → 10px, 40px → 12px
- Consistency jest ważniejsza niż perfekcja – te same style dla tabs, buttons i navigation tworzą spójność
- Steve Schoger testował kolory przez luminosity – wizualne sprawdzanie skoków między odcieniami w skali szarości
- Text wrapper z 4px padding balansuje optycznie – prosty trick na lepsze wycentrowanie tekstu z ikonami w buttonach
- Forma komponentu powinna odzwierciedlać interakcję – jeśli element tylko otwiera command palette, nie powinien wyglądać jak input field
Uwaga: Ten artykuł to notatki z live design critique session między Riddem (twórcą Inflight) a Jamesem McDonaldem (designerem znanym z pracy przy Tailwind CSS). Wszystkie opisane przemyślenia, techniki i obserwacje pochodzą od uczestników tej rozmowy. Sesja odbyła się na żywo przed ponad 2300 widzami i trwała blisko dwie godziny.
Jak ulepszyć interfejs, który już jest dobry?
Ridd pracował nad produktem Inflight przez ostatnie sześć miesięcy. Narzędzie koncentruje się na design feedback i dzieleniu się work in progress. Zaczynał od prostego pojedynczego linka do projektu, jednak po feedbackzie od użytkowników produkt ewoluował w kierunku dashboard dla zespołów – niemal „internal portfolio” pokazujące, nad czym pracuje każdy członek zespołu.
Interface działał, ale brakowało mu tego „czegoś”. Ridd czuł, że potrzebuje świeżego spojrzenia. Dlatego James zgodził się na sesję po kilku tygodniach namawiania. Dostał kilka kluczowych screenów z Figmy, a instrukcja była prosta: „zrób to lepiej”. Co ciekawe, była to pierwsza okazja, kiedy Ridd zobaczył koncepty Jamesa. Wszystko działo się na żywo, bez wcześniejszych ustaleń.
Niespodziewane zapotrzebowanie ze strony przedsiębiorstw zmienia filozofię designu
Przed zagłębieniem się w szczegóły techniczne, warto zrozumieć kontekst biznesowy. Ridd nie zakładał, że tworzy produkt korporacyjny, ale zespół doświadczył znacznie większego zainteresowania ze strony dużych firm niż przewidywał. To wpłynęło bezpośrednio na podejście do designu.
Według Ridda, celem było znalezienie równowagi między profesjonalizmem a unikalnym charakterem. Produkt musi działać dla przedsiębiorstw, jednocześnie zachowując „duszę” i nie będąc jedynie „crisp and clean”.
Inspiracją dla systemu theming był Craft Docs. Przez długi czas interfejs pozostawał w black & white z transparencies. Primary color (niebieski) pojawił się dopiero później, gdy zespół poczuł potrzebę większej branded presence.
Dlaczego dark mode jest trudniejszy niż myślisz
James od początku zauważył fundamentalną różnicę w projektowaniu. Dark mode zawsze jest trudniejszy niż light mode ze względu na konieczność operowania opacity dla backgroundów, co komplikuje projektowanie buttons na takich tłach.
Główne wyzwania dark mode:
- Konieczność operowania opacity dla backgroundów komplikuje projektowanie buttons
- Białe borders muszą być wystarczająco widoczne, przez co często stają się zbyt mocne
- Grayscale color scheme potęguje problemy z kontrastem
- Efektem końcowym jest visual noise i clutter na ciemnym tle
Ridd miał podobne doświadczenia. Długo używał opacity (5% i 10% białego) dla dwóch podstawowych odcieni, jednak w ciemniejszych kolorach skoki były zbyt duże. Nawet przy wartościach 700 czy 800 z palety Tailwind czuł, że robi się za jasno za szybko.
Rozwiązanie przyszło przez przeprojektowanie ciemniejszej połowy palety. Zamiast polegać wyłącznie na opacity, wziął hue koloru primary i ustawił go dla wszystkich color ramps. Następnie zmieniał tylko wartości brightness, co pozwoliło na używanie więcej solid colors.
Inner shadows zamiast borders – game changer w dark mode
James zaprezentował kluczową technikę, która redukuje ilość linii w interfejsie. Zamiast borders stosuje inner shadows, co znacząco zmniejsza visual noise.
Przykładem był active state dla navigation. Tam gdzie Ridd używał border, James zastąpił go inner shadow z obu stron. Rezultatem było mniej prostokątów i cleaner interface.
Korzyści z inner shadows w dark mode:
- Zmniejszenie liczby prostokątów i visual noise na stronie
- Subtelniejszy efekt wyróżnienia elementów
- Mniejsza inwazyjność niż w przypadku białych linii na ciemnym tle
- Zachowanie wyróżnienia elementów w kontrolowany sposób
James wyjaśniał, że białe linie na ciemnym tle po prostu dodają clutter. Inner shadow daje subtelniejszy efekt, jednocześnie wyróżniając element w mniej inwazyjny sposób.
Ridd początkowo projektował z myślą o „indented” look – kontenery miały wyglądać jakby były wciskane w tło. Używał ciemnego inner shadow na górze i jasnego na dole. Z kolei James wybrał jasne shadows z obu stron, dążąc do wrażenia elementów uniesionych z tła, nie wciskanych. To fundamentalnie zmienia filozofię interfejsu.
Podczas sesji wydarzył się zabawny moment. Ridd pokazał screenshot Restream login page, którą projektował James. Tam użyty był indented style – dokładnie ten, od którego James odchodził w Inflight. James przyznał się ze śmiechem do sprzeczności między tym co mówi, a tym co robi w innych projektach. To pokazuje ważną prawdę – nawet eksperci są niespójni, a kontekst ma znaczenie.
Dodatkowo James zauważył, że zbyt wiele prostokątów na stronie (sidebar w ramce, navigation w ramce, karty w ramkach) sprawia, że wszystko staje się zbyt boxy. Dlatego eliminowanie niektórych borders pomaga w zachowaniu balansu.
Systematyczne podejście do kolorów
James podzielił się techniką, której nauczył się od Steve’a Schogera z Tailwind. To metoda sprawdzania harmonii palety kolorów przez wizualizację w skali szarości.
Technika luminosity – krok po kroku:
- Weź całą paletę kolorów
- Nałóż na nią blending mode „luminosity”
- Obserwuj kolory w skali szarości od lewej do prawej
- Zidentyfikuj miejsca z za dużym skokiem wizualnym między odcieniami
- Dopracuj kolory generujące za duże skoki
- Powtarzaj proces aż przejścia będą wyglądać naturalnie
Steve Schoger spędzał mnóstwo czasu na dopracowywaniu palety Tailwind właśnie tą metodą. Ridd miał identyczny problem – skoki między wartościami 500 a 600 były za duże. Próby użycia takiego koloru jako tekstu na tle kończyły się niepowodzeniem.
James przyznał, że to pain point każdego designera. Mimo trudności, technika z luminosity rzeczywiście pomaga w znalezieniu balansu.
Dylematy UX, których nie widać na pierwszy rzut oka
Podczas sesji pojawiło się kilka fascynujących dylematów UX. To nie były wyłącznie decyzje wizualne – były to fundamentalne pytania o experience.
Search pattern: fake input czy real input?
Ridd umieścił w sidebar element wyglądający jak search input, ale działający inaczej – kliknięcie otwierało command palette zamiast pozwalać na bezpośrednie wpisywanie.
James od razu to zakwestionował, tłumacząc że kiedy widzi input field, spodziewa się możliwości pisania. Zaproponował prostsze rozwiązanie – przycisk „Search” bez fake input field. Kliknięcie = command palette. Jasne i uczciwe wobec użytkownika.
Istnieje jednak alternatywny pattern, który też może działać. Ridd pokazał, że command palette od razu wyświetla recent projects, więc user dostaje instant value, nawet jeśli to nie jest tradycyjne wyszukiwanie. James podsumował, że tak długo jak użytkownik może od razu zacząć pisać i search działa, rozwiązanie jest akceptowalne.
Profile placement: dlaczego na górze, nie na dole?
Kolejny nieoczywisty wybór dotyczył umiejscowienia profilu. W większości SaaS apps profil znajduje się na dole sidebara. Ridd umieścił go w głównej nawigacji, na równi z Dashboard, Hub i Activity.
Uzasadnienie było proste – Inflight ma coś z social media. Ridd porównał to bezpośrednio do Instagram:
Mapowanie do Instagram:
- Dashboard = Feed (content feed)
- Hub = People (zespół)
- Activity = Notifications
- Profile = Twój profil (internal portfolio)
W tej wizji profil to nie tylko „settings i account stuff”. To internal portfolio w zespole, gdzie można scrollować i widzieć timeline wszystkiego co zostało zshipowane. Skoro nie jest to typowy SaaS placement, nie powinien być w typowym SaaS miejscu.
Ridd przyznał, że otrzymywał już ten feedback wielokrotnie, więc rozwiązanie może się zmienić. Przedstawił jednak oryginalną logikę stojącą za tą decyzją.
Version history: jak oznaczać iteracje?
To był największy dylemat sesji. Ridd pokazał komponenty oznaczone jako V1, V2, V3, ale czuł, że to za sztywne rozwiązanie. Nie zawsze chodzi o całą nową wersję – czasem to powrót do czegoś, żeby zbadać jeden detal i otrzymać feedback od konkretnych osób.
Eksperymentowali z różnymi podejściami:
Opcje dla version markers:
- V1, V2, V3 – za techniczne, za heavy
- 1/3, 2/3, 3/3 – prostsze, ale nadal sugeruje linearity
- Tylko numeracja: 1, 2, 3 – jeszcze prostsze
- Segmented control do przełączania – interesujące, ale może być za subtle
- Custom labels zamiast numeracji – najbardziej flexible
Pod koniec sesji skłaniali się ku prostej numeracji (1, 2, 3) z możliwością custom labels. Chat sugerował, że „3” jest bardziej zrozumiałe niż „V3” i zajmuje mniej miejsca.
To pokazuje, jak wiele myślenia wymaga pozornie mała decyzja. Ridd nie chciał narzucić mentalnego modelu „versions”, ponieważ jego produkt jest bardziej fluid.
Border radius i jego związek z wysokością komponentów
Ridd zapytał, czy James ma system dla border radius w relacji do wysokości komponentów. James przyznał szczerze, że nie ma takiego systemu. Projektuje optycznie – jeśli coś wygląda zbyt rounded lub zbyt sharp, po prostu znajduje middle ground.
Dodał jednak ważną obserwację. Bardziej rounded buttons wydają się bardziej playful. Ponieważ Ridd pracował nad produktem, który musi działać dla przedsiębiorstw, ale wciąż ma mieć „duszę”, zmniejszył border radius – żeby było bardziej elegant niż fun.
Z kolei Ridd myślał o tym bardzo systematycznie:
Systematyczne podejście Ridda do border radius:
- 24px wysokość → 6px radius
- 32px wysokość → 8px radius
- 36px wysokość → 10px radius
- 40px wysokość → 12px radius
Zapytał wprost, czy overthinkuje to. Odpowiedź z chatu była mieszana – niektórzy robią tak samo, inni nie.
James finalnie użył 6px dla małych elementów i 16px dla większych kart. Jego zasada? Ustawić górną granicę (16px dla dużych kontenerów) i dolną (6px dla małych), a następnie stosować konsekwentnie.
Consistency vs flexibility w systemach designu
James wielokrotnie podkreślał znaczenie consistency. Jego active state dla navigation używał dokładnie tego samego stylu co active state dla tabs – to samo tło, te same shadows.
Tłumaczył, pokazując navigation i tabs obok siebie, że użycie innego rozwiązania tutaj niż tam wydawałoby się dziwne. Ridd początkowo miał różne style, jednak James je zunifikował. Rezultatem był interface odczuwalnie bardziej spójny.
Zasady consistency według Jamesa:
- Active states powinny używać tego samego stylu wszędzie
- Tabs, navigation items i podobne elementy – ten sam styl
- Small design decisions sumują się i tworzą spójność
- Primary actions mogą łamać zasady, bo muszą się wyróżniać
Istnieje jednak istotny wyjątek. Nie wszystko może być identyczne. James pokazał przyciski – tam użył zupełnie innego podejścia, ponieważ primary button to jeden z głównych elementów na stronie i powinien się wyróżniać.
Ridd miał button z subtle gradient overlay. James to zachował jako świadomy wybór – ten jeden element może łamać zasady, bo jest na tyle ważny.
Problem pojawił się z kolorem primary. W interfejsie dominował gray, więc pytanie brzmiało – gdzie użyć blue? James eksperymentował z dodaniem subtle blue gradient za active navigation item. Ridd był sceptyczny, nie chcąc przesadzić z branded colors. Wniosek? Używać primary color oszczędnie i strategicznie.
Ciekawy detal techniczny: James użył 1.5 pixel border na sidebar divider. To nietypowe rozwiązanie – większość designerów używa pełnych pixeli albo half pixels. Czasami jednak 1 pixel to za mało, a 2 to za dużo. James nie bał się złamać „zasady”.
Podobnie z notification badge – zamiast square shape użył 24×20. Malutki detal, ale świadomy, dodający character.
Light mode to nie odwrócony dark mode
Podczas przejścia do light mode prawda stała się oczywista. Nie można po prostu przełączyć kolorów.
James był bardzo jasny w swojej ocenie: „Dark mode czasami jest jak feature. Musisz traktować go trochę inaczej, bo nie dostaniesz one-to-one na shadows i takich rzeczach.”
Przykładem była sytuacja z inner shadows dla kontenerów. W dark mode działały świetnie, ale w light mode biały container z białym inner shadow nie ma sensu.
Kluczowe różnice między light a dark mode:
- Inner shadows działają inaczej (biały container z białym inner shadow nie ma sensu)
- Light mode potrzebuje szarego tła z białymi kartami dla kontrastu
- Full white background = brak kontrastu, elementy się nie odrywają
- Buttons wyglądają asymetrycznie (biały button w dark mode wygląda źle, ciemny w light mode świetnie)
- Borders i shadows mają zupełnie inne zastosowanie
Podejście Jamesa do light mode: szare tło (bardzo jasny gray) z białymi kartami uniesionymi na nim. Dlaczego nie full white background? Ponieważ wtedy nie ma kontrastu i elementy nie mogą się oderwać od tła.
Dodatkowym problemem okazał się feature automatycznego gradient theming w Inflight. Kiedy użytkownik uploaduje obraz, system analizuje go i generuje matching gradient. Można też wybrać preset. Ten gradient może być dosłownie czymkolwiek.
To komplikuje decyzje o background colors znacząco. Jeśli karta projektu może mieć dowolny gradient jako tło, nie można zrobić jej szarą – musi być biała. A jeśli karty są białe, to główny background musi być szary dla kontrastu. Ridd zauważył, patrząc na różne kombinacje, że to zmienia wszystko.
Ridd marzył o single variable mode switcher w Figmie – jedna zmiana, wszystko się przełącza. James szybko pokazał, dlaczego to nie zadziała. Buttons wyglądają inaczej, shadows działają inaczej, nawet borders potrzebują innych wartości. W dark mode biały button nie wygląda dobrze, podczas gdy w light mode ciemny button wygląda świetnie. To fundamentalna asymetria.
James wspominał, że zawsze mieli te dyskusje w Clerk i Tailwind. Light mode i dark mode wymagają osobnych decyzji – to nie jest tylko kwestia techniczna, to design challenge.
Praktyczne tricki z Figmy
Ridd pokazał kilka swoich workflow tricks wartych zapamiętania.
Text wrapper z 4px padding
Kiedy projektuje się button z tekstem i ikoną, nie należy dodawać ikony bezpośrednio do frame’a.
Jak to zrobić:
- Zawiń tekst w osobny frame z 4px padding
- Dodaj ikonę obok tego wrappera (nie wewnątrz)
- Ustaw 12px space dla ikony od krawędzi
- Ustaw 12px space dla text wrappera od krawędzi
Dlaczego to działa? Optyczny balans. Ikona ma 12px space od krawędzi, tekst też ma 12px. Ale przez wewnętrzny 4px padding tekst wizualnie ma 16px i wygląda wycentrowany. Ridd wspomniał, że zrobi z tego całą lekcję w kursie.
Workflow do szybkich iteracji komponentów
Gdy komponent jest użyty w wielu miejscach i trzeba go zmienić bez wielokrotnego powtarzania tej samej czynności: Select layers by name → wybierz wszystkie instance → break components → Master plugin → create components from objects. Plugin cykl przez wszystkie i zrobi je głównymi komponentami. Następnie zostaw jeden, usuń resztę. Edycja tego jednego aktualizuje wszystko.
Jeśli potrzebna jest poprzednia wersja? Zduplikuj artboard i użyj „Destroy instances” – to daje snapshot do porównania.
Half pixel borders
James używa ich dla icons, ale nigdy dla button strokes. Czasami dla dividers między sekcjami. Ridd używał ich częściej, ale po komentarzach Jamesa zaczął się zastanawiać, czy nie za często. James podsumował, że half pixels mogą być scary.
Podobnie z dash lines – kiedy James ich używa, trzyma dash małe, nie za długie, żeby nie rozpraszały.
Checklisty do wykorzystania
✅ Checklist: Dobry design w dark mode
Przed finalizacją dark mode, zadaj sobie pytania:
- Czy w moim interfejsie są zbędne kontenery lub ramki, które mogę usunąć?
- Czy zamiast twardej ramki mogę użyć delikatniejszego efektu, np. cienia wewnętrznego?
- Czy wszystkie aktywne elementy (np. w nawigacji i zakładkach) wyglądają identycznie?
- Czy moje kolory są precyzyjnie zdefiniowane, czy polegam na przezroczystości?
- Czy kolor marki jest używany strategicznie, czy może dominuje w interfejsie?
- Czy wygląd interaktywnych elementów jasno komunikuje, jak one działają?
- Czy skoki między odcieniami w palecie są harmonijne? (test luminosity)
- Czy przypadkiem nie mam za dużo prostokątów/containers na stronie?
✅ Checklist: Przejście z dark mode na light mode
Jeśli projektujesz light mode po dark mode:
- Czy zmieniłeś strategię dla shadows? (nie możesz użyć tych samych)
- Czy background jest szary zamiast białego dla kontrastu?
- Czy białe karty unoszą się na szarym tle?
- Czy buttons mają odpowiednie rozwiązanie? (ciemne w light mode działają lepiej)
- Czy borders mają dostosowane wartości opacity?
- Czy containers nie tracą definicji przez brak kontrastu?
- Czy uwzględniłeś, że user-generated content może mieć dowolne kolory?
- Czy zrobiłeś test obok siebie, porównując oba tryby?
✅ Checklist: UX patterns wymagające validation
Kiedy projektujesz nietypowe rozwiązania:
- Czy fake input field (który otwiera modal) nie wprowadzi użytkownika w błąd?
- Czy umiejscowienie profilu w nawigacji ma uzasadnienie w produkcie?
- Czy system versioning/labeling nie jest zbyt rigid dla use case?
- Czy otrzymujesz ten sam feedback wielokrotnie? (może trzeba przemyśleć decyzję)
Co zostało na koniec
Sesja trwała prawie dwie godziny zamiast planowanej jednej. Pod koniec Ridd i James eksperymentowali z light mode, próbując różnych kombinacji backgrounds i cards.
Nie doszli do perfekcyjnego rozwiązania. To jest właśnie kluczowe – design to proces iteracyjny. Nawet na żywo, przed 2300 ludźmi, nie ma magicznej odpowiedzi, która rozwiązuje wszystko od razu.
James kilka razy powtórzył, że to trial and error, zależny od projektu. Zasady pomagają, ale ostatecznie trzeba patrzeć i czuć, co działa.
Ridd żartował na koniec, że naprawdę ma nadzieję, iż ludzie nie wyjdą z tego myśląc, że są out of touch millennial wannabe streamers. Prawda jest jednak inna – to była sesja pokazująca prawdziwą pracę designerską. Z dylematami, powrotami do poprzednich decyzji i przyznawaniem się do błędów. James mówił „I don’t know” więcej razy niż dawał definitywne odpowiedzi.
Sesja pokazała też, że nawet eksperci są niespójni. James przyznał się do sprzeczności między tym co mówi a tym co robi. Ridd wielokrotnie mówił „może overthinkuję”. To normalne. Design to nie matematyka z jednoznacznymi odpowiedziami.
To proces. Conversation. Iteration. Jak podsumował to Ridd: czasem trzeba zaprosić kogoś z zewnątrz, by zobaczyć to, co dla nas samych już przestało być oczywiste.
Kluczowy insight
Forma podąża za interakcją
Standardowo myślimy: Komponenty powinny wyglądać zgodnie z przyjętymi wzorcami. Pole wyszukiwania musi wyglądać jak pole do wpisywania, przycisk do filtrowania jak rozwijana lista.
W praktyce okazuje się, że: Forma komponentu powinna odzwierciedlać faktyczną interakcję, a nie tylko jego nazwę. Jeśli „pole wyszukiwania” nie służy do pisania, a do otwarcia palety komend (Cmd+K), jego design powinien komunikować rolę „wyzwalacza”, a nie pola tekstowego.
Dlaczego to jest istotne: Unikamy mylenia użytkownika i budujemy bardziej intuicyjny interfejs. Ślepe podążanie za wzorcami wizualnymi, bez uwzględnienia rzeczywistej funkcji, prowadzi do niespójnego doświadczenia i frustracji.
Test na jutro: Następnym razem gdy będziesz projektować element, który jedynie inicjuje akcję (otwiera modal, filtr, paletę komend), zamiast nadawać mu wygląd standardowego komponentu (np. inputa), spróbuj świadomie zredukować jego formę do roli wyzwalacza – usuwając tło i ramki. Sprawdź, czy intencja elementu stała się bardziej oczywista.
Polecane do dalszej eksploracji:
- Dokumentacja Tailwind CSS (palety kolorów stworzone przez Steve’a Schogera)
- Clerk design system (przykłady pracy Jamesa z light/dark mode)
- Craft Docs (inspiracja dla theming system)
- Figma community – szukaj pluginów: Master, Select Similar, Destroy Instances
Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je w transkrypcie sesji live design critique między Riddem a Jamesem McDonaldem.