App Idee testen: Nachfrage und Machbarkeit vor der Entwicklung prüfen

Wenn du deine App Idee testen willst, prüfe zuerst, ob Menschen den vorgesehenen Ablauf tatsächlich nutzen würden. Kläre außerdem, ob die kritischste technische Funktion umsetzbar ist. Dafür brauchst du noch keine fertige App, sondern einen begrenzten Test mit einer klaren Frage.

Kurz gesagt: Freundliches Interesse ist noch kein Nutzungsnachweis. Lass mögliche Nutzer einen echten Vorgang ausprobieren und prüfe technische Risiken getrennt. Lege vor dem Test fest, welches Ergebnis für die Weiterentwicklung reicht.

Was musst du vor der App-Entwicklung herausfinden?

Vor der App-Entwicklung musst du klären, welches Problem deine Zielgruppe tatsächlich hat und ob dein Vorschlag dafür taugt. Zusätzlich brauchst du einen Nachweis, dass der entscheidende technische Ablauf funktioniert.

Angenommen, du führst einen Servicebetrieb. Reparaturanfragen kommen per WhatsApp, Fotos liegen auf verschiedenen Handys. Kunden rufen an, um nach dem Bearbeitungsstand zu fragen.

Deine Idee: Kunden melden Defekte über eine App und sehen dort den aktuellen Status. Das klingt zunächst sinnvoll. Ungeklärt ist aber, ob sie dafür eine App installieren würden oder lieber beim Telefon bleiben.

Auch intern gibt es eine offene Frage: Wer pflegt den Bearbeitungsstand? Wenn deine Mitarbeiter Änderungen erst nach Feierabend eintragen, zeigt die App tagsüber veraltete Angaben. Software allein löst dieses Problem nicht.

Schreibe deshalb eine überprüfbare Annahme auf: „Unsere wiederkehrenden Auftraggeber melden Reparaturen über das Handy, wenn sie dadurch Rückfragen und Anrufe vermeiden.“ Das lässt sich testen. „Wir brauchen eine Kunden-App“ beschreibt dagegen bereits eine Lösung, ohne deren Nutzen zu belegen.

Wie prüfst du Nachfrage, ohne eine App zu bauen?

Nachfrage prüfst du zunächst durch Gespräche über echte Vorgänge. Danach lässt du Interessenten einen kleinen Teil des geplanten Ablaufs ausprobieren.

Sprich mit den Menschen, die später mit der App arbeiten sollen. Bei der Reparaturmeldung sind das die Personen, die Defekte erfassen. Wenn jemand anderes über die Anschaffung entscheidet, brauchst du auch dessen Sicht.

Frage nach dem letzten Vorgang

Zeige deine Idee nicht sofort. Lass dir zuerst erklären, wie die letzte Reparaturmeldung ablief. So erfährst du etwas über den bisherigen Ablauf, bevor dein Vorschlag die Antworten beeinflusst.

Diese Fragen helfen:

• Wie hast du den letzten Defekt gemeldet?
• Welche Angaben oder Fotos musstest du nachreichen?
• Warum hast du zuletzt nach dem Bearbeitungsstand gefragt?
• Was nutzt du bereits, um solche Vorgänge zu verwalten?
• Wer entscheidet über einen anderen Meldeweg?

Notiere konkrete Schwierigkeiten. „Die Gerätenummer fehlte und musste telefonisch nachgefragt werden“ hilft dir bei der Planung. „Die Kommunikation könnte besser sein“ ist dafür zu ungenau.

Frag auch nach Gründen gegen deine Idee. Wer nur selten eine Reparatur meldet, möchte dafür vielleicht kein Konto anlegen. Dann wäre ein Formular ohne Anmeldung möglicherweise der passendere Einstieg.

Teste eine Handlung statt einer Absicht

Biete nach dem Gespräch einen begrenzten Praxistest an. Ein Auftraggeber meldet den nächsten passenden Defekt über ein Formular. Du überträgst die Angaben zunächst von Hand in die Auftragsverwaltung.

Erkläre offen, dass du einen neuen Ablauf erprobst. Beobachte, ob das Formular genutzt wird und wo Unterstützung nötig ist. Ruft der Auftraggeber trotzdem an, frage nach dem Grund.

Soll die App verkauft werden, kläre auch den Beschaffungsweg. Wer hat das Budget? Welche Voraussetzung fehlt noch für eine Kaufentscheidung? Ein „Klingt interessant“ beantwortet diese Fragen nicht.

Bei einer kostenlosen Kunden-App liegt der wirtschaftliche Nutzen eher im Betrieb. Prüfe etwa, ob vollständigere Meldungen tatsächlich Rückfragen ersparen. Berücksichtige dabei auch die Zeit, die du für Hilfestellung und Nachbearbeitung brauchst.

App Idee testen: Welcher Test passt zu deiner Frage?

Wähle den Test nach der größten offenen Frage. Für die Bedienung brauchst du ein anderes Vorgehen als für eine unsichere Anbindung an bestehende Software.

Ein Prototyp ist ein vorläufiges Modell der geplanten Anwendung. Ein Klickmodell zeigt beispielsweise Bildschirme und Übergänge, verarbeitet aber noch keine echten Aufträge.

Ein Proof of Concept, kurz PoC, prüft die Machbarkeit einer begrenzten Annahme. Ein Minimum Viable Product, kurz MVP, ist eine erste nutzbare Version mit dem notwendigen Umfang, um eine Produktannahme zu testen. Die Gründerplattform beschreibt Machbarkeitsnachweise und MVPs als Wege, Annahmen und Nachfrage früh zu überprüfen.

Du musst diese Tests nicht alle durchführen. Beginne mit der Annahme, deren Scheitern die Idee infrage stellt. Wenn benötigte Daten möglicherweise nicht zugänglich sind, kann ein Techniktest vor dem Klickmodell sinnvoll sein.

Ist dagegen unklar, ob deine Zielgruppe überhaupt ein Problem hat, helfen weitere technische Arbeiten zunächst wenig. Dann brauchst du Gespräche und einen Test des vorgeschlagenen Ablaufs.

Wie prüfst du die technische Machbarkeit?

Lass den riskantesten Teil der App unter realistischen Bedingungen vorführen. Eine allgemeine Aussage wie „Das können wir anbinden“ reicht als Entscheidungsgrundlage nicht.

Bei der Reparatur-App könnte die Verbindung zur Auftragsverwaltung entscheidend sein. Eine Schnittstelle ist ein definierter Zugang, über den Programme Daten austauschen. Dass ein System eine Schnittstelle hat, heißt noch nicht, dass darüber alle benötigten Daten verfügbar sind.

Der Techniktest sollte einen Testauftrag abrufen und dessen Bearbeitungsstand anzeigen. Er muss außerdem zeigen, wie der Auftrag dem richtigen Kunden zugeordnet wird. Dafür brauchst du passende Zugangsrechte und geeignete Testdaten.

Prüfe auch die Fehlerfälle

Eine erfolgreiche Vorführung zeigt zunächst, dass der Ablauf unter den gewählten Bedingungen funktioniert. Für eine brauchbare Entscheidung brauchst du auch Antworten auf die naheliegenden Fehlerfälle:

• Was passiert, wenn die Auftragsverwaltung nicht erreichbar ist?
• Wie erkennt die App einen fehlenden oder unbekannten Status?
• Kann eine fehlgeschlagene Übertragung wiederholt werden, ohne doppelte Aufträge anzulegen?
• Welche Einschränkungen gibt es auf den vorgesehenen Geräten?

Lass die Ergebnisse und offenen Punkte schriftlich festhalten. Dazu gehört beispielsweise, ob die Vorführung nur mit vorbereiteten Daten funktioniert hat oder bereits gegen das vorgesehene System lief.

Prüfe dabei auch, ob eine Anwendung im Browser genügt. Wenn Kunden nur gelegentlich einen Defekt melden, solltest du eine Installation nicht ungeprüft voraussetzen. Die Unterschiede erläutert Web App oder App aus dem Store.

Wie klein darf ein MVP sein?

Ein MVP darf klein sein, muss aber einen vollständigen Vorgang ermöglichen. Sein Umfang richtet sich nach der Frage, die du mit der Nutzung beantworten willst.

Für die Reparatur-App könnte dieser Vorgang reichen: Ein Auftraggeber meldet einen Defekt mit Foto und kann später den Bearbeitungsstand abrufen. Eine Geräteverwaltung oder umfangreiche Auswertungen wären dafür zunächst nicht nötig.

Spare aber nicht an der Zuverlässigkeit dieses Weges. Wenn Fotos verschwinden oder Meldungen unbemerkt scheitern, kannst du eine geringe Nutzung schwer einordnen. Vielleicht fehlt die Nachfrage, vielleicht scheitern Interessenten nur an den Fehlern.

Manuelle Arbeit im Hintergrund kann für den Test vertretbar sein. Du könntest Meldungen selbst übertragen oder Statusangaben ergänzen. Halte diesen Aufwand fest, damit du ihn bei der Entscheidung über den späteren Betrieb berücksichtigen kannst.

Bevor du dafür eigene Software bauen lässt, prüfe vorhandene Produkte. Vielleicht bietet deine Auftragsverwaltung bereits ein passendes Kundenportal. Wann eine Eigenentwicklung trotzdem sinnvoll ist, erklärt Individualsoftware oder Standardsoftware.

Wann solltest du weiterentwickeln, ändern oder stoppen?

Entscheide anhand vorher festgelegter Beobachtungen, ob du weiterentwickelst. Interesse im Gespräch, tatsächliche Nutzung und technische Machbarkeit sind dabei unterschiedliche Nachweise.

Lege vor dem Test fest, was für deinen Betrieb ein brauchbares Ergebnis wäre. Bei der Reparatur-App könnte das heißen: Auftraggeber melden passende Vorgänge über das Formular und liefern die benötigten Angaben. Sie können den Status ohne telefonische Hilfe finden.

Erfasse auch den Unterstützungsbedarf. Musst du jeden Auftraggeber mehrfach erinnern oder die Eingaben nachbearbeiten, gehört das zum Ergebnis. Die Nutzung allein sagt dann noch wenig über die Entlastung aus.

Unterscheide fehlendes Interesse von fehlender Gelegenheit. Wenn während des Tests kein Defekt auftritt, lässt sich daraus keine Ablehnung ableiten. Wenn ein passender Vorgang entsteht und trotzdem der alte Meldeweg gewählt wird, brauchst du eine Erklärung.

Aus den Beobachtungen ergeben sich konkrete Entscheidungen:

• Weiterentwickeln, wenn der Ablauf genutzt wird und die kritische Technik funktioniert.
• Den Ansatz ändern, wenn das Problem besteht, aber der vorgesehene Weg nicht passt.
• Stoppen, wenn sich kein ausreichender Nutzen zeigt oder eine notwendige technische Voraussetzung fehlt.

Du brauchst dafür keine allgemeine Erfolgsquote. Du brauchst Kriterien, die zu deinem Betrieb passen und vor dem Test feststehen.

Was solltest du für den ersten Test beauftragen?

Beauftrage eine begrenzte Prüfaufgabe statt vorschnell die komplette App. Das Ergebnis sollte deine nächste Entscheidung ermöglichen, auch wenn diese gegen die Entwicklung ausfällt.

Beschreibe die offene Frage, die benötigten Zugänge und das erwartete Ergebnis. Halte ausdrücklich fest, welche Funktionen nicht dazugehören. Vereinbare außerdem, ob Testcode später weiterverwendet werden soll oder nur dem Nachweis dient.

Der Aufwand hängt vor allem von der Prüfaufgabe ab. Ein Klickmodell benötigt keine funktionierende Verbindung zur Auftragsverwaltung. Ein technischer PoC kann dagegen schon durch fehlende Dokumentation oder Zugangsrechte aufwendig werden.

Bei mawu halten wir Anforderungen und technische Umsetzung vor der Entwicklung schriftlich fest. Welche Angaben dafür nützlich sind, zeigt Lastenheft App: Was vor der Entwicklung hinein muss.

Schreibe als nächsten Schritt auf, welche unbelegte Annahme deine App-Idee zu Fall bringen könnte. Wähle dann den kleinsten Test, der genau diese Frage beantwortet.