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.

Tag: Inner Shadows

Sekrety designu w dark mode – analiza live critique session z Jamesem McDonaldem #EN328