Model double diamond pomaga uporządkować projektowanie wtedy, gdy zespół zbyt szybko przykleja się do jednego rozwiązania. W UX i UI jest szczególnie przydatny, bo prowadzi od rozpoznania problemu do wdrożenia, zamiast zaczynać od makiet tworzonych „na czuja”. Poniżej pokazuję, jak działa ten proces, gdzie daje największą wartość w projektach stron i e-commerce oraz kiedy lepiej go skrócić.
Model porządkuje pracę od problemu do rozwiązania
- To mapa procesu projektowego, a nie sztywny przepis na pracę zespołu.
- Opiera się na dwóch ruchach: rozszerzaniu pola możliwości i zawężaniu go do najlepszej decyzji.
- Najpierw bada się problem, dopiero potem projektuje rozwiązania.
- W UX i UI model pomaga ograniczyć błędne założenia, chaos decyzyjny i kosztowne poprawki po wdrożeniu.
- Najlepiej działa przy złożonych stronach, sklepach internetowych i produktach, w których stawka jest wysoka.
- W małych zadaniach można go uprościć, zamiast przechodzić przez cały proces w pełnej wersji.
Czym jest model podwójnego diamentu w UX i UI
To prosty sposób opisu pracy projektowej, który porządkuje drogę od niejasnego problemu do konkretnego rozwiązania. Nazwa bierze się z dwóch „diamentów”, czyli dwóch cykli: najpierw dywergencji, kiedy zbieram szeroki kontekst i szukam wielu możliwości, a potem konwergencji, kiedy zawężam pole i wybieram najlepszy kierunek. W praktyce ten rytm powtarza się dwa razy: raz po to, by dobrze zrozumieć problem, i drugi raz, by zbudować i dopracować odpowiedź.
Ja traktuję ten model bardziej jak mapę myślenia niż jak checklistę do odhaczania. W UX chodzi przecież nie tylko o ładny interfejs, ale o doświadczenie użytkownika, a UI jest jego widoczną warstwą. Jeśli zespół zacznie od stylu, a nie od potrzeb i zachowań ludzi, bardzo łatwo pomyli estetykę z użytecznością. Ten model pomaga tego uniknąć, bo wymusza najpierw zrozumienie, potem decyzję, a dopiero później dopracowanie szczegółów wizualnych.
Nie utożsamiałbym go też automatycznie z design thinking. To pojęcia bliskie, ale nie tożsame. Tutaj nacisk pada na porządek pracy i świadome przechodzenie między otwarciem a zawężeniem problemu. To właśnie dlatego model tak dobrze sprawdza się w projektach cyfrowych, gdzie trzeba jednocześnie dbać o potrzeby użytkownika, ograniczenia biznesowe i spójność interfejsu. Żeby było to jeszcze bardziej praktyczne, rozbijmy proces na cztery fazy.
Jak double diamond porządkuje pracę nad produktem
W oficjalnym ujęciu model sprowadza się do czterech etapów: Discover, Define, Develop i Deliver. Sama nazwa może brzmieć akademicko, ale sens jest bardzo konkretny. Najpierw zbieram fakty, potem formułuję właściwy problem, następnie tworzę możliwe rozwiązania, a na końcu testuję i wdrażam to, co ma największy sens dla użytkownika i biznesu.
| Faza | Po co ją robię | Co zwykle powstaje | Na co uważam |
|---|---|---|---|
| Discover | Żeby zrozumieć sytuację, a nie opierać się na założeniach | Wywiady, analiza danych, audyt UX, insighty, lista hipotez | Nie mylę opinii zespołu z realnym zachowaniem użytkowników |
| Define | Żeby zawęzić temat do jednego, dobrze opisanego problemu | Problem statement, priorytety, kryteria sukcesu, mapa szans | Nie zamieniam zbyt szerokiego problemu w sztuczne uproszczenie |
| Develop | Żeby wygenerować i szybko sprawdzić kilka rozwiązań | Szkice, wireframe, prototypy, warianty UI, testy koncepcji | Nie zakochuję się w pierwszym pomyśle |
| Deliver | Żeby dopracować, wdrożyć i zweryfikować efekt | Gotowy interfejs, testy użyteczności, handoff, pomiary po wdrożeniu | Nie traktuję wdrożenia jako końca pracy |
W małym projekcie taki cykl da się często przejść w 2-3 tygodnie, jeśli zakres jest wąski i decyzje zapadają szybko. Przy większym serwisie albo sklepie internetowym to zwykle kilka sprintów, bo dochodzi więcej interesariuszy, więcej zależności i więcej miejsc, w których interfejs może wpływać na konwersję. Najważniejsze jest jednak coś innego: te etapy nie są liniową kolejką do przejścia, tylko pętlą uczenia się. Jeśli w testach wychodzi nowa informacja, wracam krok wcześniej, zamiast bronić wcześniejszych założeń. To prowadzi naturalnie do pytania, gdzie ten rytm daje największy zwrot.
Gdzie ten model daje największy zwrot w stronach i e-commerce
W projektach webowych ten proces najlepiej sprawdza się tam, gdzie problem nie jest oczywisty albo stawka jest wysoka. W praktyce mam na myśli przebudowę architektury informacji, poprawę ścieżki zakupowej, redesign strony głównej, filtrowanie produktów, formularze kontaktowe, onboarding czy strony docelowe budowane pod ruch z wyszukiwarki. W takich miejscach łatwo pomylić objawy z przyczyną. Niska konwersja nie zawsze oznacza zły UI. Czasem problemem jest komunikacja, oferta, brak zaufania albo zbyt skomplikowana struktura treści.
Przy sklepie internetowym model pomaga mi nie rozjechać kilku rzeczy naraz. Zanim przeprojektuję menu, sprawdzam, jak użytkownicy szukają produktów, które kategorie generują ruch i gdzie odpadają w lejku zakupowym. Gdy zmieniam stronę kategorii albo filtrów, patrzę nie tylko na wygląd, ale też na wpływ na odnajdywalność treści i zachowanie osób, które przyszły z wyników organicznych. To ważne, bo w e-commerce UX, UI i SEO często są połączone mocniej, niż wielu zespołom się wydaje.
Najbardziej zyskują projekty, w których występuje przynajmniej jeden z tych sygnałów:
- zespół ma kilka sprzecznych hipotez, dlaczego użytkownicy nie kończą zadania,
- strona ma dużo ruchu, ale słabą konwersję na kluczowych etapach,
- trzeba zmienić coś istotnego bez utraty istniejącej logiki i nawyków użytkowników,
- w grę wchodzi wiele działów, na przykład produkt, sprzedaż, content, SEO i development,
- projekt dotyczy krytycznego momentu, takiego jak rejestracja, koszyk, checkout albo formularz leadowy.
Im większa niepewność, tym bardziej ten model ma sens. A skoro nie zawsze da się zamknąć cały proces w jednym projekcie, warto zobaczyć, jak połączyć go z krótszym rytmem pracy.
Jak połączyć go z agile bez robienia z tego wodospadu
Największy błąd, jaki widzę, to próba zamienienia modelu w ciężką biurokrację. To nie ma działać jak wielomiesięczny ceremoniał. W zespole pracującym zwinnie da się go spokojnie wpleść w sprinty, jeśli każda faza ma jasny cel, czas i rezultat. Ja zwykle wolę krótkie pętle niż jedną wielką analizę, po której wszyscy i tak wracają do starego sposobu pracy.
- Rozpoczynam od krótkiego odkrywania problemu, zwykle 3-5 dni, jeśli projekt jest niewielki, albo dłużej, jeśli skala jest większa.
- Na podstawie danych i rozmów formułuję jedno zdanie problemu, czyli krótki opis tego, co naprawdę trzeba rozwiązać.
- W kolejnym kroku tworzę 2-3 warianty rozwiązania zamiast jednego „dopieszczonego” pomysłu.
- Testuję je na małej grupie, często wystarcza 5-8 osób, żeby zauważyć powtarzalne wzorce zachowań.
- Wdrażam najlepszy kierunek i po publikacji mierzę efekt, zamiast uznawać temat za zamknięty.
To działa szczególnie dobrze wtedy, gdy zespół ma ograniczony czas, ale nadal chce podejmować decyzje na podstawie faktów, a nie intuicji jednej osoby. W praktyce agile i ten model nie konkurują ze sobą. Jeden porządkuje myślenie o problemie, drugi rytm pracy zespołu. Kiedy je połączę, dostaję proces, który jest jednocześnie uporządkowany i wystarczająco lekki. Problem zaczyna się dopiero wtedy, gdy ktoś próbuje stosować go bez zrozumienia ograniczeń.
Najczęstsze błędy i ograniczenia, które psują cały proces
W teorii model wygląda elegancko, ale w praktyce łatwo go zepsuć kilkoma powtarzalnymi błędami. Najczęściej nie chodzi o samą metodę, tylko o to, że zespół skraca jedne fazy do minimum, a inne przeciąga ponad potrzebę. W efekcie proces przestaje być narzędziem decyzyjnym i zamienia się w rytuał.| Błąd | Co się dzieje | Jak reaguję |
|---|---|---|
| Za szybkie przejście do UI | Interfejs jest ładny, ale nie rozwiązuje właściwego problemu | Wracam do danych, rozmów z użytkownikami i analizy zachowań |
| Zbyt szeroko zdefiniowany problem | Zespół projektuje wszystko naraz i nie ma jasnego priorytetu | Ograniczam zakres do jednego celu i jednego segmentu użytkowników |
| Ideacja bez kryteriów | Powstaje dużo pomysłów, ale trudno wybrać sensowny kierunek | Ustalam wcześniej kryteria sukcesu i ograniczenia biznesowe |
| Brak testów po wdrożeniu | Nie wiadomo, czy zmiana naprawdę poprawiła doświadczenie | Mierzę zachowanie użytkowników i porównuję je z hipotezą |
| Stosowanie modelu do prostych zadań | Proces staje się cięższy niż sam problem | Uproszczam go do szybkiego researchu i krótkiego testu |
Tu właśnie widać granice tej metody. Jeśli poprawiam pojedynczy błąd w formularzu albo zmieniam drobną etykietę, pełny cykl bywa przesadą. Jeśli jednak przebudowuję stronę główną, koszyk, nawigację albo kluczowe landing pages, warto się zatrzymać i przejść przez pełniejszy proces. Z mojego doświadczenia największe oszczędności pojawiają się nie wtedy, gdy projektuję szybciej, tylko wtedy, gdy wcześniej unikam złej decyzji. I to prowadzi do ostatniego, praktycznego kroku: co faktycznie warto zabrać z tego modelu do codziennej pracy.
Co zabieram z tego modelu do codziennej pracy nad stronami i sklepami
Jeśli miałbym zostawić z tego procesu tylko kilka zasad, byłyby bardzo proste. Po pierwsze, najpierw rozumiem problem, dopiero potem proponuję rozwiązanie. Po drugie, nie zamykam się w jednej wersji interfejsu, zanim nie sprawdzę alternatyw. Po trzecie, każdą większą zmianę kończę pomiarem, bo bez tego trudno odróżnić prawdziwą poprawę od dobrego wrażenia w zespole.
- Jedno zdanie problemu jest lepsze niż pięć mglistych założeń.
- 2-3 warianty rozwiązania dają więcej niż dopracowywanie jednego pomysłu w próżni.
- Krótki test z 5-8 osobami często pokazuje więcej niż długie dyskusje w zespole.
- W e-commerce trzeba patrzeć równocześnie na UX, UI, treść i wpływ na ruch organiczny.
- Po wdrożeniu najważniejsze staje się to, czy zmiana rzeczywiście poprawiła zachowanie użytkowników.
W praktyce ten model najlepiej działa wtedy, gdy zespół nie myli szybkości z pośpiechem. Najpierw porządkuję problem, potem zawężam pole decyzji, a dopiero na końcu dopracowuję interfejs. Przy stronach internetowych i sklepach internetowych taka kolejność zwykle daje lepszą nawigację, czytelniejszy UI i mniej kosztownych poprawek po wdrożeniu.
