TL;DR

Technical designer to hybryda – osoba z mentalnością inżyniera i wizją użytkownika, która projektuje systemy a nie tylko ekrany
Kluczowe umiejętności – rozumienie technologii, współpraca z zespołami backendowymi, krytyczne myślenie i wrażliwość na warsztat
Firmy technologiczne potrzebują specjalistów – szczególnie te z bardzo technicznymi produktami gdzie design stał się prawdziwym wyróżnikiem
Kodowanie nie jest konieczne – ważniejsze jest rozumienie medium: API, JSON, wydajność, skalowalność
Rekrutacja na mentalność – lepiej zatrudniać osoby z ciekawością technologii niż z gotowym doświadczeniem programistycznym
Nauka przez pytania – designerzy nietechniczni powinni dużo pytać inżynierów i uczestniczyć w planowaniu sprintów
Granice ról się zacierają – szczególnie z narzędziami AI, jednak wartość designera leży w kształtowaniu architektury i kompromisów

Poniższe notatki pochodzą z rozmowy Tom Scott z Emilio Garcia (VP of Design w Onum) – designerem z 25-letnim doświadczeniem w kierowaniu zespołami projektowymi w firmach takich jak New Relic, Eventbrite czy CARTO. Wszystkie przedstawione przemyślenia, obserwacje i wnioski należą do rozmówców.

Branża designu przechodzi gwałtowne zmiany. Role się łączą, produkty stają się bardziej złożone, natomiast narzędzia AI przekształcają sposób pracy. W tej rzeczywistości pojawia się fundamentalne pytanie – co właściwie czyni designera „technicznym”?

Garcia, z perspektywą ćwierć wieku w branży, przedstawia praktyczne spojrzenie na ewoluującą rolę technical designera. Jego doświadczenie w tworzeniu produktów dla wiodących firm technologicznych daje unikalny wgląd w to, jak projektować w świecie coraz bardziej technicznych produktów.

Jak zdefiniować „technical designer” w 2025 roku

Według Garcia, technical designer to projektant produktu z mentalnością inżyniera i wizją użytkownika – osoba poruszająca się swobodnie między złożonością techniczną a łatwością użytkowania.

Jest to hybryda łącząca strategiczną wizję opartą na doświadczeniu projektanta produktu z umiejętnością rozumienia, projektowania i prototypowania rozwiązań dla bardzo złożonych produktów technicznych. Garcia podkreśla, że nie chodzi tylko o interfejs czy doświadczenie, lecz o aktywną rolę w projektowaniu funkcjonalnym, architekturze koncepcyjnej i wykonalności technicznej. Równie ważne jest rozumienie tego, co firma sprzedaje i wizji Go to Market – co powinno być wspólne dla wszystkich typów designerów.

Kluczowe różnice technical designera:

Kompleksowe rozumienie technologii – jak produkt działa i projektowanie systemów, nie tylko ekranów
Ścisła współpraca z zespołami inżynierskimi – nie tylko frontend, ale rozumienie jak działają API i dlaczego może być potrzebny przycisk „Zapisz filtry” lub jakie konsekwencje techniczne może mieć zapisywanie w locie
Krytyczne myślenie – gdy programista mówi „potrzebuję przycisk który robi to”, designer rozumie dlaczego i znajduje idealne rozwiązanie dla użytkownika
Silna kultura tech – próbowanie nowych produktów i bycie na bieżąco z trendami rynkowymi

Garcia dodaje jeszcze jeden element – szczególną wrażliwość na warsztat. Jego zdaniem, produkty techniczne były postrzegane jako bardziej funkcjonalne niż piękne, jednak to się zmienia i te dwa elementy nie powinny się wzajemnie wykluczać.

Gdzie technical designerzy są najbardziej potrzebni

Garcia zawsze preferował firmy z wysokim poziomem wiedzy technologicznej – miejsca gdzie technologia jest naprawdę kluczowa. Rynek produktów technicznych rośnie szybko, dlatego Garcia widzi ogromną szansę na poprawę designu w tym obszarze.

Istnieje jednak pewne zastrzeżenie – Garcia zna fantastycznych designerów którzy pracowali w takich firmach, ale zdecydowali się odejść bo zdali sobie sprawę, że tak naprawdę nie podobał im się ten obszar. Szukali produktów bardziej namacalnych i mających znacznie szerszą, bardziej powszechną bazę użytkowników. Pierwszy krok do podjęcia takiej roli – musisz naprawdę lubić lub przynajmniej być szczerze zainteresowany tym sektorem.

W firmach skoncentrowanych na B2C dojrzałość designu osiągnęła naprawdę wysoki poziom, z kolei w firmach technicznych jest jeszcze długa droga do przejścia. Największy problem z jakim borykały się firmy techniczne – praca nad designem była często wykonywana przez samych inżynierów lub designerzy byli postrzegani jako osoby które „sprawiają, że ekrany ładnie wyglądają” po fakcie.

Sytuacja jednak całkowicie się zmieniła. Garcia wskazuje na przykłady firm robiących to dobrze – GitHub nie stałby się tym czym jest bez mentalności ceniącej design. Podobnie Vercel robi niesamowite rzeczy z designem ostatnio, natomiast Tines fantastyczną pracę z językiem wizualnym.

W Onum, CEO zawsze podkreślał że design powinien być jednym z elementów różnicujących i musi być obecny od samego początku. Każdy Pull Request wpływający na interfejs wymaga zatwierdzenia przez design. Czas na podjęcie przez użytkownika decyzji czy to co używa sprawia dobre wrażenie skurczył się do zaledwie kilku sekund.

Case study Onum – system projektowy przed product-market fit

Garcia ma ciekawy wgląd z budowania Onum od zera. Szczerze przyznaje: „będąc w 100% szczery—tak naprawdę nie wiedziałem w co się pakuję” gdy CEO przedstawił mu pomysł. Spędził kilka miesięcy na badaniu konkurencji, czytaniu o logach i różnych formatach, pracując nad zdefiniowaniem solidnego systemu do nawigacji i konsumpcji informacji.

Jedna z najważniejszych decyzji – rozpoczęcie od samego początku z systemem projektowym. Garcia podważa popularny mit: „Zawsze istniał pogląd że startupy nie powinny spędzać czasu na systemie projektowym dopóki nie mają jasnego product-market fit”.

Garcia doświadczył jednak na własnej skórze bólu braku solidnych fundamentów. Gdy dług techniczny i projektowy zaczyna się nawarstwiać, praktycznie niemożliwe jest wdrożenie systemu projektowego później. Zaczęli od małego, z jasną bazą, ale z kontrolą nad zarządzaniem tokenami. Niemal pierwszą rzeczą było połączenie między Figma i GitHub, żeby dodawanie lub modyfikacja tokena nie była problemem dla zespołu inżynierskiego.

Doświadczenie z New Relic – kontekst techniczny ma znaczenie

W New Relic Garcia dołączył podczas kończenia migracji ze starego New Relic do New Relic One. Kluczowy wgląd: nowy krajobraz w architekturze oprogramowania przynosi nowe potrzeby dla narzędzi obserwacyjności. Przetłumaczyli definiujące charakterystyki architektur opartych na chmurze na podstawowe zasady projektowe New Relic One – produktu zbudowanego od zera dla nowej rzeczywistości.

Czy designerzy powinni kodować – praktyczna perspektywa

Garcia daje krótką odpowiedź: tak, w 100%. Długa odpowiedź brzmi jednak: to zależy.

Wszystko zależy od tego co oznacza „programowanie”. Gdy mówimy o designerze znającym kodowanie, myślimy o HTML/CSS/JS. Garcia uważa jednak że zakres musi się trochę poszerzyć – nie tylko kodowanie, ale rozumienie samej technologii: jak działa API, jak zamienić JSON w interfejs, ile zapytań potrzeba dla płynnego doświadczenia użytkownika.

W Onum mają automatycznie generowane ekrany z plików YAML. Wyzwanie polega na zrozumieniu jak to działa i jak reprezentować różne grupy. Garcia porównuje to do grafika znającego działanie maszyny drukarskiej czy projektanta mody rozumiejącego tkaniny.

Potrzebujemy równowagi – między znajomością kodowania (i projektowaniem rozwiązań łatwych do wdrożenia) a nie pozwalaniem tej wiedzy ograniczać innowacyjnego myślenia. Jak mówił Steve Jobs – rozwiązania które sprawiają, że technologia służy potrzebom użytkownika, a nie na odwrót.

Gdzie kończy się design a zaczyna development

20 lat temu Garcia miał moment niepewności czy jego kariera pójdzie w kierunku zostania programistą. Wybrał ścieżkę designu – ale zawsze z jednym okiem na kod. Kiedyś granice były jasno określone, jednak teraz ta linia staje się coraz bardziej rozmyta – szczególnie z narzędziami AI.

Garcia rysuje granicę między możliwością wdrażania kodu do produkcji a „tylko” tworzeniem prototypów. Różnica między znajomością kodowania a faktycznym wdrażaniem rzeczy do produkcji jest kluczowa. Garcia wdrażał rzeczy do produkcji w wielu poprzednich firmach, ale uważa że chyba że to bardzo specyficzna praca (poprawki, drobne zmiany) lub zależnie od typu firmy – największa wartość designera nie leży w wdrażaniu rzeczy do produkcji.

Posiadanie tej „tajnej broni” może być kluczowe w pewnych momentach. Tam gdzie jednak ten typ designera naprawdę się wyróżnia to rozumienie ograniczeń, posiadanie opinii na temat części architektury i zapewnienie że wszystko składa się w solidne doświadczenie użytkownika.

Jak budować technical fluency w zespole

Garcia ma ogólną zasadę: zatrudniaj pod kątem mentalności uczenia się i współpracy, rozwijaj konkretne umiejętności techniczne wewnętrznie. W ten sposób dostajesz designerów którzy dostosują się do unikalnego stosu technologicznego zamiast tylko tych którzy już go znają.

Checklist: Na co zwracać uwagę podczas rekrutacji technical designera

✓ Ciekawość technologii ponad czyste doświadczenie w kodowaniu
✓ Designer który pyta „Jak działa ten endpoint?” będzie się szybko uczył
✓ W rozmowach – daj proste diagramy systemów, ograniczenia lub dokumentację API żeby zobaczyć jak myślą
✓ Poprzednia współpraca z inżynierami – bliska praca z programistami i dostosowywanie designów do realiów backendu
✓ Sposób prezentacji portfolio – statyczne PDF dla ról technicznych już coś mówi

Rozwijanie technical fluency w zespole

Nawet najbardziej doświadczeni nowi pracownicy będą mieli luki w stosie technologicznym produktu, dlatego uczenie się musi być częścią kultury zespołu. Garcia podkreśla znaczenie uczestnictwa designerów w planowaniu sprintów i doskonaleniu backlogu. Przeglądy pull requestów, jeśli to możliwe, dają znacznie więcej kontekstu.

Coś co dobrze działało to praca designerów i inżynierów ramię w ramię przy prototypowaniu przepływów z prawdziwymi danymi – przybliżanie rzeczywistych ograniczeń deweloperskich do designerów.

Jak technical fluency zmienia współpracę

Współpraca jest znacznie łatwiejsza gdy mówisz tym samym językiem i wszyscy są w tym samym miejscu. Oczywiście czasami są napięcia wokół granic, jednak często naciskanie na poprawę doświadczenia oznacza że nie zawsze jest łatwo.

Garcia ma realistyczne podejście: „ludzie zawsze mówią o byciu w 100% zgodni, a to dość trudne do osiągnięcia”. Te małe różnice zdań – ostatecznie sprawiają że rezultat jest znacznie lepszy dla użytkownika. Firma potrzebuje pewnego poziomu dojrzałości produktowej i kultury designu żeby dobrze to obsłużyć.

Kluczowe jest wczesne zaangażowanie – Garcia podkreśla, że gdy mówi o designie w produktach technicznych, nie skupia się na stronie wizualnej ale całym doświadczeniu. Jeśli dołączysz do dyskusji za późno, możesz odkryć że decyzje techniczne zostały już podjęte i tworzą ograniczenia – i bez względu na to jak bardzo starasz się znaleźć najlepsze rozwiązanie, już jesteś uwięziony.

Praktyczne wskazówki dla designerów nietechnicznych

Garcia podkreśla: zadawanie wielu pytań nie czyni cię gorszym designerem. Gdy dołączasz do firmy z bardzo technicznym produktem, najlepszy sposób na poprawę to zadawanie pytań, rozmowy z product managerami i szczególnie z inżynierami.

Checklist: Jak rozwijać się jako designer nietechniczny

✓ Zadawaj pytania wcześnie i często – dużo pytaj inżynierów i product managerów
✓ Staraj się zrozumieć jak to jest zbudowane – architektura produktu (nie musi być 100% każdej części)
✓ Proś o konkretną opinię i celowe pytania o to co musisz wiedzieć

Umiejętności techniczne do opanowania: ✓ Kluczowe koncepcje: API, bazy danych, architektura klient-serwer, usługi chmurowe, mikrousługi
✓ Czytaj prawdziwą dokumentację API i ćwicz proste integracje używając narzędzi jak Postman
✓ Zgłębiaj wydajność, bezpieczeństwo, skalowalność żeby rozumieć decyzje techniczne
✓ Zapoznaj się z SQL, JSON, strukturami danych do prototypowania i analizowania informacji

Garcia dodaje: znajdź firmę gdzie jest lider który pomoże ci rosnąć – ktoś kto może przewodzić przykładem. Często lepiej dołączyć do zespołu z powodu managera niż z powodu samego projektu.

Jak oceniać głębokość techniczną na rekrutacji

Garcia zwraca uwagę na sposób prezentacji portfolio. W przypadku pewnych ról, pokazywanie statycznego PDF – bez względu na to jak dobre – już coś mówi.

Kluczowe wyzwania do przetestowania podczas wywiadu:

Problemy z obsługą danych w czasie rzeczywistym – jak myślą o aktualizacjach w czasie rzeczywistym
Wizualizacje danych – jak wybierają typy dla odbiorców technicznych
Planowanie stanów błędu – komunikaty błędów, stany ładowania, aktualizacje
Skalowalność i łatwość utrzymania – czy biorą to pod uwagę w projektach

Czy technical designers myślą inaczej o designie

Garcia nie uważa żeby powinni myśleć w fundamentalnie inny sposób. Każdy designer powinien mieć głębokie zrozumienie branży w której pracuje – projektowanie doświadczenia bez znajomości jak wszystkie elementy działają zostawi cię z ograniczeniami.

Jako designerzy mamy obowiązek budować lepszy internet. Ostatnio po prostu powtarzamy wzorzec za wzorcem, tworząc rzeczy bez duszy. Garcia wierzy że zarówno technical designerzy jak i każdy inny projektant produktu musi naciskać na innowacje i tworzyć doświadczenia które urzekają użytkownika od samego pierwszego momentu.

Przykład – możesz lubić lub nie najnowsze trendy designu w iOS, jednak jasne że przynajmniej próbują innowować, stworzyć coś innego.

Kluczowy insight

System projektowy przed PMF

Standardowo myślimy: Startupy powinny czekać z systemem projektowym do osiągnięcia product-market fit, bo wcześniej to strata czasu i zasobów.

W praktyce okazuje się, że: Garcia doświadczył na własnej skórze że gdy dług techniczny i projektowy zaczyna się nawarstwiać, praktycznie niemożliwe jest wdrożenie systemu projektowego później. W Onum zaczęli od systemu projektowego jako jedną z pierwszych rzeczy – połączenie między Figma i GitHub żeby zarządzanie tokenami nie było problemem.

Dlaczego to jest istotne: Ból braku solidnych fundamentów jest znacznie większy niż koszt wczesnej inwestycji. Dług techniczny i projektowy narasta wykładniczo i może zabić skalowanie produktu.

Test na jutro: Następnym razem gdy zaczynasz nowy projekt, zamiast zostawiać system projektowy „na później” spróbuj zdefiniować podstawowe tokeny i komponenty jako fundament i sprawdź jak bardzo to ułatwia kolejne decyzje projektowe.

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 tutaj: What makes a designer technical?

Tag: Designer Developer Collaboration

Co czyni designera technicznym? Praktyczny przewodnik na 2025 rok #EN255