Pomysł na aplikację mobilną może wyglądać obiecująco na kartce, w rozmowie z zespołem albo podczas prezentacji dla inwestora. Problem zaczyna się wtedy, gdy po kilku miesiącach pracy okazuje się, że użytkownicy nie chcą instalować kolejnego programu, nie widzą wystarczającej różnicy względem istniejących rozwiązań albo nie są gotowi zapłacić za funkcję, która wcześniej wydawała się oczywista. Dlatego zanim zlecisz programowanie, sprawdź nie to, czy aplikacja da się stworzyć, lecz czy rozwiązuje konkretny problem konkretnej grupy osób. [2]
Skuteczna walidacja pomysłu na aplikację nie wymaga od razu dużego budżetu. Potrzebuje natomiast kolejności działań: sformułowania hipotez, rozmów z potencjalnymi klientami, obserwacji ich obecnych zachowań, przygotowania prostego prototypu, testu zainteresowania oraz chłodnej oceny modelu biznesowego. Celem nie jest uzyskanie pełnej pewności, bo takiej przed premierą zwykle nie da się osiągnąć. Chodzi o to, by możliwie tanio wykryć założenia, które mogą pogrążyć projekt. [4]
Najdroższy błąd nie polega na złym kodzie, tylko na budowaniu czegoś, czego nikt nie potrzebuje
Pomysł może brzmieć dobrze, a mimo to nie mieć wartości biznesowej
Zdanie „to ciekawa aplikacja” jest bardzo słabym dowodem. Rozmówca może uznać pomysł za interesujący, ponieważ podoba mu się sama koncepcja, chce być uprzejmy albo lubi rozmawiać o nowych technologiach. Nie oznacza to jeszcze, że poświęci czas na instalację, udostępni dane, zmieni swoje przyzwyczajenia lub zapłaci za korzystanie. Prawdziwa wartość pojawia się dopiero wtedy, gdy aplikacja rozwiązuje problem odczuwany dostatecznie często i dotkliwie.
Użytkownik nie instaluje aplikacji dlatego, że ma ona wiele funkcji. Instaluje ją, gdy dzięki niej szybciej coś załatwi, uniknie kosztu, ograniczy ryzyko, osiągnie cel albo zyska wygodę, której nie zapewnia obecne rozwiązanie. Czasem problem jest praktyczny, na przykład trudność w rezerwowaniu wizyt. Innym razem emocjonalny lub organizacyjny, jak brak kontroli nad terminami i obowiązkami. W obu przypadkach trzeba ustalić, co dokładnie jest uciążliwe, a nie tylko opisać zestaw planowanych ekranów.
Popularna funkcja także nie musi oznaczać dobrego produktu. Aplikacja może oferować skanowanie dokumentów, przypomnienia, mapę, czat lub automatyczne powiadomienia, ale użytkownicy mogą korzystać z tych możliwości raz na kilka miesięcy. Jeżeli problem występuje rzadko, trudniej uzasadnić instalowanie kolejnej aplikacji i regularne wracanie do niej. Alternatywą może być strona internetowa, wiadomość e-mail, arkusz kalkulacyjny albo jednorazowa usługa. [3]
Obecność konkurencji nie przekreśla pomysłu. Często potwierdza, że ktoś już dostrzegł popyt. Jest jednak sygnałem, że nie wystarczy skopiować podstawowych funkcji. Trzeba wskazać konkretną przewagę: lepszą obsługę określonego segmentu, prostszy proces, integrację z używanym narzędziem, niższą cenę, większe bezpieczeństwo, dostępność offline albo rozwiązanie problemu, który konkurenci pomijają.
Co dokładnie trzeba sprawdzić przed zleceniem programowania
Pierwsze pytanie brzmi: kto ma używać aplikacji? „Wszyscy posiadacze smartfonów”, „rodzice”, „przedsiębiorcy” czy „osoby aktywne” to zbyt szerokie określenia, by na ich podstawie przeprowadzić sensowne badanie potrzeb użytkowników. Inaczej zachowuje się właściciel małego gabinetu, inaczej pracownik dużej firmy, a jeszcze inaczej osoba korzystająca z aplikacji prywatnie. Potrzebują innych komunikatów, mają różne budżety i można do nich dotrzeć innymi kanałami.
Następnie sprawdź częstotliwość oraz wagę problemu. Czy użytkownik napotyka go codziennie, co tydzień, raz w miesiącu, czy tylko w wyjątkowych sytuacjach? Czy obecne rozwiązanie zabiera mu kilka minut, kilka godzin, czy generuje realne straty? Problem częsty, choć umiarkowanie uciążliwy, może być dobrym punktem wyjścia dla aplikacji używanej regularnie. Problem rzadki musi być na tyle ważny, aby użytkownik zaakceptował koszt instalacji, nauki i przechowywania danych.
Trzecia kwestia to alternatywy. Ludzie prawie nigdy nie pozostają całkowicie bezradni. Jeżeli nie mają dedykowanej aplikacji, mogą korzystać z notatnika, Excela, grupy na komunikatorze, telefonu do pracownika, kalendarza, kartki na lodówce lub konkurencyjnego narzędzia. Trzeba zrozumieć, dlaczego obecna metoda nie wystarcza. Sam fakt, że jest niedoskonała, nie oznacza, że użytkownik zmieni ją na nową aplikację.
Na końcu pojawia się pytanie o dotarcie i zarabianie. Nawet dobry produkt nie zdobędzie użytkowników, jeśli nie wiadomo, gdzie ich znaleźć i kto przekona ich do instalacji. Model biznesowy aplikacji może opierać się na abonamencie, płatności jednorazowej, prowizji, sprzedaży usług, reklamach lub modelu B2B, ale każda opcja wymaga innych założeń. Przychód z użytkownika powinien mieć przynajmniej potencjalną relację z kosztem pozyskania, obsługi i utrzymania aplikacji.
Sygnały, które powinny zatrzymać pochopną inwestycję
Ostrożność jest wskazana, gdy opis projektu składa się niemal wyłącznie z funkcji technicznych: logowanie, profile, geolokalizacja, płatności, powiadomienia, panel administratora i integracje. Taki opis mówi, co ma powstać, ale nie odpowiada, komu produkt pomaga i dlaczego użytkownik miałby go wybrać. Im więcej funkcji znajduje się w pierwszej wersji, tym większe ryzyko, że budżet zostanie wykorzystany na elementy, których nikt nie uzna za potrzebne.
Niebezpieczne jest również założenie, że „dobry produkt obroni się sam”. Aplikacje nie pojawiają się automatycznie w telefonach potencjalnych klientów. Potrzebują dystrybucji: treści, reklam, partnerów, sprzedaży bezpośredniej, obecnej bazy klientów, rekomendacji albo silnego efektu sieciowego. Jeżeli nie masz pomysłu, jak dotrzeć do pierwszych kilkudziesięciu użytkowników, problemem nie jest jeszcze technologia, tylko brak hipotezy dystrybucyjnej.
Przyhamuj także wtedy, gdy nie masz dostępu do osób z grupy docelowej albo nie chcesz z nimi rozmawiać przed rozpoczęciem prac. Unikanie rozmów często wynika z obawy przed krytyką pomysłu. Tymczasem negatywna informacja na początku kosztuje niewiele. Ta sama informacja uzyskana po zapłaceniu za projekt UX, programowanie i publikację może oznaczać stratę wielu miesięcy.
Alarmem jest budżet przeznaczony wyłącznie na kod. W kalkulacji powinny znaleźć się co najmniej analiza i projekt UX, testy z użytkownikami, utrzymanie serwera, poprawki, bezpieczeństwo, regulaminy, ochrona danych, analityka, publikacja w sklepach oraz promocja. Koszt stworzenia aplikacji to nie tylko faktura od programisty. Jeśli cała kwota kończy się w dniu oddania pliku instalacyjnego, produkt może nie mieć środków na sprawdzenie, czy działa w realnych warunkach.
Jeden problem może prowadzić do kilku zupełnie różnych produktów
Pomysł na aplikację do organizacji rodzinnych obowiązków brzmi uniwersalnie. Dopiero rozmowy mogą pokazać, że w jednej rodzinie problemem jest brak listy zadań, w innej brak odpowiedzialności za ich wykonanie, a w jeszcze innej trudność w uzgadnianiu terminów między rodzicami pracującymi zmianowo. Każda diagnoza prowadzi do innego rozwiązania.
W pierwszym przypadku wystarczy być może prosty współdzielony harmonogram. W drugim potrzebny byłby mechanizm przypisywania zadań i potwierdzania ich realizacji. W trzecim większą wartość może mieć synchronizacja kalendarzy oraz automatyczne proponowanie terminów. Zbudowanie „aplikacji do obowiązków rodzinnych” bez rozstrzygnięcia, który problem jest najważniejszy, grozi stworzeniem rozbudowanego, lecz nieprzekonującego narzędzia.
Zanim sprawdzisz pomysł, zamień go w hipotezy, które da się potwierdzić albo obalić
Zdefiniuj jednego pierwszego użytkownika
Persona opisana wyłącznie przez wiek, płeć i miejsce zamieszkania rzadko wystarcza. Znacznie więcej mówi sytuacja oraz zachowanie: „właścicielka małego gabinetu kosmetycznego, która samodzielnie odbiera telefony, prowadzi kalendarz i traci czas na przekładanie wizyt” albo „student pracujący na zmiany, który regularnie wymienia się dyżurami z grupą znajomych”. Taki opis wskazuje kontekst, moment wystąpienia problemu i możliwe miejsce dotarcia do odbiorcy.
Trzeba rozdzielić trzy role. Użytkownik korzysta z aplikacji. Decydent wybiera lub zatwierdza zakup. Płatnik ponosi koszt. W aplikacji do zarządzania pracą zespołu użytkownikiem może być pracownik, decydentem kierownik, a płatnikiem właściciel firmy. Jeżeli te role są różne, rozmowa z jedną osobą nie odpowie na wszystkie pytania. W modelu konsumenckim role zwykle się łączą, ale nie należy przyjmować tego automatycznie.
Wybierz wąski segment na start. „Przedsiębiorcy” to niejednorodna grupa, natomiast „właściciele małych gabinetów przyjmujący wizyty wyłącznie stacjonarnie” stanowią znacznie lepszy punkt wyjścia. Zawężenie nie oznacza, że aplikacja na zawsze będzie dostępna tylko dla nich. Ułatwia jednak stworzenie konkretnego komunikatu, znalezienie rozmówców i zauważenie, czy problem powtarza się w podobny sposób.
Zapisz problem w formie konkretnego zdania
Pomocny schemat brzmi: „Kiedy [sytuacja], [grupa użytkowników] ma trudność z [problem], co powoduje [konsekwencja]”. Przykład: „Kiedy klient odwołuje wizytę w ostatniej chwili, właściciele małych gabinetów mają trudność z szybkim znalezieniem zastępstwa, co powoduje puste godziny i utracony przychód”. To zdanie nie zakłada jeszcze aplikacji. Dopuszcza także telefon, automatyczną listę rezerwową, usługę concierge lub integrację z istniejącym systemem.
Unikaj sformułowań takich jak „użytkownicy potrzebują aplikacji do zarządzania zadaniami”. To opis rozwiązania, a nie problemu. Gdy rozwiązanie zostanie wpisane do założenia, łatwo zacząć dopasowywać wszystkie odpowiedzi do pierwotnego pomysłu. Lepsze pytanie brzmi: „Co dzieje się obecnie, gdy zadanie zostaje zapomniane, i jakie są tego skutki?”.
Problem powinien być możliwy do zaobserwowania w codziennym działaniu. Jeżeli rozmówca deklaruje: „czasem przydałoby mi się coś takiego”, dopytaj, kiedy ostatnio wystąpiła opisana sytuacja, jak sobie wtedy poradził i ile kosztowało go to czasu lub pieniędzy. Konkretne wspomnienie jest zwykle bardziej wiarygodne niż ogólna ocena przyszłego produktu.
Ustal najważniejsze hipotezy biznesowe
Walidacja pomysłu na aplikację polega na sprawdzaniu założeń, a nie na zbieraniu przypadkowych opinii. Najczęściej trzeba zweryfikować kilka rodzajów hipotez:
Dobrym uzupełnieniem tego tematu jest także poradnik: Jak zbudować strategię finansową małej firmy?.
- Hipoteza problemu – określona grupa rzeczywiście zmaga się z daną trudnością.
- Hipoteza grupy docelowej – wiadomo, gdzie te osoby znaleźć i jak opisać ich sytuację.
- Hipoteza rozwiązania – proponowany sposób jest wyraźnie wygodniejszy od obecnych alternatyw.
- Hipoteza popytu – część osób wykona działanie wymagające większego zaangażowania, na przykład zapisze się na listę, umówi rozmowę, zamówi pilotaż lub zostawi dane.
- Hipoteza finansowa – przychód z użytkownika może uzasadnić koszt pozyskania, obsługi i utrzymania.
Najtańsza walidacja zaczyna się od rozmów i obserwacji, nie od tworzenia aplikacji
Najpierw porozmawiaj o ostatniej konkretnej sytuacji
Pierwszym testem nie musi być ankieta wysłana do setek osób. Zwykle więcej dowiesz się z kilkunastu rozmów przeprowadzonych z osobami należącymi do wybranego segmentu. Nie zaczynaj jednak od pytania: „Czy korzystałbyś z aplikacji, która…?”. Rozmówca chce być uprzejmy, może polubić sam pomysł albo odpowiedzieć zgodnie z tym, co według niego chcesz usłyszeć. Taka deklaracja nie oznacza jeszcze gotowości do instalacji ani zapłaty.
Lepszy jest wywiad oparty na przeszłości i zachowaniu. Zapytaj:
- „Kiedy ostatnio wystąpiła taka sytuacja?”
- „Jak wtedy sobie poradziłeś?”
- „Z jakich narzędzi lub osób skorzystałeś?”
- „Ile czasu albo pieniędzy to kosztowało?”
- „Co w obecnym sposobie działania jest najbardziej uciążliwe?”
- „Czy próbowałeś już coś zmienić? Dlaczego to nie zadziałało?”
Nie prowadź rozmowy jak prezentacji sprzedażowej. Najpierw pozwól rozmówcy opisać własny proces, używane narzędzia i momenty frustracji. Dopiero później pokaż krótki opis potencjalnego rozwiązania i sprawdź, która jego część odpowiada na realną potrzebę. Zapisuj dokładne sformułowania, przykłady i powtarzające się sytuacje, a nie tylko ogólne oceny typu „brzmi ciekawie”.
Obserwuj, co ludzie robią zamiast tego, co deklarują
Rozmowa pokazuje sposób myślenia, ale obserwacja często ujawnia zachowania, o których użytkownik nie wspomina. Poproś o pokazanie obecnego procesu: arkusza, kalendarza, grupy na komunikatorze, dokumentu, systemu rezerwacji albo notatek w telefonie. Zwróć uwagę, gdzie pojawiają się obejścia, ręczne przepisywanie danych, pomyłki i opóźnienia.
Właścicielka gabinetu może twierdzić, że problemem jest brak aplikacji do zarządzania odwołanymi wizytami. Dopiero obserwacja może pokazać, że najwięcej czasu traci nie na samo znalezienie klienta zastępczego, lecz na ręczne sprawdzanie kilku kanałów kontaktu i pamiętanie, komu można zaproponować wolny termin. W takim przypadku kluczową wartością może być nie rozbudowany kalendarz, ale szybkie dopasowanie wolnego terminu do listy oczekujących. [1]
Jeżeli nie możesz obserwować pracy użytkownika na żywo, poproś o nagranie ekranu, zdjęcia używanych notatek albo opis całego procesu krok po kroku. Nie zbieraj przy tym danych, które nie są potrzebne do badania. W przypadku dokumentów firmowych, danych klientów lub informacji zdrowotnych trzeba zadbać o anonimizację i zgodę na ich wykorzystanie.
Ustal, kiedy odpowiedź jest wystarczająco mocnym sygnałem
Przed rozmowami zapisz kryteria, które wpłyną na decyzję. Bez tego łatwo uznać każdą pozytywną wypowiedź za potwierdzenie pomysłu. Przykładowo możesz przyjąć, że hipoteza problemu będzie wstępnie potwierdzona, jeśli większość rozmówców z wybranego segmentu opisała podobną sytuację, spotyka się z nią regularnie i już poświęca czas lub pieniądze na obejście trudności.
Nie chodzi o magiczną liczbę wywiadów, lecz o powtarzalność wzorców. Jeżeli po kilku rozmowach każda osoba wskazuje zupełnie inny problem, segment jest prawdopodobnie zbyt szeroki albo założenie zostało sformułowane zbyt ogólnie. Jeżeli kolejne rozmowy przynoszą te same przykłady, można przejść do testu zachowania.
Warto prowadzić prostą tabelę z kolumnami: segment, opisana sytuacja, obecne rozwiązanie, częstotliwość, koszt problemu, gotowość do kolejnego kroku oraz cytat rozmówcy. Oddzielaj fakty od interpretacji. „Pięć osób pokazało własny arkusz” to fakt. „Użytkownicy chcą automatyzacji” to już wniosek, który wymaga dalszego sprawdzenia.
Sprawdź zainteresowanie bez budowania pełnej aplikacji
Po rozmowach możesz zaproponować rozwiązanie w najprostszej formie, która pozwoli zmierzyć rzeczywiste zaangażowanie. W zależności od pomysłu będzie to:
- prosta strona opisująca konkretny problem i obiecaną wartość,
- formularz zapisu na pilotaż lub listę oczekujących,
- ręcznie obsługiwana usługa udająca działanie przyszłej aplikacji,
- prototyp klikalny pokazujący główną ścieżkę użytkownika,
- test reklamowego komunikatu kierowanego do ściśle określonego segmentu,
- płatny pilotaż z kilkoma firmami albo użytkownikami.
Strona testowa powinna mówić o sytuacji odbiorcy, a nie wyliczać wszystkie planowane funkcje. Zamiast nagłówka „Nowoczesna aplikacja z kalendarzem, powiadomieniami i integracjami” skuteczniejszy może być komunikat: „Zapełnij odwołane wizyty bez ręcznego pisania do kilkudziesięciu klientów”. Dodaj jedno wyraźne wezwanie do działania: zapis, umówienie rozmowy, przesłanie zgłoszenia lub rezerwację miejsca w pilotażu.
Sam klik w reklamę jest słabym sygnałem. Mocniejsze są działania wymagające czasu, danych albo pieniędzy. Ktoś, kto zostawia kontakt, opisuje swój przypadek, zgadza się na test lub deklaruje udział w płatnym pilotażu, pokazuje większe zainteresowanie niż osoba, która tylko polubiła post. Wyniki trzeba jednak interpretować w kontekście źródła ruchu, ceny, komunikatu i jakości pozyskanych kontaktów.
Zastąp pierwszą wersję aplikacji ręcznym procesem
Niektóre pomysły można sprawdzić, wykonując usługę częściowo manualnie. Jeśli aplikacja ma automatycznie dobierać klientom wolne terminy, na początku możesz przyjmować zgłoszenia przez formularz, a dopasowanie wykonywać samodzielnie. Jeżeli użytkownicy otrzymują wartość mimo braku automatyzacji, zyskujesz dowód, że problem i obiecany rezultat są istotne. Dopiero później sprawdzasz, które czynności warto zautomatyzować.
Taki test nie powinien być przedstawiany jako gotowa aplikacja, jeśli nią nie jest. Uczciwie poinformuj uczestników pilotażu, że korzystają z wczesnej wersji usługi lub testu. Dzięki temu unikniesz fałszywych oczekiwań i dowiesz się, czy użytkownik akceptuje proponowany sposób pracy, zanim zainwestujesz w technologię.
Prototyp klikalny jest przydatny do sprawdzania zrozumiałości procesu, kolejności ekranów i reakcji na główną obietnicę. Nie potwierdza jednak, że użytkownik będzie regularnie korzystał z produktu. Podczas testu poproś badaną osobę o wykonanie konkretnego zadania, na przykład: „Znajdź wolny termin i wyślij propozycję klientowi”. Nie pytaj wyłącznie, czy interfejs jej się podoba. Obserwuj, gdzie się zatrzymuje, czego szuka i jakie pytania zadaje.
Czego nie robić podczas sprawdzania pomysłu
Najczęstszą pułapką jest pytanie znajomych, czy aplikacja jest dobrym pomysłem. Bliskie osoby zwykle chcą wesprzeć autora, a poza tym nie zawsze należą do grupy docelowej. Ich opinia może pomóc znaleźć niejasne sformułowania, ale nie powinna być głównym dowodem popytu.
Unikaj też ankiet z pytaniami sugerującymi odpowiedź: „Czy przydatna byłaby aplikacja, która oszczędza godzinę tygodniowo?”. Tak skonstruowane pytanie opisuje korzyść i skłania do potwierdzenia. Jeżeli korzystasz z ankiety, zacznij od pytania o obecne zachowanie, a dopiero na końcu przedstaw krótki wariant rozwiązania.
Nie traktuj liczby zapisów jako jedynego kryterium. Użytkownicy mogą zostawić adres e-mail, ponieważ oferta nic ich nie kosztuje. Dlatego warto szybko przejść z deklaracji do kolejnego działania: rozmowy, przesłania danych potrzebnych do testu, użycia prototypu, udziału w pilotażu lub zapłaty za konkretną usługę.
Błędem jest również testowanie kilku grup i kilku problemów jednocześnie. Jeżeli reklama kieruje się do rodziców, studentów, freelancerów i właścicieli firm, a strona opisuje pięć różnych korzyści, nie dowiesz się, co właściwie zadziałało. Na początku ogranicz eksperyment do jednego segmentu, jednego problemu i jednej obietnicy.
Przejdź od dowodu problemu do decyzji o budowie
Po pierwszej serii rozmów i testów nie pytaj jeszcze: „Czy budować całą aplikację?”. Zadaj bardziej precyzyjne pytania:
- Czy problem powtarza się w określonej grupie?
- Czy obecne alternatywy są wystarczająco niewygodne, kosztowne lub nieskuteczne?
- Czy użytkownik rozumie proponowaną wartość bez długiego wyjaśniania?
- Czy wykonuje działanie wykraczające poza uprzejme zainteresowanie?
- Czy ręczny pilotaż daje mu rezultat, za który chce wrócić albo zapłacić?
- Czy wiadomo, jak dotrzeć do kolejnych osób o podobnym profilu?
Jeżeli odpowiedzi są negatywne, nie musi to oznaczać końca pomysłu. Być może trzeba zawęzić grupę, zmienić komunikat, rozwiązać inny fragment procesu albo zrezygnować z aplikacji na rzecz prostszej usługi. Jeżeli natomiast użytkownicy opisują ten sam problem, podejmują kolejne kroki i korzystają z pilotażu, można przygotować ograniczony zakres pierwszej wersji.
Najbezpieczniejsza kolejność to: rozmowy, obserwacja, ręczny test lub prototyp, pomiar konkretnego działania, a dopiero potem programowanie. Kod powinien automatyzować proces, którego wartość została już zauważona, nie zastępować brakujące zainteresowanie. Przed podpisaniem umowy z wykonawcą określ więc jedną główną ścieżkę użytkownika, warunek sukcesu pilotażu i listę funkcji koniecznych do jej obsłużenia. Resztę odłóż do czasu, gdy realne zachowanie użytkowników pokaże, że jest potrzebna.
Najważniejsze punkty
- Przed programowaniem sprawdź, czy aplikacja rozwiązuje konkretny i odczuwalny problem określonej grupy użytkowników.
- Rozmawiaj z potencjalnymi klientami o ich obecnych zachowaniach, trudnościach i używanych alternatywach, a nie tylko o samym pomyśle.
- Zacznij od wąskiego segmentu oraz jednej jasno sformułowanej hipotezy problemu.
- Oceń częstotliwość i wagę problemu, gotowość do zmiany przyzwyczajeń oraz możliwość dotarcia do pierwszych użytkowników.
- Nie przeznaczaj całego budżetu na kod. Uwzględnij między innymi testy, utrzymanie, bezpieczeństwo, analitykę i promocję.
- Prosty prototyp lub test zainteresowania może pomóc taniej wykryć założenia, które zagrażają projektowi.
Pytania od czytelników
Ile osób warto zaprosić do pierwszych rozmów?
Czy konkurencja oznacza, że nie warto rozwijać pomysłu?
Czy aplikacja zawsze jest lepsza od strony internetowej albo arkusza?
Co zrobić, jeśli nie wiem, jak dotrzeć do pierwszych użytkowników?
