Discovery Sprint pomaga szybko zweryfikować pomysł biznesowy i jest idealnym pierwszym krokiem w budowaniu użytecznych i skalowalnych aplikacji i systemów biznesowych. Daje nam dobrze rozwiniętą ogólną ramę dla struktury sprintu i przetestowany zestaw narzędzi, co pozwala nam przeprowadzać go systematycznie i optymalnie zbierać kluczowe informacje. Jeśli chcesz dowiedzieć się więcej o procesie Discovery Sprint, przeczytaj nasz artykuł.
Wszystkie czynności podczas sprintu są ze sobą powiązane i zaplanowane w sekwencjach, tak aby spostrzeżenia z poprzedniego ćwiczenia służyły jako podstawa do kolejnych kroków. Po Discovery Sprincie otrzymasz specyfikację funkcjonalną i biznesową, kluczowe ekrany koncepcji oraz prezentację dla zarządu. Co to oznacza i czego się spodziewać? W tym artykule znajdziesz przykłady docelowych materiałów, ich opis i najważniejsze korzyści.
Co chcemy zbudować?
Pierwszym krokiem do urzeczywistnienia pomysłu jest precyzyjne zmapowanie wizji produktu. Czy jest to przeprojektowanie istniejącego rozwiązania cyfrowego? Przenosimy proces offline na cyfrowy? Tworzymy nowe rozwiązanie? W zależności od odpowiedzi możemy dostosować kolejne kroki do potrzeb projektu. Na podstawie materiałów warsztatowych możemy przygotować docelowe materiały.
Podczas warsztatu zbieramy odpowiedzi na pytania biznesowe i mapujemy kluczowe założenia. Pomaga nam to zrozumieć, dlaczego chcesz zbudować swoje rozwiązanie i jaki problem to rozwiąże. Definiujemy odbiorców i myślimy o ich konkretnych potrzebach. Porównujemy planowane rozwiązanie z rozwiązaniami konkurencji i określamy naszą unikalną propozycję wartości. Skupiamy się na temacie sprintu, mając jednocześnie na uwadze cały ekosystem. Głównym celem warsztatów business design podczas Discovery Sprint jest określenie celów długoterminowych i zidentyfikowanie możliwych wyzwań.
Dlaczego to robimy?
– aby poznać uzasadnienie, dlaczego warto zainwestować w pomysł
– aby zrozumieć, jak ten pomysł wpisuje się w szerszy kontekst biznesowy
– aby umieć zaproponować odpowiednie rozwiązania
– aby być świadomym potencjalnych ograniczeń
– aby reagować na potencjalne zagrożenia, zanim jeszcze się pojawią
Kto będzie korzystać z naszego rozwiązania?
Persony
Persona jest dobrze znanym artefaktem w procesie myślenia projektowego. Jest to fikcyjny, ale realistyczny opis użytkowników produktu, reprezentujący podobne zachowania, cele i motywacje. Podsumowuje dane i wizualizuje spostrzeżenia.
Optymalną praktyką jest tworzenie person w oparciu o badania, np. wywiady z użytkownikami końcowymi lub analitykę z bieżącej aplikacji. Jeśli nie mamy żadnych badań, możemy zamiast tego zbudować proto-persony, ale ponieważ będą oparte jedynie na założeniach, musimy pamiętać, że trzeba będzie je później zweryfikować.
Budując persony musimy pamiętać, że nie chodzi nam o „przeciętnego” użytkownika. Mają one reprezentować wspólne cechy rzeczywistych grup ludzi (wspólne postawy, cele, problemy i oczekiwania). Nie jest to też to samo co persona marketingowa, bo mniej skupiamy się na danych demograficznych i preferencjach, a bardziej na potrzebach, bolączkach, działaniach i przyczynach.
Dlaczego to robimy?
– aby wywołać empatię i przyjąć perspektywę użytkownika
– aby skupić się na rzeczywistych potrzebach i zweryfikować założenia
– aby zebrać wstępne wymagania i pomóc w przemyśleniu rozwiązań
– aby łatwiej było wyobrazić sobie odbiorców i odnosić się do nich
– przełożyć abstrakcyjną ideę na człowieka „z krwi i kości”
User/job stories
Jest to mapa wymagań i opis funkcjonalności aplikacji z punktu widzenia użytkownika. Po zdefiniowaniu naszych person możemy zacząć myśleć o tym, co ci ludzie próbują osiągnąć za pomocą naszego narzędzia z różnych perspektyw. Historie powinny być krótkie, nieformalne, nietechniczne i ogólne. Ważne jest, aby skupić się na tym, jak nasza praca przekłada się na zysk dla użytkownika.
Standardowa struktura user story podczas Discovery Sprint to „Jako …, chcę …, aby …”, na przykład „Jako respondent chcę, by moje odpowiedzi były zapisywane automatycznie, aby nie musieć zaczynać od początku”. Koncentruje się na roli, co jest szczególnie pomocne, gdy w systemie mamy wiele person z różnymi procesami do zrealizowania. Kiedy chcemy bardziej skupić się na kontekście użycia, możemy zastosować job story: „Kiedy …, chcę …, aby móc …”, na przykład „Kiedy wychodzę z ankiety i wracam po pewnym czasie, chcę by moje odpowiedzi były automatycznie zapisane, aby móc łatwo zacząć w miejscu, w którym skończyłam”.
Warto pamiętać, że ćwiczenie ma na celu zebranie wymagań i nie pracujemy jeszcze nad ostatecznymi rozwiązaniami, więc skupiamy się na intencjach użytkownika, a nie sposobie implementacji czy interfejsie.
Dlaczego to robimy?
– aby zmapować wymagania i zakres produktu
– aby uchwycić cel wraz z funkcją
– aby uzyskać wstępny pogląd na złożoność systemu
– aby używać naturalnego i łatwego do odczytania języka zamiast długich stron specyfikacji
– aby szybko zweryfikować, czy pomysł na jakąś funkcję ma sens
– aby stworzyć podstawy do mapowania architektury informacji i praw dostępu
– aby móc przełożyć to na plan wdrożenia i testów
Jaki jest zakres Discovery Sprint?
Priorytetyzowanie funkcjonalności
Zwykle w trakcie tego procesu zbieramy wiele pomysłów, a wdrożenie ich wszystkich na raz jest wyzwaniem, zwłaszcza gdy każda funkcja wydaje się równie istotna. W takim przypadku korzystne jest użycie prostego value-effort matrix w celu zmapowania względnej ważności działań.
Ta prosta matryca może nam pomóc podzielić funkcjonalności na mniejsze grupy i pokazać kolejność implementacji. W dalszej pracy skupiamy się na „szybkich wygranych” (wysoka wartość i mały wysiłek) i wybieramy 1 lub 2 „duże zakłady” (wysoka wartość i duży wysiłek). Nasze „może” (niska wartość i niewielki wysiłek) doskonale wypełniają luki, na przykład podczas oczekiwania na informację zwrotną, kiedy mamy wolny czas do wykorzystania. I wreszcie „pochłaniacze czasu” (niska wartość i duży wysiłek) to rzeczy, które na razie decydujemy się pominąć.
Aby uchwycić cały obraz, najlepiej zaprosić osoby z różnych obszarów do wykonania tego zadania. Zespół biznesowy może odnosić się do wartości i wysiłku dla organizacji, zespół UX może reprezentować interesy użytkowników, a zespół programistów może oszacować trudność wdrożenia.
Dlaczego to robimy?
– aby upewnić się, że nie zapomnieliśmy o żadnej wartościowej funkcji
– aby zidentyfikować, czy jest coś, czego nie warto implementować w MVP
– aby określić najbardziej ryzykowne pomysły
– aby zachęcać do dyskusji i zbierać różne punkty widzenia
Architektura informacji
To schemat z kluczowymi kategoriami i podkategoriami w systemie. Pomaga nam to zdefiniować strukturę treści, co możemy wykorzystać później do określenia, w jaki sposób użytkownicy będą poruszać się po naszym rozwiązaniu i jak będzie zbudowana nawigacja. Dbamy o to, aby nazewnictwo było adekwatne i spójne, mapujemy treści i grupujemy podobne elementy. Następnie porządkujemy i mapujemy relacje między informacjami. To szkielet naszego produktu.
Systemy biznesowe mogą mieć złożone struktury zarówno w pionie, jak i w poziomie. Przejrzysta architektura informacji pozwala użytkownikom szybko i bez rozpraszania się znaleźć odpowiednie treści. Może być skrojona pod role i obejmować ograniczony dostęp do określonych sekcji systemu. Warto pamiętać, że z czasem będzie pojawiać się co raz więcej treści i funkcjonalności, więc architektura informacji powinna być łatwo skalowalna, zwłaszcza gdy stworzymy Minimum Viable Product (MVP).
Dlaczego to robimy?
– aby zbudować czytelną hierarchię elementów
– aby pokategoryzować grupy podobnych elementów
– aby zmapować strukturę
– aby omówić etykiety dla kategorii
– aby mieć przegląd zakresu
– aby zrozumieć złożoność systemu
Role i uprawnienia
To jest lista różnych ról, możliwych akcji i praw dostępu. Pomaga nam to zrozumieć, która część systemu będzie dostępna dla jakich grup. Na podstawie listy możemy spersonalizować strony główne, procesy, funkcje i nawigację dla każdej roli.
Zwykle role są zorganizowane hierarchicznie, co pozwala nam spełnić wymagania bezpieczeństwa w systemie – np. użytkownicy mogą tworzyć tylko role, które mają taką samą lub niższą rangę w systemie. Niektóre role to „super-użytkownicy”, którzy mogą robić prawie wszystko, podczas gdy inne mają poziom „tylko do przeglądania”. Możemy odróżnić role, które wymagają założenia konta od tych, które nie muszą tego robić. Nasze systemy mogą być elastyczne, ale ważne jest, aby przemyśleć strukturę ról, zanim programiści utworzą bazy danych, ponieważ późniejsza reorganizacja może zająć dużo czasu i wysiłku.
Dlaczego to robimy?
– aby upewnić się, że właściwe osoby zobaczą właściwe informacje
– aby blokować dostęp do części systemu, które nie powinny być widoczne dla „zwykłych” użytkowników
– dla bezpieczeństwa danych
– aby nie rozpraszać użytkowników nieistotnymi treściami i funkcjami
– aby pomóc użytkownikom poruszać się po procesach
Jak to będzie działać?
User flow
Aby oszacować czas i wysiłek potrzebny do wdrożenia docelowego rozwiązania, podczas discovery sprint mapujemy ekrany wymagane do tego, aby cały proces działał. Możemy oszacować, ile ekranów potrzebujemy i w jakiej kolejności powinny być zaprojektowane.
Zaczynamy od schematu, który pokazuje proces podejmowania decyzji przez użytkowników i etapy wykonywania zadań w różnych przypadkach użycia. Następnie wypisujemy ekrany i układamy je w diagram, który wizualizuje połączenia między nimi. Dodajemy kluczowe informacje lub funkcje, które użytkownicy widzą na każdym ekranie, oraz ich wpływ na proces podejmowania decyzji podczas korzystania z produktu. Na podstawie mapy procesu możemy zrozumieć różne przypadki użycia i zobaczyć, jak wpisują się w całość rozwiązania.
Dlaczego to robimy?
– aby zwizualizować możliwe ścieżki użytkowników
– aby mieć przegląd zakresu
– aby zrozumieć strukturę aplikacji
– aby zrozumieć kroki i ich kolejność
– aby upewnić się, że proces jest kompletny i optymalny
– aby zaznaczyć relacje między ekranami i modułami i zobaczyć możliwe przejścia
Koncepcja
Na podstawie wszystkich dotychczasowych materiałów możemy zaproponować, jak mogłoby wyglądać ostateczne rozwiązanie. Jest to wizualizacja aplikacji – typowo 5 kluczowych ekranów. Przedstawiamy najważniejsze widoki, aby pomóc wszystkim zrozumieć całą ideę. Nie zagłębimy się w wiele szczegółów, ale to doskonała podstawa do wstępnej weryfikacji i dalszego rozwoju. Głównym celem jest tu wsparcie narracji, więc ekrany powinny zawierać rzeczywistą treść, aby w jak największym stopniu naśladować kontekst użycia.
Koncepcję można wykonać nawet za pomocą zwykłego papieru i ołówka, ale ponieważ jeden obraz jest wart więcej niż tysiąc słów, zalecamy skorzystanie z dedykowanego Design Systemu. Jeśli Twoja organizacja już go posiada, będziemy mogli wykorzystać go do stworzenia makiet. Jeśli nie, skorzystamy z naszej wewnętrznej biblioteki komponentów, która może być bazą do budowy spójnego interfejsu w przyszłości.
Design System pozwala nam używać elementów UI jak cegiełek, postępować zgodnie z określonymi wytycznymi i natychmiast budować wszystkie widoki systemu zgodnie z docelowym wyglądem i stylem. Dzięki temu przygotowywanie makiet high-fidelity jest znacznie szybsze, a nowy system jest natychmiast spójny z resztą rozwiązań, aby dopasować się do całego ekosystemu. W pełni rozwinięty Design System zawiera również fragmenty kodu dla programistów, co ułatwia jego wdrożenie oraz oszczędza mnóstwo czasu i pieniędzy.
Dlaczego to robimy?
– aby uzgodnić treści
– aby zobaczyć strukturę
– aby zaprezentować interesariuszom
– aby przedstawić wartość aplikacji
– aby pomysły były łatwiejsze do wyjaśnienia
– aby zobaczyć, jak to wszystko razem działa
– aby przeprowadzić pierwszą weryfikację pomysłu
Prezentacja dla decydentów
Na koniec procesu wyłapujemy kluczowe spostrzeżenia z naszego Discovery Sprintu i tworzymy zwięzłą prezentację. Pomoże to rozpowszechniać Twój pomysł, zaprosić ludzi do dowiedzenia się więcej i uzyskania niezbędnych akceptacji.
Na podstawie wszystkich materiałów łatwiej będzie oszacować czas, pracochłonność i koszt realizacji. Rekomendujemy zweryfikowanie pomysłu na produkt z potencjalnymi odbiorcami przed rozpoczęciem wdrożenia. Testowanie może obejmować ustrukturyzowane badania eksploracyjne, a nawet nieformalne rozmowy i dyskusje, by zebrać informacje zwrotne. Nasi specjaliści mogą pomóc Ci w zaplanowaniu badań po sprincie, aby upewnić się, że docelowe rozwiązanie spełni swoje zadanie i odpowie zarówno na potrzeby docelowych użytkowników, jak i organizacji.
