Product
Czy funkcja wzmacnia główną pętlę i priorytety produktu?
ZESPÓŁ
Zespół definiujemy przez odpowiedzialność.
Opisujemy zespół przez odpowiedzialności. Każda dyscyplina ma własne pytania, ale wszystkie pracują nad jednym rezultatem: czytelnym, spokojnym i spójnym produktem.
studioprocessystemyjakośćprodukt
Pięć perspektyw na tę samą funkcję.
To, co dla gracza jest jednym przyciskiem albo gestem, w zespole staje się zestawem pytań.
Design
Czy reguły są spójne i tworzą sensowne decyzje?
Visual / UX
Czy stan i rezultat są czytelne w pierwszym spojrzeniu?
Implementation
Czy zależności są odporne na nietypową kolejność i przerwanie?
QA
Czy system zachowuje się poprawnie także w stanach granicznych?
Jak decyzja przechodzi przez zespół.
Zamiast ukrywać problemy w kolejnych warstwach, staramy się wracać do źródła niejasności.
Cel
Zapisujemy oczekiwany efekt w produkcie.
Ryzyko
Wskazujemy, gdzie nowy system może kolidować z istniejącymi.
Propozycja
Budujemy najprostszy model, który daje oczekiwany rezultat.
Review
Inne dyscypliny sprawdzają koszt poznawczy i implementacyjny.
Doprecyzowanie
Usuwamy wyjątki i dublujące się stany.
Akceptacja
Funkcja ma jasne kryteria gotowości.
Co wzmacnia współpracę, a co ją psuje.
Nie udajemy konkretnej metodyki czy narzędzi, których nie ujawniono. Pokazujemy zasady komunikacji produktu.
Wzmacniamy
- definiować rezultat przed rozwiązaniem
- pokazywać zależności między systemami
- sprawdzać język i wizualny priorytet
- oddzielać fakt od interpretacji
- zapisywać kryteria jakości
Unikamy
- dokładać wyjątki bez właściciela
- ratować słaby flow dodatkowym tekstem
- traktować QA jako etap po projekcie
- kopiować mechanikę bez roli w produkcie
- maskować brak danych fikcyjną historią
Co powinno przejść razem z decyzją.
Sama makieta albo ticket nie przenoszą intencji. Handoff traktujemy jak pakiet kontekstu, który pozwala kolejnej dyscyplinie podjąć świadomą decyzję.
Cel i kryterium
Co użytkownik ma zrozumieć lub osiągnąć oraz po czym poznamy, że rozwiązanie działa.
Stany i wyjątki
Co dzieje się przy braku zasobu, blokadzie, przerwaniu, powrocie i zmianie kontekstu.
Priorytet informacji
Co musi być widoczne od razu, co może być wtórne, a co nie powinno trafiać do UI.
Zależności
Które inne systemy czytają wynik, zmieniają warunek albo mogą zostać naruszone przez poprawkę.
Jak rozstrzygamy konflikt między dyscyplinami.
Nie każda różnica zdań jest problemem do wypośrodkowania. Najpierw wracamy do celu i sprawdzamy, która propozycja lepiej spełnia kryterium produktu.
Pokazujemy
- wracamy do celu funkcji
- porównujemy koszt poznawczy
- sprawdzamy zależności i regresję
- wybieramy mniejszą liczbę wyjątków
Nie dopisujemy
- nie głosujemy nad gustem
- nie maskujemy problemu dodatkowym tekstem
- nie bronimy rozwiązania tylko dlatego, że jest już wdrożone
- nie mylimy szybkości implementacji z jakością decyzji
Role prowadzą do wspólnego flow.
Na stronie procesu rozpisujemy kolejne decyzje: od celu, przez system i interakcję, po review, balans i release-readiness.