Przegadany (?) proces projektowy

Są takie tematy, które nas, osoby projektujące bardzo grzeją. I nie widzę nic złego w tym, że coś nas wyjątkowo ekscytuje i lubimy o tym mówić. Jednak problem zaczyna się, kiedy proste tematy, zaczynają być po prostu przegadane.

I jednym z nich jest proces projektowy. Pogadajmy dzisiaj o tym, bo mam poczucie, że zwłaszcza osoby początkujące, lubią sobie ten temat mocno komplikować. Niezmiennie uważam, że proces projektowy to temat, o którym trzeba i warto opowiadać. Sęk w tym, że nie w każdej formie i nie każdemu. No ale zacznijmy od początku.

PS ten wpis ma też wersję audio, którą znajdziesz na YouTubeSpotify.

Proces projektowy czyli co?

To po prostu szereg następujących po sobie działań, które prowadzą do wytworzenia dzieła – to może być plakat, kod oprogramowania, identyfikacja wizualna, fizyczny przedmiot, strona internetowa czy rozbudowany serwis online. Procesy projektowe spotkacie w architekturze i produkcji wszelkiej maści – produktów cyfrowych i samochodów. A to powoli powinno rysować wam obraz tego, że proces projektowy nie jest zarezerwowany wyłącznie dla projektantów. Projektuje bowiem wiele osób – a to oznacza rownież, że spotkacie się z wieloma punktami widzenia.

Uprośćmy sobie jednak temat i zawęźmy nasz proces projektowy do specjalistów takich jak osoby projektujące grafiki, identyfikację czy UX. Procesem projektowym nazwiemy te działania, które zaczynają się od momentu, kiedy przychodzi klient i mówi – chcę to. A kończy się na tym, kiedy oddajecie swoją pracę. Czasami pracujemy w ciągłych procesach – np. gdy jesteśmy zatrudnieni w firmie i pracujemy nad np. jednym produktem. Tak zdarza się w przypadku Product Designerów, UX i UI Designerów, których zadaniem jest usprawnianie i ciągła opieka nad produktem, np. sklepem internetowym albo appką finansową.

Nie ma jednego procesu projektowego

A to wszystko oznacza, że nie ma jednego, właściwego procesu projektowego. I stąd prawdopodobnie takie zamieszanie wokół tematu. Na kursach i w podręcznikach, na blogach i kanałach na YouTube, będziecie spotykać się z tym pojęciem i może zdarzyć się, że każdy z nich będzie trochę inny. Problem pojawia się kiedy autorzy tych materiałów, próbują przekonać was z całych sił, że to właśnie prezentowana przez nich wersja, jest tą właściwą i jedyną sensowną.

I o ile w grafice jakoś specjalnie nie spotkałam się z takim ciśnieniem na procesy, tak w przypadku UXa mamy jakąś obsesję na tym punkcie. Zwłaszcza wymyślania tych nowych. Powstają canvy (czyli takie szablony procesów), książki i szkolenia. I nie ma co ukrywać – za wieloma takimi działaniami stoi po prostu kasa. Bo to kolejna rzecz, na której można zarobić.

Tymczasem, każdy ma jakiś proces pracy. Może być bardziej lub mnie replikowany na różne projekty. Może być super krótki i prosty, ale to wciąż jakiś proces. Nie trzeba go specjalnie nazywać i dorabiać do niego większej filozofii.

Są osoby, które zaraz po mailu od klienta siadają do Photoshopa lub Figmy i zaczynają projektować. Czasem zrobią sobie dodatkowy research lub poszukiwanie inspiracji, czasem nie. A potem gotowe warianty wysyłają do klienta i wdrażają poprawki. Są kilkuosobowe zespoły, które nie zaczną projektowania bez kilkugodzinnych warsztatów i spotkań. Są osoby, które zawsze zaczynają od badań i zrozumienia biznesu. Są takie, które testują swoje projekty z użytkownikami i szukają feedbacku. I są takie, które tego nie robią. Wszystkie te osoby korzystają z jakiegoś procesu pracy i każda z tych osób, może opowiedzieć o swoim procesie projektowym.

I tu powoli zmierzam do tego, że…

Proces projektowy nie musi być skomplikowany

Po wpisaniu w wyszukiwarkę „proces projektowy” i zerknięciu na obrazki, zobaczymy całą masę diagramów – mniej lub bardziej rozbudowanych. I tu jakiś kolejny fetysz w UXie, czyli diagramy, które robi się tak żeby nikt ich nie zrozumiał. Ale kiedy zgłębimy się w nie bardziej i zaczniemy faktycznie analizować co kryje się pod tymi kafelkami, strzałkami i innymi ślimaczkami, to dojdziemy do wniosku, że w gruncie rzeczy, one wszystkie są do siebie bardzo podobne. Zwłaszcza gdy patrzymy na procesy UXowe, których założeniem jest skupienie uwagi na rzeczywistych problemach i motywacjach ludzi, którzy korzystają z naszych rozwiązań. Mamy więc takie pojęcia jak User Centered Design, Design Thinking czy Double Diamond.

I tu znowu mamy dużo pojęć jak etap empatyzacji, definiowania problemu, ideacji, prototypowania, testowania i tak dalej. I z jakiegoś powodu, wiele początkujących osób rozumie to jako – ok, to w moim projekcie muszę przejść przez wszystkie te etapy i do każdego mieć przynajmniej jedną metodę. Tylko tak wcale nie jest. Co więcej – wiele firm, również tych z UX designerami na pokładzie, wielu z tych rzeczy w projektach nigdy nie robiła.

Bo nie trzeba zawsze robić wszystkiego

I tu przechodzimy do błędu w portfolio początkujących osób. Czyli wciskanie wszystkich metod pracy żeby rozwiązać jakiś trywialny problem albo stworzyć prosty produkt. I nie wiem czy wynika to bardziej z tego jak przekazywana jest wiedza na kursach i szkoleniach, czy to po prostu brak wyczucia osób, które zaczynają, ale widziałam dziesiątki opisów case study, w których mamy przegląd metod badawczych i projektowych, że gdyby robić to dobrze, większym zespołem, to całość zajęłaby dobre miesiące pracy. I przede wszystkim, wymagają pewnego doświadczenia. A tymczasem oglądamy projekt robiony w dwa tygodnie przez osobę bez dużego doświadczenia komercyjnego.

Chodzi mi o takie opisy projektów, gdzie pojawiają się persony, analizy konkurencji, desk research, wywiady indywidualne, ankiety, mapy podróży użytkowników, prototypy lo-fi a potem hi-fi a na koniec tworzenie design systemu i finalny UI.

Proces projektowy stał się jakąś templatką w Miro czy FigJamie do uzupełnienia, w efekcie dostajemy bardzo powierzchowne obserwacje i wnioski, które często w ogóle z siebie nie wynikają. Nie widać też często powiązania wniosków z zaproponowanymi rozwiązaniami w UI. I mam przeczucie graniczące z przekonaniem, że efektem jest stosowanie metod, których nie rozumiemy. Nie rozumiemy po co właściwie robić mapę podróży użytkownika. Nie wiemy skąd brać do niej informacje. Nie wiemy co dalej z tymi informacjami możemy robić. Dodajemy kolejne metody, które nic realnie nie wnoszą do projektu, wydłużając tylko proces i niepotrzebnie go komplikując.

Źle dobrane metody

Szczególnie niemądre wydaje się stosowanie metod, których założeniem jest zbieranie wiedzy innych osób. Nagminnie natykam się na opis „sortowania kart”, w których jedynym uczestnikiem badania jest osoba tworząca projekt. Albo ankiety, które rozsyłane są w grupach związanych z nauką UX zamiast w potencjalnej grupie docelowej. Nawet jeśli projekt jest tylko do szuflady, trudno będzie nauczyć się analizy wyników i pracy z nimi, kiedy nie zbieramy rzetelnych danych. Wiele osób, które trafiało do mnie na konsultacje, było przekonanych, że praca w definiowaniu person polega na wypełnieniu szablonu informacjami, które „nam się wydają, że są prawdziwe”. Pomijając już fakt, że tworzenie całego zestawu person do jednego projektu UI może nie mieć szczególnej wartości.

To samo dotyczy prototypowania, gdy nie planujemy żadnych testów. Robienie rozbudowanych, interaktywnych prototypów przy stronach, które nie mają niczego poza prostymi przejściami między podstronami jest trochę… stratą czasu. Dużo sensowniej skupić się na widokach i typach interakcji wyjątkowych i niestandardowych, a resztę dostarczyć w formie dobrze przygotowanego pliku np. Figmy.

Jeśli w projekcie, osoba projektująca ograniczała się tylko do szybkiej analizy konkurencji i od razu przeszła do projektu UI, to… ten proces powinniśmy opisywać. Nie dodawać wymyślonych metod, których nie wykorzystaliśmy ani których nie rozumiemy. Uwierzcie – osoba, która przegląda wasze portfolio lub zaprosi was na rozmowę, bardzo szybko wyczuje, że nie rozumiecie tego tematu.

No ale to przecież do portfolio

I tu się może zaraz ktoś przyczepić, że no dobra, ale to są często projekty do portfolio, projekty na których ktoś się uczy i jednocześnie chce pokazać, że pracował z tymi metodami.

Tylko to nie wyklucza myślenia.

Dorzucanie wielu losowych metod (które nic nie wnoszą) nie pokazuje potencjalnym pracodawcom, że umiecie je stosować. I że np. wyciągacie z nich jakieś wartościowe wnioski. Użycie szablonu w Miro i uzupełnienie go tekstem, jest zadaniem, z którym poradzi sobie pewnie każdy nastolatek. Zamiast dorzucać do procesu źle wykorzystywane metody warsztatowe (bo te najczęściej obserwuję), które wymagają udziału np. obecnych użytkowników albo kluczowych dla projektu członków zespołu, wybierzmy metody, które są w naszym zasięgu:

  • Zrobienie ankiety i przeprowadzenie analizy i wypunktowanie niepewnych obszarów, które badalibyście dalej w prawdziwym projekcie, daje dużo większe poczucie, że wiecie co robicie.
  • Jeśli produkt ma łatwo dla was dostępną grupę odbiorców, warto skusić się na zrobieniu wywiadów indywidualnych, przygotować sobie scenariusz pytań, spisać pytania badawcze – dużo się dzięki temu nauczycie.
  • Jeśli macie opory bądź brak możliwości, to zerknijcie na netnografię i analizę tego co piszą i o co pytają ludzie w sieci – np. na tematycznych grupach, forach internetowych, w komentarzach pod TikTokami marki.
  • Sprawdźcie czy rzeczy, które chcecie przebadać, nie zostały już przebadane wzdłuż i wszerz i nie są dostępne na ten temat raporty w sieci (przypadek sklepów internetowych).

Skoro macie już te prototypy, to przygotujcie prosty scenariusz testów i pod nie przygotujcie prototyp. Przetestujcie go nawet ze znajomymi czy rodziną żeby nauczyć się dobrego przygotowania samego pliku.

– A co jeśli wszystkie te propozycje wydają się zbyt skomplikowane i wymagają za dużo pracy?

To może być sygnał, że to jeszcze nie etap na budowanie portfolio, a skupienie się na nauce.

Opisanie procesu projektowego w portfolio to… ostatni krok

Portfolio to miejsce, w którym opisujemy i przedstawiamy nasz dorobek. Portfolio tworzy się gdy chcemy dostać się na studia artystyczne – wtedy przedstawiamy tam miesiące, często lata naszej pracy. Wybierając NAJLEPSZE projekty z etapu uczenia się. Lub przygotowujemy je specjalnie z myślą o zaprezentowaniu naszych umiejętności.

Gdybym do mojego portfolio na studia wrzuciła moje pierwsze rysunki i prace malarskie to… pewnie nie dostałabym się na studia. Bo pierwsze projekty są często strasznie słabe.

Dlatego polecam zmienić podejście. Zanim rzucimy się w wir budowania portfolio po przesłuchaniu jednego webinaru, bo liczymy na szybkie przebranżowienie i masę ofert, poświęćcie trochę czasu na naukę. Zróbcie parę projektów, pobawcie się metodami, potestujcie różne procesy, a kiedy poczujecie się pewniej, zaplanujcie sobie projekt do portfolio. I spróbujcie go zrobić wybranym procesem. Ale skupcie się na zaprojektowaniu czegoś – a nie odklepywaniu kolejnych metod i myśleniu jak pokazać je w case study. Bo dopiero jak skończycie projekt, przyjdzie na to czas.

Jak mówić o procesie projektowym?

Na koniec jeszcze o tym, jak o tym procesie projektowym opowiadać? Bo opowiadać trzeba będzie, na różnym etapie waszego zawodowego rozwoju i z różnymi osobami. I te osoby, to taki kluczowy punkt przy którym chwilę bym się zatrzymała.

Starajmy się tak opowiadać o procesie i efektach naszej pracy, by dopasować się do tego, o czym chcą słuchać nasi odbiorcy.

Inaczej będziemy opowiadać o procesie na rozmowie kwalifikacyjnej, inaczej w portfolio, inaczej na spotkaniu z klientem, który ma duże doświadczenie z projektowaniem, a inaczej z klientem, który nie ma o tym pojęcia. Inaczej będziemy opowiadać o naszej pracy i procesie na konferencji dla projektantów a inaczej na konferencji biznesowej. To coś, czego uczymy się z czasem i nabiera się w tym wprawy, ale przygotowując np. prezentację, dobrze mieć z tyłu głowy do kogo będziemy mówić i co chcemy żeby te osoby z tego gadania wyciągnęły.

Dobór komunikatu do grupy docelowej

Prostym przykładem jest rozmowa kwalifikacyjna – najczęściej pierwszy etapem jest tak zwany screening, czyli taki pierwszy telefon albo spotkanie z HR. Na spotkaniu z HR padają też pytania o waszą pracę, proces projektowy, ulubione projekty lub z czego jesteście najbardziej dumni. Zakładam, że osoby z HR nie muszą dobrze znać całego przeglądu metod i podejść pracy, więc sypanie trudnymi słowami jak z rękawa, może nie przynieść dobrego efektu. Na pierwszych rozmowach zawsze używałam uproszczeń. Starałam się opisywać w dużo prostszy sposób moje podejście do pracy i doświadczenie. Nie wchodziłam w szczegóły, za to tłumaczyłam od razu pokrótce pojęcia, które być może nie były dobrze znane przez drugą osobę.

Za to kiedy dostawałam zaproszenie na rozmowę np. z Design Managerem albo innymi projektantami UX, mogłam pozwolić sobie na wchodzenie w szczegóły, dokładne opisywanie mojego podejścia. Za to bez tłumaczenia czym są np. testy sortowania kart czy user journey maps. Tu też uwaga do opisywania procesu i metod w portfolio. Jeśli zakładacie, że po drugiej stronie portfolio ogląda doświadczona w projektowaniu osoba, nie ma potrzeby tłumaczyć czym jest User Centered Design albo co to jest persona. Bo tę osobę bardziej będzie interesować, co wy z tego tworzenia person wyciągnęliście.

Jak się uczyć o procesach i metodach?

Najlepiej w praktyce, testując różne metody w projektach choćby do szuflady. Nie oznacza to, jak wspominałam wcześniej, że wszystkie te projekty i opisy metod muszą trafić później do waszego portfolio. Na początku drogi najlepiej skupić się na tych zadaniach, które przydadzą się możliwie najwcześniej w pracy zawodowej i są popularne. Bo popularne może oznaczać, że realne w zastosowaniu. Moim zdaniem (bo pewnie co projektant i firma, to inne podejście), będą to*:

  • Dowolna forma zbierania wymagań, czyli gadania z klientami lub innymi zlecającymi zadania, o tym co właściwie chcemy zrobić, czemu, jakie informacje już mamy a czego nam brakuje. To może być brief, spotkanie lub warsztat – cokolwiek to będzie, przyda się zawsze, bo nauczy zadawać odpowiednie pytania.
  • Sposób na generowanie pomysłów. Czyli kiedy siedzimy – samodzielnie lub w grupie i jakoś robota nie idzie. To może być mapowanie myśli (en. mind mapping), burza mózgów (pl. brainstorming) – idealna jeśli jest więcej osób, czy po prostu szkicowanie. A im dalej w las, tym więcej metod będziecie poznawać.
  • Porządkowanie informacji o konkurencji i benchmarkach. Co można porównywać? Od cen, grup docelowych po wygląd, sposób komunikacji, listę funkcji czy innych udogodnień. Projektując nową identyfikację firmy czy zestaw grafik na portale społecznościowe, dobrze wiedzieć jak wygląda konkurencja, jak wypadniemy z nowymi projektami na jej tle.

    Taki przegląd konkurencji i inspirujących firm ułatwia nam znalezienie potencjalnych przewag (lub luk) w biznesie, dla którego pracujemy. I możemy robić to w dowolny i wygodny dla nas sposób – od tworzenia tabelek w Excelu po tworzenie interaktywnych tablic w Miro czy FigJamie.
  • Dla osób zajmujących się projektowaniem stron i aplikacji – jakaś forma walidacji pomysłów, np. testy użyteczności. Tworzenie prostych, krótkich (np. 15-20 minut) scenariuszy testów, formułowanie zadań testowych, określenie grupy, która powinna testować produkt, tworzenie prototypu do testu (np. w Figmie), a następnie analiza wyników tych testów i rekomendacje zmian.

*nie wymieniłam tu stricte „projektowania”, bo zakładam, że to oczywiste, że osoba projektująca projektuje – niezależnie czy zajmuje się identyfikacją wizualną, robieniem grafik na Instagrama czy ilustracjami, ta część jest równocześnie do powyższy metod rozwijana.

Są i książki

Na blogu i kanale polecałam już wielokrotnie dwie książki, które mogą wzbogacić wasz wachlarz metod i nauczyć po co się je właściwie stosuje. Pierwsza to ta, która mówi o metodach badawczych – „Badania jako podstawa projektowania User Experience” Iga Mościchowska, Barbara Rogoś-Turek. A druga, która bardziej pokrywa metody warsztatowe – „Gamestorming: gry biznesowe dla innowatorów” Dave Gray, James Macanufo, Sunni Brown

Podsumowując

Jeśli mielibyście zapamiętać z tego materiału tylko jedną rzecz to – serio, nie trzeba robić wszystkiego. To zakochiwanie się w procesach i metodach kończy się niestety przegadanymi projektami i masą straconego czasu. Metody i procesy projektowe powinny pomagać nam, tak, w projektowaniu – w osiągnięciu określonego celu. Częściej mam jednak wrażenie, że stają się sztuką dla sztuki.

You May Also Like
ux writing i tworzenie treści
Read More

WWW: Treści na stronie

Dawno nie wrzucałam nic z serii procesu projektowania strony internetowej! Sporo się przez grudzień i styczeń działo (jak na przykład to, że założyłam swój…
Projektowanie usług z Kasią Słowik
Read More

Service design – zapis rozmowy

 9 lutego (we wtorek) gościła u mnie na kanale Kasia Słowik i porozmawiałyśmy chwilę o projektowaniu usług (Service Design). Poniżej zapis spotkania (nagrania…