Te notatki powstały na podstawie rozmowy z Gavinem Nelsonem w podcaście Dive Club. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od rozmówcy i zostały przeze mnie jedynie uporządkowane dla lepszej przyswajalności.

TL;DR

Projektowanie mobilne wymaga myślenia o kontekście: użytkownicy korzystają z aplikacji w 1-2 minutowych sesjach, często jedną ręką
Prototypy wysokiej jakości to „uniwersalny język” zespołu – eliminują potrzebę długich prezentacji
Fizyczność interakcji na urządzeniach mobilnych różni się od interfejsów komputerów stacjonarnych – dotyk wymaga odpowiedzi naśladujących fizyczny świat
Nauka programowania dla projektantów opiera się na podstawach: tablice, instrukcje warunkowe i pętle
Iteracyjny proces polega na ciągłym duplikowaniu, testowaniu małych zmian i ewolucji pomysłów
ChatGPT jako mentor: strategia „naucz mnie jak” zamiast „zrób to za mnie”
Opowiadanie równie ważne jak projektowanie: przekonanie zespołu to druga połowa pracy projektanta

Projektowanie mobilne to znacznie więcej niż zmniejszenie interfejsu komputera stacjonarnego do rozmiaru telefonu. Gavin Nelson, projektant odpowiedzialny za aplikacje mobilne GitHub i Linear, zaczynał swoją przygodę od rysowania ikon piksel po piksel. Dziś dzieli się swoją perspektywą na projektowanie dla urządzeń dotykowych oraz znaczenie prototypowania w procesie twórczym.

Od ikon piksel po piksel do aplikacji mobilnych

Nelson rozpoczął swoją przygodę z projektowaniem w liceum, kiedy zdał sobie sprawę, że ikony na komputerze to ręcznie tworzona sztuka cyfrowa. Jego pierwsza ikona przedstawiała ustawienia w rozdzielczości 64 pikseli – każdy piksel umieszczał indywidualnie na płótnie.

„Spojrzałem na te piękne 1024-pikselowe ikony, przybliżyłem bardzo blisko i zobaczyłem każdy pojedynczy piksel. Pomyślałem, że oni po prostu umieścili te piksele na płótnie” – wspomina Nelson. Szybko jednak zorientował się, że to nie tak właśnie powstają ikony.

Ta ciekawość rozwinęła się organicznie. Nelson nigdy nie myślał o projektowaniu jako karierze – robił to z pasji i ciekawości poznawczej. Dopiero dzielenie się wynikami naturalnie utworzyło sieć klientów freelance, co pozwoliło mu kontynuować tę pracę bez ryzyka wypalenia zawodowego.

Metoda ciągłego duplikowania

Z pracy nad ikonami Nelson wyniósł konkretną metodę iteracji, którą stosuje do dziś w projektowaniu produktowym. „Jestem serial duplicator ramki czy obszaru roboczego – robię jedną małą zmianę, porównuję z poprzednim, duplikuję lepszy, robię kolejną zmianę”.

Ta metoda ciągłego eksperymentowania tworzy wprawdzie bałagan w plikach projektowych, jednak pozwala systematycznie znajdować najlepsze rozwiązania. Trudną częścią jest natomiast wiedzieć, kiedy przestać iterować i zakończyć proces.

Jak fizyczność zmienia sposób myślenia o projektowaniu

Nelson podkreśla fundamentalną różnicę między interakcjami na urządzeniach mobilnych a komputerach stacjonarnych. Dotyk wprowadza zupełnie inny sposób komunikacji z interfejsem, dlatego projektanci muszą przeprogramować swoje myślenie.

Kluczowe różnice między dotykowym a stacjonarnym:

Komputer stacjonarny: mysz tworzy cyfrowe połączenie, stany najechania, skróty klawiaturowe
Urządzenia mobilne: fizyczny dotyk, wielodotykowe gesty, brak drugiego wejścia
Oczekiwania użytkowników: interfejs musi reagować jak fizyczne obiekty

Apple i iOS wprowadziły interakcje oparte na fizyce, które stały się standardem branżowym. Gdy użytkownik naciska na element, powinien on zareagować na ten nacisk w sposób przypominający rzeczywiste obiekty.

Doskonałym przykładem jest inercyjne przewijanie na iOS. Gdy użytkownik przewija listę i dociera do końca, zawartość lekko „odbija się” jak gumka, a następnie łagodnie wraca na miejsce. Większość użytkowników nie zauważa tego efektu świadomie, ale jego usunięcie sprawia, że interfejs zaczyna działać dziwnie.

Ciekawym przykładem jest również „shake to undo” na iOS. Gdy użytkownik frustruje się telefonem i potrząsa nim, system pyta, czy chce cofnąć akcję. Mimo że funkcja nie jest perfekcyjnie wykonana, intencja stojąca za nią była świetna – wykorzystanie naturalnej reakcji na frustrację.

Dziedziczenie fundamentu po Alex Cornell

Nelson dołączył do Linear po roku eksploracji przeprowadzonej przez Alex Cornell. „Alex poświęcił dużo czasu na przemyślenie, jak Linear mógłby wyglądać na urządzeniach mobilnych, gdybyśmy zaczęli od zera” – wyjaśnia Nelson.

Cornell stworzył solidny fundament, który Nelson odziedziczył i mógł rozwijać dalej. Krótko po dołączeniu Nelsona zespół wysłał aplikację iOS do pierwszych beta testerów, co pozwoliło mu skupić się na budowaniu na istniejącej podstawie oraz przetwarzaniu opinii zwrotnych użytkowników.

Zajmuje bowiem dużo czasu, żeby być pewnym fundamentalnego kierunku aplikacji. Cornell spędził ten czas na tej pracy, dzięki czemu Nelson mógł wejść na nieco innym etapie i pracować nad różnymi problemami.

Kontekst użytkowania kształtuje każdą decyzję

Ludzie używają telefonu w krótkich, 1-2 minutowych sesjach – często jedną ręką podczas wyprowadzania psa czy innych czynności. Każde wprowadzenie tarcia czy powtarzalnych akcji jest w takim kontekście mocno odczuwalne przez użytkowników.

Nelson opisuje to jako niezbędną zmianę mentalności projektowej. Łatwo jest zaprojektować rozwiązanie wymagające trzech czy czterech tapnięć, jednak w praktyce okazuje się to frustrujące dla użytkowników korzystających z aplikacji w ruchu.

Dlatego warto zacząć od inteligentnych domyślnych ustawień i być bardziej kreatywnym w podejściu do problemów. Chodzi o destylację złożonych procesów do najbardziej bezbolesnej formy dla użytkownika końcowego.

Niewidzialny szlif jako cel projektowania

Nelson używa pojęcia „niewidzialnego szlifu” do opisania najlepszych aplikacji mobilnych. To jakość, która sprawia, że interfejs schodzi na dalszy plan, pozwalając użytkownikowi skupić się wyłącznie na zadaniu.

Jako przykłady podaje aplikację Things, którą używa od ponad 10 lat. „Mogę dodawać zadania szybko, ustawiać terminy, przestawiać rzeczy – wszystko naprawdę bez myślenia o tym, co robię” – opisuje Nelson. Aplikacja nigdy nie staje mu na drodze do produktywności.

Podobnie Netflix, mimo że to aplikacja rozrywkowa, „nie ma prawa być tak dobrze zaprojektowana, jak jest”. Gdy znajdziesz film, możesz go tapnąć, odrzucić gestem podczas przewijania, a nagłówek elegancko się zmniejsza, robiąc miejsce na treść.

Gestów nie widać, ale można ich nauczyć

Gesty przesuwania to potężny wzorzec pozwalający na szybkie akcje, ale nie są odkrywalne dla nowych użytkowników. Mobilne systemy operacyjne wciąż nie rozwiązały tego problemu w sposób idealny.

Obecnym rozwiązaniem branży jest zapewnienie widocznego sposobu wykonania tej samej akcji. Usunięcie powiadomienia może wymagać trzech tapnięć przez menu, ale można też przeciągnąć je przez ekran gestem. Jest to znacznie szybciej, ale tylko jeśli użytkownik wie, że taka opcja istnieje.

Nelson zawsze próbuje znaleźć subtelne sposoby podpowiadania użytkownikom o istnieniu takich gestów. To sposób na wprowadzanie ich w bardziej płynne sposoby korzystania z aplikacji, podobnie jak skróty klawiaturowe zwiększają produktywność na komputerach stacjonarnych.

Kiedy sięgać po niestandardowe komponenty

Nelson pracował zarówno w środowisku GitHub (standardowe komponenty) jak i w Linear (własny system projektowania). Nelson zaczyna zawsze od standardowych komponentów i dopiero potem rozważa niestandardowe rozwiązania.

Zalety standardowych komponentów:

Dostępność: Apple i Google wbudowały wymagania dostępności
Aktualizacje: nowe API z WWDC automatycznie dostępne
Znajomość: użytkownicy znają sposób działania
Szybkość: mniej pracy programistycznej

Kiedy sięgać po niestandardowe rozwiązania:

Standardowe komponenty nie spełniają funkcji wystarczająco dobrze
Potrzebujesz spójności z tożsamością marki
Rozwiązujesz unikatowy problem UX

Główną zasadą jest jednak nie zmuszanie użytkowników do ciągłego uczenia się nowych sposobów korzystania z telefonu.

Prototypowanie jako uniwersalny język zespołu

Według Nelsona prototypy wysokiej jakości to „uniwersalny język” otrzymywania opinii zwrotnych i testowania pomysłów z zespołem. Gdy projektant ma prototyp nieodróżnialny od produkcji, może po prostu dać go komuś i poprosić o wykonanie konkretnego zadania.

„To prawdziwy test użytkownika w pewnym sensie – czy potrafią to zrobić? Czy uważają to za łatwe?” – tłumaczy Nelson.

Gdy prototyp może być całkowicie chaotycznym kodem w tle, ale tworzy wysokiej jakości doświadczenie, staje się podstawą do rzeczywistego testowania. Projektant nie musi spędzać tygodni czy miesięcy na faktycznym budowaniu, żeby sprawdzić pomysł z użytkownikami.

Gdy interakcja jest rdzeniem rozwiązania

Nelson opisuje konkretny przykład z Linear, gdzie pracował nad problemem obejmującym widok przewijania z panelem dolnym na górze. Jego pomysł polegał na tym, że tapnięcie w różne części widoku przewijania powoduje rozwijanie lub zwijanie panelu dolnego, a przewijanie w panelu dolnym może przesuwać widok przewijania.

„Mój szkicownik wygląda jak meme Charlie Day, gdzie masz po prostu pęk sznurków i jest całkowicie niezrozumiały” – śmieje się Nelson. W Figmie takie rozwiązanie wymagałoby 40 ramek i 20 minut wyjaśniania zespołowi.

Dlatego bardzo wcześnie sięgnął po kod i zbudował prototyp, gdzie wszystkie te interakcje działały zgodnie z jego intencją. Można było to po prostu przetestować, co okazało się znacznie szybsze niż analizowanie makiet w Figmie.

Zaczynaj od chaosu – metodologia rozwiązywania problemów

Gdy Nelson staje przed niejednoznacznym problemem projektowym, jego pierwszym krokiem jest faza, którą można nazwać „kontrolowanym chaosem”. Zanim powstanie jakikolwiek prototyp, proces zaczyna się od głębokiego zrozumienia problemu.

Najpierw zapisuje wszystko, co przychodzi mu do głowy na temat problemu, kontekstu i użytkowników. Następnie szkicuje dziesiątki różnych rozwiązań – od najbardziej oczywistych po zupełnie abstrakcyjne.

„Mój cel to przemyśleć jak najwięcej różnych szalonych rozwiązań problemu. Można naszkicować sto rozwiązań o różnym stopniu oparcia w rzeczywistości, może 98 z nich to totalne abstrakcje” – opisuje Nelson swój proces.

Z tego chaosu wybiera jeden lub dwa obiecujące kierunki i iteracyjnie je ulepsza. Gdy później trafia na przeszkodę, wraca do oryginalnych pomysłów i łączy elementy z różnych koncepcji – może wziąć fragment z pomysłu numer 62 i połączyć z pomysłem numer 20.

Wybór narzędzi zależy od celu

Nelson porusza się między trzema narzędziami bardzo płynnie i zamiennie. Nie ma ustalonej sekwencji – każde narzędzie ma swoją wartość w odpowiednim momencie procesu projektowego.

Kiedy sięgać po które narzędzie:

Szkicowanie: szybkie pomysły, rozwiązywanie problemów, osobiste notatki
Figma: wizualne aspekty, proste prototypy, współdzielenie z zespołem
Kod: walidacja decyzji, wysokowierny prototyping, testowanie złożonych interakcji

Nelson może prototypować coś, zdecydować, że wymaga zmiany, a najszybszym sposobem ustalenia tej zmiany jest naszkicowanie kilku rozwiązań. Kluczem jest skupienie się na celu końcowym i najszybszej drodze do niego, zamiast zastanawiania się nad wyborem narzędzia.

Gdy kod staje się najszybszą opcją

Nelson coraz częściej sięga po kod do prototypowania, szczególnie gdy chce osiągnąć poziom wierności nieodróżnialny od produkcji. W Figmie trudno osiągnąć taką jakość – Smart Animate to potężna funkcja, ale nie będzie dokładnie taka sama jak kod czy narzędzie w rodzaju Origami.

„Im wyższa wierność prototypu, tym wykładniczo bardziej użyteczny się staje” – zauważa Nelson. Dotyczy to nawet wczesnych etapów, gdy projektant próbuje prototypować interakcję i szybko walidować decyzję.

Zwykły JavaScript i HTML może być bardzo szybki w użyciu. Można używać Times New Roman, bo nie ma się CSS-a, ale nadal szybko przejść od zera do działającego prototypu.

Wewnętrzna aplikacja prototypów

Nelson stworzył w Linear wewnętrzną aplikację TestFlight, która zawiera wszystkie jego prototypy. „To prawdopodobnie najłatwiejszy sposób jaki znalazłem do dzielenia się prototypami Xcode z zespołem”.

Pierwsza strona aplikacji to po prostu indeks – lista wszystkich prototypów. Czasami można znaleźć wersję pierwszą, drugą, zobaczyć ewolucję i przetestować różne wersje. To znacznie ułatwia współdzielenie i zbieranie opinii zwrotnych od zespołu.

Kiedy kod prototypu trafia do produkcji

Czasami fragmenty prototypów Nelsona rzeczywiście trafiają do produkcji. Przykładem jest ekran wprowadzenia w aplikacji Linear, gdzie ikona aplikacji wydaje się unosić nad ekranem telefonu z efektem paralaksy.

Ten prototyp Nelson stworzył jeszcze przed dołączeniem do Linear, eksperymentując z takimi efektami w SwiftUI. Gdy dołączył do zespołu, chcieli wypolerować ten ekran i pomyślał, że to naprawdę unikatowy pomysł.

Inżynierowie skopiowali spore fragmenty jego kodu SwiftUI do prawdziwej aplikacji, ponieważ celem było dopracowanie tych wartości do perfekcji. Ale zazwyczaj jego kod to „totalny bałagan” – inżynierowie mogą na niego spojrzeć dla zrozumienia przypadków brzegowych, ale prawie nigdy nie nadaje się do bezpośredniego wdrożenia.

Nauka programowania: podstawy wystarczą

Nelson uważa, że projektanci potrzebują tylko podstawowej wiedzy programistycznej do tworzenia prototypów. Kluczowe elementy to: tablice do przechowywania danych, instrukcje warunkowe i pętle.

„To może być zbiór rzeczy potrzebnych do tego, żeby coś było Turing complete, co oznacza, że teoretycznie możesz osiągnąć wszystko z tym językiem programowania” – wyjaśnia Nelson.

Posiadanie podstawowego zrozumienia tych konceptów daje fundament, na którym można napisać naprawdę okropny kod. Doświadczony inżynier nigdy nie wdrożyłby go do produkcji, ale pozwoli projektantowi ruszyć z miejsca i kontynuować naukę.

Od frustracji z Origami do SwiftUI

Nelson miał podstawy programowania z college’u (Java, C) i spore doświadczenie z Origami. To potężne narzędzie, ale Nelson często walczył z nim podczas pracy.

„Sposób, w jaki Origami chciało, żebym to robił, i sposób, który był sensowny w mojej głowie, nie do końca się zgadzały” – tłumaczy. Dochodził do momentów, gdzie spędzał frustrująco dużo czasu łącząc węzły w Origami, myśląc „Wiem, jak używać tablicy w kodzie lepiej niż pętli w Origami”.

SwiftUI okazało się podobne do React, którego już znał. HStack, VStack i ZStack bardzo przypominają automatyczne rozmieszczenie z Figmy – jeśli projektant zna to narzędzie, łatwo może zacząć tworzyć wizualne elementy na ekranie.

Nelson poleca praktyczne ćwiczenie: weź prostą, statyczną makietę z Figmy i spróbuj ją zbudować w SwiftUI. To świetny sposób na zrozumienie podstawowych komponentów i logiki automatycznego układu. Nawet jeśli użyjesz Times New Roman jako czcionki, bo nie masz CSS-a, nadal szybko przejdziesz od zera do działającego rezultatu.

Moment przełomu z siatką hexagonalną

Nelson opisuje prototyp, który go szczególnie podekscytował – odtworzenie siatki aplikacji z WatchOS na iPhone’ie. Zamiast standardowej siatki 4×4, chciał stworzyć hexagonalną strukturę „plastra miodu”.

Najbardziej fascynujące było to, że można było szczypać, żeby zobaczyć od jednej do stu ikon aplikacji podczas zoomowania.

„Z pomocą ChatGPT zbudowałem początkową ikonę aplikacji, a potem powiedziałem: okej, weź pętlę for i powiedz 'dla zera do stu ikon aplikacji, chcę, żebyś umieścił każdą, i za każdym razem gdy umieszczasz jedną, przesuń ją o tyle i tyle, jeśli jest w tej pozycji'” – opisuje Nelson.

„Nagle trafiasz na właściwe zaklęcie swojej pętli for i cała siatka po prostu się pojawia i działa. To są te momenty, kiedy myślę: 'Mam to! Zrobiłem to!'”

Strategia nauki z ChatGPT

Nelson ma konkretne podejście do korzystania z AI w nauce programowania. Zamiast wklejać cały kod i prosić o rozwiązanie, stara się izolować problemy i prosić o naukę procesu.

„Próbuję robić jak najwięcej sam. Gdy utknę na czymś, staram się naprawdę wyizolować problem i powiedzieć: naucz mnie, jak to rozwiązać. Nie rób tego za mnie” – opisuje swoją metodę.

Często pyta: „Chcę, żeby to się stało. Jak bym to zrobił?” ChatGPT wyjaśnia wtedy ogólnie, bez podawania całego kodu. Gdy pojawia się fragment składni, którego nie rozumie, pyta o wyjaśnienie konkretnych symboli i ich znaczenia.

Przykładem jest „trailing closure syntax” w SwiftUI, której Nelson wciąż do końca nie rozumie. Można pisać SwiftUI bez jej używania, ale z jakiegoś powodu wielu programistów uwielbia jej używać.

Gdy AI używa takiej składni, Nelson pyta: „Wyjaśnij słowo po słowo w tych trzech liniach, co robi każde słowo i dlaczego go użyłeś”. To pozwala mu stopniowo budować lepsze zrozumienie zamiast ślepego kopiowania.

Kod projektanta vs kod produkcyjny

Nelson nie ma złudzeń co do jakości swojego kodu. „Mogę umieścić milion zmiennych stanu w pliku i powiedzieć: gdy zmieniasz to, tamto się przełącza, a gdy zmieniasz tamto, to się zmienia” – opisuje swoją metodę.

Może tak połączyć prototyp znacznie szybciej, niż gdyby musiał pisać czytelny kod dla kogoś bez większego doświadczenia programistycznego. Jego kod to narzędzie służące konkretnemu celowi – artefaktowi, którym jest prototyp używany do komunikacji z zespołem.

Opowiadanie jako druga połowa pracy

Jedna z najważniejszych lekcji, jaką Nelson wyniósł z pracy w GitHub ze współpracownikiem Brianem Lovinem, to umiejętność prezentacji. Lovin był w tym „naprawdę fantastyczny” i Nelson wiele się od niego nauczył.

„Praca projektanta może być rozwiązywaniem problemów i budowaniem doświadczeń użytkownika, ale druga część to przekonanie zespołu, że to właściwa rzecz do zbudowania w ten sposób w tym czasie” – podkreśla Nelson.

Można wykonać świetną pracę projektową, ale nic z niej nie zostanie wdrożone, jeśli projektant nie ma tej drugiej umiejętności. Dlatego nauka jasnego definiowania problemu, wyjaśniania jak rozwiązanie go adresuje oraz opisywania użytkowników i kontekstu użytkowania jest tak cenna dla każdego projektanta.

Najlepsi nauczyciele to ci, którzy sami się borykali

Nelson ma ciekawą obserwację na temat uczenia się programowania. „Najlepszymi nauczycielami są często ludzie, którzy początkowo sami się z tym borykali, bo mogą postawić się w sytuacji kogoś, kto ma trudności z nauką”.

Gdy ktoś próbuje nauczyć czegoś, co przyszło mu bardzo naturalnie, może mieć podejście „dlaczego tego nie rozumiesz? Nie znam innych sposobów, żeby ci to wyjaśnić”.

Dlatego czasami lepiej jest uczyć się od kogoś, kto jest „o jeden czy dwa szczeble wyżej na tej drabinie” – głęboko empatyzuje ze zmaganiami i pamięta, jak pewne rzeczy mogą być trudne do zrozumienia.

Prototypy wysokiej jakości jako narzędzie komunikacji

To właśnie doprowadziło Nelsona do rozwijania prototypów wysokiej wierności. Zdał sobie sprawę, jak cenna jest kombinacja opowieści o kontekście pracy z prototypem, który można dotknąć i przetestować.

Projektant może przedstawić kontekst, wyjaśnić problem i pokazać prototyp mówiąc: „Oto proponowane rozwiązanie. To jest to, co będziecie mieli, jeśli zdecydujecie się to zbudować za miesiąc czy dwa”.

Taka prezentacja znacznie przewyższa możliwości statycznych makiet czy prezentacji wymagających obszernego opowiadania słowami.

Praktyczne checklisty

✅ Podstawy programowania dla projektantów

Aby zacząć prototypować w kodzie, Nelson zaleca opanowanie:

Tablice (Arrays) – przechowywanie i organizacja danych
Instrukcje warunkowe – logika „jeśli X, to Y”
Pętle (Loops) – powtarzanie kodu określoną liczbę razy
Zmienne – przechowywanie wartości

✅ Strategia nauki z ChatGPT

Rób jak najwięcej sam, zanim poprosisz o pomoc
Izoluj konkretny problem zamiast wklejać cały kod
Pytaj „Naucz mnie jak to zrobić” zamiast „Zrób to za mnie”
Wyjaśniaj niezrozumiałe fragmenty składni
Unikaj kopiowania gotowych rozwiązań bez zrozumienia

✅ Projektowanie z myślą o kontekście mobilnym

Użytkownicy korzystają w 1-2 minutowych sesjach
Często używają telefonu jedną ręką podczas innych czynności
Każde tarcie jest mocno odczuwalne
Gesty muszą być subtelnie sugerowane
Fizyczność interakcji powinna naśladować rzeczywistość

✅ Filozofia promptowania AI według Nelsona

Nelson używa trzech konkretnych typów promptów, które pomagają mu realnie zrozumieć kod:

Pytanie o metodę: „Chcę osiągnąć [opis pożądanego efektu]. Jak mogę to zrobić w SwiftUI?”
Pytanie o składnię: „W moim kodzie pojawił się symbol [$]. Czy możesz wyjaśnić, co on oznacza i dlaczego się go tutaj używa?”
Prośba o analizę: „Czy możesz wyjaśnić mi, słowo po słowo, co robi każda część w tych 3 linijkach kodu i dlaczego została użyta?”

Kluczowe zasady:

„Naucz mnie jak” zamiast „zrób za mnie” – pytaj o proces, nie o gotowe rozwiązanie
Izoluj problem – zamiast wklejać cały kod, wyodrębnij konkretną trudność
Buduj zrozumienie stopniowo – gdy nie rozumiesz fragmentu, nie idź dalej
Unikaj kopiowania bez zrozumienia – lepiej wolniej, ale ze świadomością

Kluczowy insight

Kod projektanta jest po to, by go wyrzucić

Standardowo myślimy: Jeśli projektant uczy się kodu, powinien dążyć do pisania go „dobrze” – czysto, wydajnie i zgodnie z inżynierskimi standardami.

W praktyce okazuje się, że: Celem projektanta-kodera nie jest tworzenie kodu, który trafi do produkcji, ale tworzenie kodu, który pozwoli podjąć lepszą decyzję, a następnie zostanie bez żalu usunięty. Jak przyznaje Nelson: „Jego kod to często splątany kod, którego główną zaletą jest szybkość powstania, a nie elegancja”.

Dlaczego to jest istotne: Ta presja na „dobry kod” często paraliżuje projektantów i zniechęca do eksperymentów. Kod staje się jednorazowym narzędziem do myślenia, a nie permanentnym artefaktem podlegającym ocenie inżynierskiej.

Test na jutro: Następnym razem gdy wahasz się czy spróbować czegoś w kodzie bo „nie umiesz programować”, zamiast dążyć do perfekcji spróbuj napisać najbardziej chaotyczny kod, który pozwoli ci przetestować pomysł i sprawdź jak zmienia to twoją pewność decyzji projektowych.

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 podcaście Dive Club – odcinek 62 z Gavinem Nelsonem o prototypowaniu, interaction design i nauce SwiftUI.

Tag: Swiftui

Od ikon do aplikacji mobilnych – jak prototypowanie w kodzie zmienia pracę projektanta #EN222