Proces tworzenia UI - NIGDY TAK NIE ZACZYNAJ!

Mikołaj Waśkowski -

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!