Od pomysłu do prototypu, czyli aplikacja mobilna bez dotykania klawiatury

Każdy projekt zaczyna się od pomysłu. Nie inaczej jest z moim projektem w ramach konkursu “Daj się poznać 2017”. Chcę napisać aplikację mobilną wspomagającą zarządzanie domową apteczką: kontrolowanie, które leki się ma, a którym kończy się termin przydatności. Chciałbym także, aby ta aplikacja pomagała w znajdowaniu leków, które już się ma, a które podobne lekarz zalecił kupić, aby po prostu wydawać (i marnować) mniej i nie kupować 4. opakowania aspiryny, bo wydaje mi się, że się kończy.

Oderwanie się od ekranu

Ale co dalej z tym pomysłem? Zanim zacznę kodować, postanowiłem go urealnić. Nie tylko wyobrazić sobie, jak moja aplikacja będzie wyglądała albo jakie miała funkcje, ale zaprojektować, co i jak będzie działało:

• jakie ekrany będzie miał do dyspozycji użytkownik,
• co będzie na nich istotne,
• ile ich będzie,
• co znajdzie się na pierwszej stronie po włączeniu aplikacji,
• jakie będą formularze i jakie pola będą w nich dostępne,
• po czym będzie można filtrować listę leków
• i wreszcie, jak połączyć listę “planów zakupowych” z informacjami o tym, które leki się w domu kończą.

Całość miała na celu oderwanie się od tego, do czego my, programiści, przywykliśmy, czyli projektowania aplikacji, patrząc na techniczną stronę projektu. Bo pierwszym, o czym myślimy, są tabelki w bazce danych, requesty, callbacki, eventy i hierarchia klas. Ale przecież ważniejszy jest finalny produkt, a nie to czy tu będzie STI, a może tam ENUM albo relacja one_to_many i wzorzec Adapter.

Drugim problemem, w jaki łatwo wpaść, tworząc swój kolejny genialny pomysł, jest eksplozja funkcjonalności i perfekcjonizm. Bo przecież chciałoby się, aby produkt był idealny. By miał wszystko zaimplementowane jak najlepiej, zachwycał z zewnątrz i od środka. Więc bardzo łatwo przeładować go funkcjami, oczekiwać od siebie więcej, niż to jest realne, albo utonąć w nieistotnych detalach.

Prototyp na papierze

To ćwiczenie — stworzenie prototypu aplikacji na papierze — miało za zadanie uchronić mnie przed tym wszystkim. Zbyt wiele genialnych projektów poszło w niepamięć przez powyższe sytuacje. Tym razem postanowiłem podejść do sprawy inaczej. Zacząć od zobaczenia efektu końcowego w postaci prototypu na papierze, i na tym konkrecie się później skupić, realizując całość. To też dla mnie ważny krok, bo nie mam klienta zewnętrznego — czyli kogoś, kto powie mi: “potrzebuję tego, a to ma działać tak” — i ogranicza mnie tylko moja wyobraźnia. A taki papierowy konkret pozwoli później skupić się na tym, co naprawdę istotne.

Oczywiście, mogłem użyć po prostu kartki i długopisu, ale że miałem pod ręką jeden z notesów UXPin, postanowiłem go wykorzystać. Co to takiego? To zestaw post-itów przedstawiających różne podstawowe elementy interfejsu użytkownika (takie jak przyciski, selecty, inputy itp.), które można dowolnie przyklejać. Bazgrać po nich, wycinać, bo to przecież tylko papier. Co prawda nie miałem zeszytu przeznaczonego tylko do aplikacji mobilnych, więc musiałem nieco improwizować, ale jestem bardziej niż zadowolony z efektu. Co mi z tego wyszło, możecie zobaczyć poniżej:

Co dalej?

Mam 7 ekranów kluczowych dla mojej aplikacji. Kolejnym krokiem, gdy wiem już, jak będzie wyglądała, jest spisanie poszczególnych funkcjonalności i próba ich ograniczenia. Tak, aby dało się zrobić najpierw pierwszą minimalną wersję produktu, a dopiero później, w trakcie kolejnych iteracji, dobudowywać resztę.

Te ekrany to:

• ekran główny,
• strona wyszukiwania po kodzie kreskowym leku,
• strona listy leków / wyników wyszukiwania,
• lista zakupów,
• strona leku,
• strona dodawania suplementu bądź leku spoza bazy,
• strona z ulotką.

Minimum funkcjonalności stanowi tak naprawdę tylko strona leku i listy leków (może też zastąpić stronę główną na start) i na tym skupię się w pierwszej kolejności.

To tyle na dziś. Ciekaw jestem, jakie Wy macie doświadczenia z prototypowaniem i realizowaniem własnych pomysłów. Czy zaczynacie od projektu, a może zupełnie innej strony?