Meine erste App, ein Minimum Viable Product.

Im 2021 lernte ich während dem Lockdown programmieren. Wenig später veröffentlichte ich meine erste App für iOS und Android.

Als kompletter Quereinsteiger in die Programmierung hatte ich von nichts wirklich eine Ahnung… Doch ich hatte ein Ziel: Meine erste App muss in den App Store!

Ich programmierte einfach mal drauflos 🤯 Ja. Das klappte nicht so einfach. Vieles würde ich heute anders machen. Diese spannende Erfahrung möchte ich gerne teilen!

Also los, schauen wir zurück auf die Entstehung einer App!

Also let’s go, zurück in die Zukunft 😉

Das ist ein minimum viable Product „MVP“

Das Konzept ist nicht neu… Es erinnert sicher gleich an einen Prototypen oder PoC (Proof-of-Concept). Doch anders als diesen ist ein MVP wirklich ein fertiges Produkt, welches auf dem Markt verfügbar ist.

Das Minimum Viable Product ist die erste Version eines Produkts, die frühzeitiges Feedback ermöglicht und Risiken bei der Entwicklung minimiert.

Dabei soll bewusst aus Nutzerfeedback gelernt und agil weiterentwickelt werden. Mein Ziel war es einen Party-Begleiter zu veröffentlichen. Der Businessplan ist ganz löcherig, aber primär wollte ich ja mit Fillup Party lernen. Also baute ich eine erste Version, welche alle basics der Idee erfüllten aber keineswegs wirklich stabil oder clean programmiert war.

Nach meiner ersten öffentlichen Version der App musste ich natürlich all meinen Freunden über diese grossen Neuigkeiten berichten. Fleissig wurde die App installiert, doch bereits erste Fragen kamen auf… „Für was soll ich jetzt die App nutzen?“

Ich war verwirrt. War der Nutzen also nicht klar? Nach zig Feedbacks, direktem Nachfragen und diversen Einsätzen und Demos sah ich plötzlich wieso Unklarheiten bestanden und erhielt viele Verbesserungsvorschläge.

Ja dann, einfach ein Update hochladen oder!? Halt. Ein Update geht mir zu langsam. Feedback muss ich schneller und einfacher erhalten können.

Die Vision: Annahmen treffen.

Ich hatte zu Beginn eine klare Vision. Bei der Programmierung einer gesamten App als kompletter Neuling beschäftigte ich mich plötzlich aber zu tief mit Details. Ich habe das optimiert und verbessert, was meiner Ansicht nach wichtig war. Ich habe also meine getroffenen Annahmen ohne Überprüfung umgesetzt.

Doch das ist nicht Zielführend. Mit der Zeit lernte ich meine Ideen und Annahmen als Wireframe und dann mittels interaktivem Prototyp meinen Nutzer zu präsentieren.

Ein Design-Protoyp meiner App, welcher durch Verlinkung einzelner Viszualisierungen einen ersten Eindruck vermittelt.

Interaktive Prototypen haben mir geholfen schneller Feedback einzuholen, ohne bereits eine funktionierende Software schreiben zu müssen.

Dadurch konnte ich viele Konzepte schneller validieren oder verwerfen und musste nicht mühselig Features entwickeln, welche am Schluss keiner nutzt und früher oder später aus der App verschwinden.

Aber ich hatte tausend Ideen…

Ideen-Pool: Der Backlog und dessen Steuerung

Nach jeder Demo der App oder von einem meiner Prototypen erhielt ich hundert weitere Ideen und Verbesserungsvorschläge. Diese Informationsflut musste ich kontrollieren lernen und katalogisieren damit klare Prioritäten für den nächsten Release entstehen können.

In der agilen Entwicklung werden diese sogenannten „User Stories“ in einem Backlog geführt und können in weitere Subtasks untergeordnet werde

Durch die Erstellung von „Features“, also klar lieferbaren Software-Elemente und das klare definieren von Zielen gibt man in diesem unstrukturierten Haufen an Ideen Ordnung. So erstellte ich dann weitere Versionen mit leichten Anpassungen.

Screendesign des „Sprüche-Feature“ mit vielen User Experience Optimierungen basierend auf Feedback, erhalten durch die aktive Nachverfolgung und Erstellung einer User Journey.

Wie kann eine solche User Story aussehen? Ich habe beispielsweise mehrfach das Feedback erhalten, dass die Sprüche ja eine tolle Idee sind, aber diese einfach nicht auffindbar sind…

In der V 1.2 habe ich dann das Feature „Spruch-Zufallsgenerator“ visuell direkt auf den Startscreen gehoben, eine Suchfunktionalität hinzugefügt und durch anpassbare Kategorien mit Bilder direkt einzelne Themen hervorgehoben.

Diese kleine, lediglich visuelle Anpassung hat das User Experience enorm optimiert. Jetzt hörte ich plötzlich: „Wow genial, kannst du eine Kategorie Flachwitze hinzufügen?“

Fokus setzen und Prozesse optimieren

Das schönste an einer eigenen App ist für mich zu sehen, wie Nutzer damit interagieren. Noch heute bin ich stolz, wenn ich mein App Icon auf dem Home Screen von jemand anderem sehe.

Seit dem initialen Launch der App hat sich einfach alles weiterentwickelt!

Heute gibt es einige „geniale Feature“, welche lediglich durch meinen Annahmen so genial sind und eigentlich keine Sau braucht…

Analysedaten sowie Nutzerfeedbacks halfen mir jeweils „richtig“ zu entscheiden.

Meine Nutzerzahlen und die Feedbacks sprechen für sich. Von der Idee einer „Party-App“ ist heute nicht mehr so viel übrig. Das Feature „Sprüche“ macht Fillup Party wirklich aus und das bestätigen auch die Suchanfragen.

Doch für eine Skalierung müsste ein neues Gesamtkonzept her. Verwerfen oder behalten, das ist nun die Frage. Ich habe mich entschieden:

Danke Fillup Party, du warst ein toller Corona-Begleiter!

Für mich ist erstmals Schluss mit weiteren Updates. Die letzen Jahre haben mich persönlich sehr viel weiter gebracht. Dank meiner ersten App und dem Versprechen zu stetigem Lernen steht viel Neues an!

Es wird noch so einiges kommen!