Von der Idee zum Prototyp: Konzept, Proof of Concept und MVP erklärt

Um von der Idee zum Prototyp zu kommen, prüfen Sie zuerst, ob das Problem echt ist, und bauen dann das Günstigste, was Ihre riskanteste offene Frage beantwortet. Ein Konzept beantwortet „Was bauen wir, und für wen?“, ein klickbarer Prototyp (Klickdummy) „Können Menschen es bedienen?“, ein Proof of Concept „Lässt es sich bauen?“ und ein MVP „Nutzen Menschen es, und zahlen sie dafür?“. Mit Kundengesprächen in Woche eins, einem mit fünf Nutzern getesteten Klickdummy und, wo nötig, einem technischen Spike lässt sich eine klar umrissene Idee in zwei bis vier Wochen testen statt in Monaten.

#Konzept, Prototyp, Proof of Concept, MVP: welche Frage jedes beantwortet

In Pitch-Decks und Angeboten werden diese Begriffe beliebig vermischt, und so bezahlen Gründer am Ende für das Falsche. Jedes Artefakt beantwortet eine Frage, für ein anderes Publikum, mit einer anderen Lebensdauer.

Eric Ries definierte das Minimum Viable Product als die Version eines neuen Produkts, mit der ein Team mit dem geringsten Aufwand das meiste validierte Wissen über seine Kunden gewinnt. Prototyp und Proof of Concept kommen davor und sind noch günstiger. Was danach kommt, beschreibt unser Leitfaden für ein MVP, das auch in Monat neun noch funktioniert.

#Validieren Sie das Problem, bevor Sie etwas gestalten

Der teuerste Prototyp ist ein schöner für ein Problem, das niemand dringend genug hat, um sein Verhalten zu ändern.

Kundengespräche, die Sie nicht in die Irre führen

Rob Fitzpatricks The Mom Test ist hier das Standardwerk, gebaut auf einer Beobachtung: Menschen sind höflich zu Ihrer Idee. Seine drei Regeln lauten: Sprechen Sie über das Leben Ihres Gegenübers statt über Ihre Idee, fragen Sie nach konkreten Situationen aus der Vergangenheit statt nach Allgemeinem oder Meinungen über die Zukunft, und reden Sie weniger, hören Sie mehr zu.

• „Wann ist das zuletzt passiert? Erzählen Sie mir, wie es ablief.“
• „Was haben Sie dagegen getan, und was hat Sie das an Zeit oder Geld gekostet?“
• „Was haben Sie schon ausprobiert, und warum haben Sie aufgehört?“
• „Wer ist noch beteiligt, wenn das schiefgeht?“

Vermeiden Sie „Würden Sie das nutzen?“ und „Wie viel würden Sie dafür zahlen?“. Antworten auf hypothetische Fragen sind Meinungen über die Zukunft. Das ehrliche Signal liegt in dem, was Menschen bereits tun: Umwege, Excel-Listen, schon ausgegebenes Geld, und ob sie einem konkreten nächsten Schritt zustimmen, etwa einem zweiten Termin, einer Vorstellung bei einer Kollegin oder einem Pilotprojekt.

Smoke-Tests: Absicht messen, nicht Komplimente

Ein Smoke-Test zeigt Menschen das Versprechen, bevor das Produkt existiert, und misst, was sie tun. Übliche Formen sind eine Landingpage mit einer klaren Handlungsaufforderung (Warteliste, Demo buchen, vorbestellen), ein „Fake Door“-Button in einem bestehenden Produkt und ein Concierge-Test, bei dem Sie das Ergebnis für einige Kunden von Hand liefern. Legen Sie vorher fest, welches Ergebnis als Ja zählt, damit Sie sich hinterher keines einreden. Seien Sie gegenüber Besuchern ehrlich, was bereits existiert, und ergänzen Sie einen Datenschutzhinweis, wenn Sie E-Mail-Adressen sammeln.

#Den Prototyp in Tagen zuschneiden, nicht in Monaten

Ein Prototyp wird über seine Frage zugeschnitten, nicht über eine Feature-Liste. Nehmen Sie die riskanteste offene Annahme und bauen Sie nur, was sie testet. Alles andere ist Dekoration.

1. Formulieren Sie die riskanteste Annahme als Satz, der sich als falsch erweisen kann, zum Beispiel: „Praxismanagerinnen lassen Patienten Termine ohne Anruf verschieben.“
2. Ordnen Sie sie ein. Begehrtheit und Bedienbarkeit brauchen Gespräche und einen Klickdummy; Machbarkeit braucht einen technischen Spike; Wirtschaftlichkeit braucht Preisgespräche und später ein Pilotprojekt.
3. Wählen Sie einen Nutzer und einen Weg, vom Auslöser bis zum Ergebnis. Ein einziger Weg über eine Handvoll Screens reicht meist.
4. Legen Sie vor dem Start einen Zeitrahmen und einen Testtermin fest und buchen Sie die Testteilnehmer sofort, damit der Termin nicht rutscht.
5. Vereinbaren Sie, was Sie danach entscheiden: weitermachen, Richtung ändern oder aufhören.

Der Design Sprint von GV zeigt, wie weit ein fester Zeitrahmen trägt: fünf Tage von der Problemskizze bis zur Beobachtung, wie Kunden auf einen realistischen Prototyp reagieren, nach dem Grundsatz, dass für den Test mit Kunden eine realistische Fassade genügt. Sie brauchen keinen formalen Sprint, aber ein fester Testtag hält den Prototyp klein.

#UX und UI: vom User Flow zum getesteten Klickdummy

User Flows

Beginnen Sie mit dem Ablauf, nicht mit den Screens: die Schritte vom Auslöser („Ein Patiententermin wird abgesagt“) bis zum Ergebnis („Ein neuer Termin ist gebucht“), mit den Entscheidungspunkten und dem, was passiert, wenn etwas schiefgeht. Ein Flow auf einer Seite deckt fehlende und überflüssige Schritte auf, bevor jemand einen Pixel zeichnet.

Wireframes

Wireframes sind Screens in geringer Detailtiefe: Layout, Inhalte und Aktionen in grauen Kästen. Sie lassen sich schnell ändern, sogar zwischen zwei Testsitzungen, und die Nielsen Norman Group weist darauf hin, dass Prototypen in geringer Detailtiefe offensichtlich unfertig wirken und Menschen sie deshalb eher kritisieren.

Klickdummys in Figma

Für Tests mit Nutzern und für Investoren verknüpfen Sie realistische Screens zu einem Klickdummy. In Figma verbinden Sie Frames über Interaktionen zu Flows und können den Prototyp dann per Link teilen oder auf einem Gerät präsentieren. Jedes Klickziel auf dem getesteten Weg muss funktionieren, sonst bricht die Sitzung ab. Nutzen Sie realistische Inhalte im Vokabular Ihrer Kunden; Platzhaltertext verdeckt genau die Fragen, auf die es ankommt.

Usability-Tests mit fünf Nutzern

Jakob Nielsen von der Nielsen Norman Group argumentiert, dass ein qualitativer Test mit fünf Nutzern rund 85 % der Usability-Probleme findet und dass ein Budget in drei Runden mit je fünf Personen, mit Verbesserungen dazwischen, besser angelegt ist als in einer großen Studie. Zwei Einschränkungen: Bei deutlich verschiedenen Nutzergruppen, etwa Praxisteam und Patienten, testen Sie drei oder vier Personen pro Gruppe; quantitative Kennzahlen brauchen mehr als fünf.

Ein Usability-Test braucht eine Moderation, realistische Aufgaben und Teilnehmer, die Ihrem ersten Nutzer entsprechen und während der Arbeit laut denken. Formulieren Sie Aufgaben als Ziele, nicht als Anweisungen: „Sie müssen den Termin am Dienstag auf nächste Woche verschieben“, nicht „Klicken Sie auf Verschieben“. Die NN/g warnt, dass Schrittbeschreibungen versteckte Hinweise auf die Bedienung enthalten.

#Technische Spikes und KI-Machbarkeitsprüfungen

Ein Proof of Concept beantwortet die Machbarkeitsfrage, und seine schnellste Form ist ein Spike. Ward Cunningham erinnert sich, wie er Kent Beck fragte, was das Einfachste sei, das sie programmieren könnten, um sich zu überzeugen, auf dem richtigen Weg zu sein, und Beck nannte die Antwort einen Spike: einmal durch alle Schichten, aber sehr schmal. Ein Spike ist zeitlich begrenzt, eng gefasst und wird meist weggeworfen. Das Ergebnis ist die Erkenntnis, nicht der Code.

• Integrationen mit Systemen, die Sie nicht kontrollieren, etwa ein ERP, eine Praxissoftware oder eine Banking-API: Können Sie sich authentifizieren und lesen und schreiben, was Sie brauchen, innerhalb der Rate Limits und Nutzungsbedingungen?
• Geschwindigkeit und Last: Liefert die Suche, das Matching oder die Berechnung ein Ergebnis in der Zeit, die ein Nutzer tatsächlich wartet?
• Daten, die Sie voraussetzen: Sind sie verfügbar, sauber genug und rechtmäßig für diesen Zweck nutzbar?
• Gerätefunktionen: Offline-Synchronisierung, Bluetooth oder Kamera, auf echten Telefonen.

KI-Machbarkeit: das Modell an Ihren echten Fällen testen

Bei KI-Produkten ist die Demo der leichte Teil: Ein Prompt, der bei drei handverlesenen Beispielen funktioniert, sagt wenig über die echten Fälle. Eine brauchbare Prüfung:

1. Sammeln Sie echte Eingaben, auch die unordentlichen: unvollständige Formulare, die falsche Sprache, mehrdeutige Anfragen.
2. Legen Sie fest, wie eine richtige Ausgabe aussieht und welche Fehlerquote akzeptabel ist, bevor Sie etwas laufen lassen.
3. Bewerten Sie automatisch, wo es geht. Anthropics Leitfaden zum Aufbau von Evaluationen empfiehlt, die reale Verteilung der Aufgaben samt Grenzfällen abzubilden, und zieht viele automatisch bewertete Testfälle wenigen von Hand bewerteten vor.
4. Messen Sie Kosten und Antwortzeit pro Anfrage bei dem Volumen, das Sie erwarten, nicht nur die Genauigkeit.
5. Prüfen Sie, wohin die Daten gehen: welcher Anbieter, welche Region, unter welchem Vertrag. Unser Leitfaden zu DSGVO-konformem KI-Hosting zeigt die Optionen.

Bevor ein Modell angebunden ist, testet ein „Wizard of Oz“-Prototyp, bei dem ein Mensch hinter der Oberfläche die Antworten liefert, das Erlebnis selbst; die Nielsen Norman Group nennt ihn für KI-Funktionen, bevor die KI gebaut ist. So trennen Sie zwei Fragen: Wollen Nutzer diese Antwort, und kann ein Modell sie zuverlässig liefern?

#Was Sie Investoren und Pilotkunden zeigen

Jedes Publikum stellt eine andere Frage, also zeigen Sie jedem andere Belege.

Sagen Sie klar, was echt ist. Ein Klickdummy, der als fertige Software präsentiert wird, ist der schnellste Weg, eine erfahrene Investorin oder die IT-Abteilung eines Pilotkunden zu verlieren.

Halten Sie jedes Pilotprojekt auf einer Seite fest: Ziel, Erfolgskriterien, Dauer, wer was tut und was passiert, wenn es funktioniert. Ein Pilot ohne Erfolgskriterien endet meist mit einem höflichen „interessant“ statt mit einem Vertrag.

#Prototyp wegwerfen oder weiterentwickeln?

Entscheiden Sie das vor dem Bau, denn es bestimmt, wie der Prototyp gebaut wird. Die Faustregel: Design-Prototypen und Spikes werden weggeworfen, ein MVP bleibt. Gefährlich ist das Dazwischen, ein programmierter Prototyp, der unbemerkt zum Produkt wird.

Martin Fowler nennt bewusst wegwerfbaren Code Sacrificial Architecture und erinnert daran, dass eBay 1995 als Sammlung von Perl-Skripten begann, an einem Wochenende gebaut. Code wegzuwerfen ist in Ordnung, wenn das der Plan war; das Problem ist Code, der nie zum Behalten gebaut wurde und trotzdem bleibt.

Wenn Sie ihn weiterentwickeln, prüfen Sie den Code und bringen Sie zuerst die teuren Fundamente in Ordnung: Datenmodell, Konten und Rollen, Zahlungen und Hosting-Region, wie es der Leitfaden zum Monat-neun-Problem beschreibt.

#Ein Plan für zwei bis vier Wochen, von der Idee zum getesteten Prototyp

Der Plan setzt eine Idee, einen ersten Nutzer und ein kleines, erfahrenes Team voraus. Für Begehrtheit und Bedienbarkeit reichen oft zwei Wochen; planen Sie vier, wenn zusätzlich eine Integration oder ein KI-Modell bewiesen werden muss.

Das Ergebnis dieses Plans ist eine belegte Entscheidung, keine Software. Lautet sie „weitermachen“, folgt die erste Version, gebaut auf Fundamenten, die bleiben.

#Kosten und die Fallstricke, die sie erhöhen

Ein Prototyp kostet vor allem Arbeitszeit, also folgen die Kosten dem Umfang: Zahl der Nutzergruppen und Flows, Wireframes oder Gestaltung auf Markenniveau, und ob eine technische oder KI-Machbarkeitsprüfung nötig ist. Eine Richtwert-Spanne für Ihre eigene Idee liefert unsere kostenlose Schätzung; sie ist eine Schätzung, kein Angebot.

• Prototypen vor der Validierung. Ein polierter Prototyp für ein unbestätigtes Problem ist eine sehr teure Umfrage.
• Meinungen sammeln statt Verhalten beobachten. „Das würde ich auf jeden Fall nutzen“ ist kein Beleg; ein gebuchtes Pilotprojekt schon.
• Zu viel Detailtiefe zu früh. Gestaltung auf Markenniveau, bevor der Ablauf steht, macht jede Änderung langsamer und jede Kritik höflicher.
• Eine Demo, die den schwierigen Teil versteckt. Wenn die KI oder die Integration nur simuliert ist, sagen Sie es und testen Sie sie getrennt.
• Ein Prototyp, der aus Versehen zum Produkt wird. Entscheiden Sie vorab, ob er weggeworfen oder weiterentwickelt wird.
• Werte auf fremden Namen. Designdateien, Testaufzeichnungen, Domains und Repositories gehören vom ersten Tag an Ihrem Unternehmen.

#Wie wir Sie unterstützen

Bespoke IT begleitet Gründer vom Konzept bis zur ersten Version: Produktarbeit, um die riskanteste Annahme zu finden und zu testen, UX- und UI-Design vom User Flow bis zum Klickdummy, erprobt mit echten Nutzern, Architektur und technische Spikes für den schwierigen Teil und die Entwicklung der Version, die bleibt. Unsere Zusammenarbeit mit Startups beginnt mit einem Discovery-Sprint, und unsere Seite zu Web- und Mobile-Apps zeigt Konzepte unseres Designteams neben Produkten, die wir ausgeliefert haben.

Über unseren Partner Salford Ventures GmbH in Düsseldorf erhalten Gründer zudem Unterstützung bei der Finanzierung: bei der Strategie, beim Finanzplan, bei der Vorbereitung der Unterlagen, die Investoren verlangen, und mit einer Liste von Investoren, die Sie ansprechen können. Sehen Sie, wie wir mit Startups arbeiten, lassen Sie sich eine Richtwert-Spanne für Ihren Prototyp geben oder sprechen Sie uns an.