Proces tworzenia UI - NIGDY TAK NIE ZACZYNAJ!

Developerzy - tak jak do programowania modułu systemu na backendzie najpierw projektujemy architekturę i rozpisujemy gdzieś działanie systemu, na froncie też powinniśmy najpierw sobie wszystko rozpisać i zastanowić się nad tworzonym UI, nad flow tworzonego rozwiązania.

Często w ferworze nacisków biznesu "na kiedy to dacie radę zrobić?" siadamy, na szybko omawiamy endpointy ...i jebs - siadamy do kodu.

To bardzo zła praktyka.

Głównie przez to, że w tym przypadku myślimy o ficzerze "za płytko". Na 100% nie weźmiemy pod uwagę wszystkich przypadków integracji z innymi miejscami w systemie itd.

Niektóre rzeczy wyjdą w trakcie developmentu. Oby nie trzeba było zmieniać za dużo kodu... 😱

Niektóre rzeczy wyjdą po oddaniu ficzera do testów 🖱 ⌨️

Niektóre rzeczy wyjdą na produkcji 💥

Niektóre wyjdą po miesiącu od oddania ficzera 💣

Co zrobić?

Poniżej rozwiązanie. Traktuj je jako wskazówka a nie wzór, który musi obowiązywać.

Propozycja dla zespołu, który składa się tylko z developerów (ew. project managera) i przedstawiciela biznesu - brak UI/UX designerów, event-stormingów itd.:

10 kroków tworzenia nowego ficzera:

1. Konwersacja z biznesem
2. Zrozumienie problemu
3. Znalezienie możliwie dużo przypadków i powiązań z innymi częściami systemu i uwzględnienie ich
4. Propozycja rozwiązania dla biznesu:
   - dokumentacja tekstowa
   - mocki UI
   - user stories
5. Konwersacja z biznesem, dostosowanie dokumentacji
6. Akceptacja biznesu
7. Dokumentacja techniczna, ustalenie sposobu komunikacji front<->backend itd.
8. Zaprojektowanie prac na froncie i backendzie
9. Podział prac, rozpisanie zadań, organizacja w czasie
10. Kod

Każda większa lub wpływająca na dużą liczbę obecnych elementów w systemie zmiana powinna być wprowadzana dopiero po przejściu powyższych punktów.

Dzięki temu:

• nie tracimy tyle czasu na poprawki
• nie tracimy tyle czasu na uwzględnianie nie wziętych pod uwagę przypadków granicznych
• nie tracimy tyle czasu na olśnienia biznesu (biznes też człowiek i może się mylić) i zmiany po wprowadzeniu ficzera - większość olśnień nastąpi na etapie tworzenia dokumentacji
• cały ficzer powinien być lepiej zrobiony - został zaprojektowany, a nie zakodowany
• mamy dokładniejszą estymację czasu potrzebnego na wykonanie zadania
• mamy rozplanowaną pracę
• biznes wie co będzie robione, kiedy oddane i jak to będzie działało

Powodzenia!

Pozdrawiam i miłego dnia!