Pierwsza wersja aplikacji, która pozwala wykonać najważniejsze zadanie
Nie musisz zaczynać od wszystkich funkcji, które wyobrażasz sobie w gotowym produkcie. Pomagamy wybrać pierwszy zakres aplikacji mobilnej: użytkownika, jego zadanie i kompletną ścieżkę od początku do końca. Na tej podstawie planujemy interfejs, potrzebne zaplecze i kryteria odbioru. Kolejne funkcje mają wynikać z doświadczeń z używania produktu.
Firmy, z którymi pracowaliśmy nad produktami cyfrowymi
Klienci uwielbiają z nami pracować
Jak wyznaczamy zakres MVP przed rozpoczęciem budowy
Użytkownik i jego problem
Zapisujemy, kto będzie korzystać z aplikacji i jaki efekt ma uzyskać. Zamiast zaczynać od listy ekranów, ustalamy sytuację, w której produkt ma pomóc, oraz sposób, w jaki użytkownik radzi sobie z nią dzisiaj.
Jedna kompletna ścieżka
Pierwszy zakres powinien pozwalać wykonać uzgodnione zadanie od początku do końca. Wybieramy konieczne kroki i stany błędne; odróżniamy funkcje potrzebne do działania od dodatków, które można odłożyć.
Prototyp przed implementacją
Układ ekranów i przejść pozwala omówić scenariusz przed inwestycją w całą implementację. Uzgadniamy, co prototyp ma pokazać, kto go oceni i jakie pytania ma rozstrzygnąć.
Minimum zaplecza potrzebne do pracy
Ustalamy, które dane, konta i operacje wymagają backendu lub panelu. Ograniczanie zakresu nie oznacza pomijania wymagań niezbędnych do poprawnej i odpowiedzialnej obsługi produktu.
Kryteria odbioru pierwszego wydania
Każdej kluczowej funkcji przypisujemy warunki, po których można poznać, że działa. Uwzględniamy obsługę błędów, platformy oraz sposób udostępnienia pierwszym użytkownikom.
Plan decyzji po uruchomieniu
Przed startem ustalamy, czego chcemy dowiedzieć się z użycia aplikacji. Wskazujemy zadania do obserwacji i pytania do użytkowników, aby kolejne wydanie nie powstawało wyłącznie na podstawie listy nowych pomysłów.
Jak złożony produkt dzieli się na osobne moduły
JutroDrop jako przykład zakresu produktu mobilnego
JutroDrop obejmuje kalendarz premier, newsy, promocje, ogłoszenia i powiadomienia oraz zaplecze administracyjne. Ta realizacja pokazuje, z jakich współpracujących elementów może składać się aplikacja. Nie każdy nowy produkt potrzebuje ich wszystkich na pierwszym etapie. Przy ustalaniu MVP wybieramy te, które są konieczne do wykonania konkretnego zadania użytkownika.
Co użytkownik ma móc zrobić w pierwszej wersji Twojej aplikacji?
Opisz odbiorcę, jego problem i sposób, w jaki radzi sobie z nim dzisiaj. Napisz, co chcesz sprawdzić pierwszym wydaniem. Nie potrzebujesz kompletnej specyfikacji, żeby zacząć ustalać zakres.
Pytania o MVP aplikacji mobilnej
Pierwsze wydanie wymaga jasnego zadania, granic zakresu i sposobu sprawdzenia działania. Wyjaśniamy, jak podejść do tych decyzji.
Chcesz uporządkować pomysł na pierwszą wersję? Porozmawiajmy o zakresie.
Prototyp pozwala przejść przez zaprojektowane ekrany i ocenić ścieżkę przed pełną implementacją. MVP jest działającym zakresem produktu, z danymi i operacjami potrzebnymi do wykonania zadania. Zakres prototypowania i budowy ustalamy osobno.
Wybór zależy od pierwszych odbiorców, funkcji i sposobu udostępnienia produktu. Czasem uzasadniony jest start na obu platformach, a czasem sprawdzenie jednego scenariusza na wybranej. Te decyzje łączymy z planowaniem pełnego zakresu aplikacji mobilnej.
Funkcje, które nie są konieczne do wykonania głównego zadania. Na przykład dodatkowe filtry mogą poczekać, jeżeli użytkownik już potrafi znaleźć potrzebną informację. Ograniczanie zakresu nie powinno usuwać koniecznej kontroli dostępu, obsługi błędów ani podstaw poprawnego działania.
Uzgadniamy scenariusze, elementy pierwszej wersji, zależności i kryteria odbioru; formę dokumentacji określamy w zakresie współpracy. Przykładowa karta: członek społeczności chce sprawdzić najbliższą premierę, więc potrzebuje listy, szczegółów i aktualnych danych. Kolejne mechanizmy społecznościowe zostają do oceny, a odbiór obejmuje także brak danych i błędne odpowiedzi zaplecza.
Nie. Dostarczenie działającej aplikacji nie zastępuje dotarcia do odbiorców i sprawdzenia potrzeby. Warto ustalić, kogo zaprosisz do pierwszego użycia, jakie zadanie ma wykonać i czego chcesz dowiedzieć się z jego doświadczeń.
Od zakresu głównej ścieżki, zaplecza, integracji, platform i wymagań testowych. Znaczenie ma również sposób udostępnienia pierwszym użytkownikom oraz gotowość treści i danych. Wyceniamy uzgodnione wydanie, a dodatkowe pomysły zapisujemy jako osobne decyzje.
Sprawdzamy, czy użytkownicy wykonują główne zadanie i gdzie napotykają trudności. Łączymy obserwacje z rozmowami oraz dostępnymi danymi o użyciu. Priorytety kolejnej wersji powinny wynikać z tych ustaleń, zależności i kosztu zmian.
Klienci uwielbiają z nami pracować