Jak zrobić dobre makiety do dokumentacji?
Klient nie wie czego chce, ale doskonale wie czego nie chce. To czego nie chce mówi Ci w sytuacji gdy zobaczy skończony przez Ciebie projekt. To niestety za późno bo musisz spędzić czas na dostosowaniu i poprawkach. Rzuć okiem na ten wpis aby dowiedzieć się czy projektowanie makiet będzie rozwiązaniem problemu.
Z moich obserwacji wynika, że wielu analityków nie projektuje makiet, bo:
- nie mają czasu 🙃;
- twierdzą, że to zadanie dla grafika / UX designera.
Jakby to powiedział Radosław Kotarski – „nic bardziej mylnego”.
Argumentem z brakiem czasu do dokumentacji już wyjaśniałem. W przypadku brakiem czasu do projektowania makiet jest analogicznie.
Zrozumienie zakresu z klientem dzięki zaprojektowaniu dobrych makiet jest warte każdej roboczo godziny.
Dziś przekażę Ci najważniejsze „dobre praktyki”. Całości projektowania makiet niestety nie jestem w stanie wyjaśnić Ci w jednym wpisem. M.in. dlatego, że tekst nie jest formą na to. Żebyś potrafił zaprojektować dobrą makietę niezbędne byłoby pokazanie tego na przykładach i omówienie z voice overem. Na blogu ciężko to zrobić. Dlatego jeśli chcesz tworzyć dobre makiety to zajrzyj do mojego kursu – Dokumentacja.Pro, w którym nagrałem kilkunasto minutowy materiał dogłębnie poruszając ten temat.
Wiedza o Dokumentacji IT na twój adres e-mail?
Na początek warto sobie wyjaśnić pojęcia, takie jak:
- wireframing – jest to tworzenie pewnego rodzaju „szkieletu” pod nasze kontrolki widoku;
- mockup(owanie) – jest to tworzenie widoków z szatą graficzną.
Gdzieś pomiędzy tymi pojęciami jest termin makiety funkcjonalne, który „sam wymyśliłem”.
Makietowanie funkcjonalne w moim rozumieniu to coś więcej niż sam wireframing – bo projektujemy dodatkowo szczegółowo dane na naszych widokach.
I jednocześnie to coś innego niż mockup – bo nie zawiera szczegółów wizualnych, które na etapie pisania dokumentacji są często nieistotne.
Bo czy ważne jest czy nasza aplikacja będzie ciemna czy jasna? Możemy o tym zdecydować, gdy uzgodnimy zakres z klientem 🙂
Projektując makiety skup się na:
- na tym CO dany użytkownik będzie mógł robić, zamiast JAK to będzie wyglądać. Chodzi o pokazanie możliwości funkcjonalnych, zamiast efektu wizualnego;
- potraktuj projektowanie makiet jak walidację rozumienia zakresu. Nie chodzi w nich tylko o to, aby pokazać coś fajnego klientowi. Chodzi o to abyś miał pewność, że dobrze rozumiesz to co klient oczekuje – znasz prawdziwe oczekiwania.
- myśl o makietach w kontekście satysfakcji klienta – wielokrotnie mówiłem, że „klient nie wie czego chce, ale wie czego nie chce„. Więc na pewno taniej będzie przerobić makietę zgodnie z oczekiwaniami niż przebudowywać aplikację po wdrożeniu.
- unikaj różnego rodzaju „lorem ipsum” – pamiętaj, że w makietach chodzi o to aby zastanowić się nad tym czy dobrze rozumiesz logikę funkcjonalną. Staraj się nie wkładać „fake data” w makiety tylko zastanowić jakie faktycznie dane będą tam wyświetlane.
- makiety funkcjonalne pomogą Ci „odkryć zakres”, o którym nie powiedział klient, a będzie mu potrzebny. Prawdopodobnie po przygotowaniu makiet niektóre „feature” podpowie Ci zdrowy rozsądek.
- Jeśli projektując makietę rozważasz dwie kontrolki i nie wiesz, której użyć. Bo na przykład dają podobne możliwości funkcjonalne, często powołuję się na przykład radio buttonów i checkboxów. Jeśli masz taki dylemat, nie trać czasu na wybór – zastosuj tą, która wydaje Ci się najbardziej odpowiednia na ten moment. Dobranie odpowiedniego UX (user experience) będzie wyzwaniem designera / grafika. Na pewno w późniejszym etapie – gdy „dogracie” zakres z klientem.
Postarałem się pomóc, na tyle na ile mogłem w formie tekstowej.
Nie będę zaskoczony jeśli coś będzie dla Ciebie niejasne, dlatego czekam na pytania od Ciebie – zadaj w formie komentarza 🙂 Postaram się odpowiedzieć najlepiej jak umiem 🙂
Mam do Ciebie pytanie za 100 punktów…
Jak wybrać widoki, które warto zamakietować?
Jeśli tworzysz dokumentację dla klienta komercyjnie, to polecam Ci dołączyć do kursu Dokumentacja.Pro, gdzie dogłębnie omawiam różne podejścia, wskazówki, narzędzia i procesy myślowe do tworzenia dokumentacji.
Jest to o tyle wartościowe, że dziele się wiedza, którą sam stosuję na codzień w praktyce prowadząc projekty i pisząc analizy w mojej firmie.
Kurs Dokumentacja.Pro jest moim manifestem i mówieniem STOP dla tworzenia „dokumentacji – gniotów”, których nikt nie rozumie, a ich napisanie zajmuje dużo czasu.
Twierdzę, że da się dobrać odpowiedni wymiar szczegółowości do tworzenia dokumentu, który będzie wymierny do ilości poświęconego na nią czasu.
A przy tym wszystkim będzie zrozumiała dla klienta i zespołu realizacyjnego (programistów, testerów, kierowników projektów).
Jeśli temat Cię zaciekawił dołącz do mojego newslettera.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
