Zum Inhalt springen
Leitfaden6 Min. Lesezeit

Review-Rundgang für eine Bubble-App

Zeigen Sie dem Prüfer den Ablauf, der beweist, dass der Build dem Briefing entspricht.

Geben Sie dem Prüfer eines Bubble-Projekts einen aufgezeichneten Ablauf, der beweist, dass der Build dem Briefing entspricht, statt eines Statusupdates.

Ansehen, wie es funktioniertDie ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um es herunterzuladen.

Ein Review-Rundgang für eine Bubble-App existiert, um eine Frage zu beantworten, die ein Kunde oder Projektverantwortlicher immer wieder stellt, ohne sie laut auszusprechen: Wurde das, worum ich gebeten habe, tatsächlich gebaut. Schriftliche Statusupdates beantworten das schlecht. Sie beschreiben Absicht, nicht Ergebnis, und ein Prüfer, der liest, "der Rechnungsworkflow ist fertig", hat keine Möglichkeit zu erkennen, ob das bedeutet, dass er korrekt auslöst, oder ob jemand den Satz einfach hoffnungsvoll getippt hat. Ein aufgezeichneter Ablauf des tatsächlich laufenden Workflows beseitigt diese Unklarheit, denn entweder erzeugt der Klick auf die Schaltfläche das versprochene Ergebnis auf dem Bildschirm, oder er tut es nicht.

GogoScreen erstellt das aus einer Webanwendungs-URL und einem einzeiligen Hinweis, der den aufzunehmenden Ablauf beschreibt. Es liefert ein erzähltes MP4, meist in etwa zwei Minuten, mit einer Bearbeitung, die tote Luft entfernt, den Cursor glättet, bei Klicks heranzoomt und Untertitel einbrennt. Für einen Workflow, der erst sichtbar wird, wenn jemand eingeloggt ist, kann ein Demokonto bereitgestellt werden. Bei GogoScreen werden Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Nichts davon ersetzt das Lesen des Codes oder der Workflow-Logik im Bubble-Editor. Es ersetzt, einen nicht technischen Prüfer stattdessen darum zu bitten.

Was genau sollte der Rundgang beweisen?

Beginnen Sie beim Briefing, nicht bei der App. Lesen Sie noch einmal genau nach, was der Kunde oder Manager konkret verlangt hat, sei es "Nutzer können einen Antrag einreichen und sehen, wie sich sein Status ändert" oder "ein Administrator kann ein Inserat freigeben, und es erscheint öffentlich". Der Rundgang sollte genau diesen Weg zeigen, ausgelöst so, wie es ein echter Nutzer tun würde, und beim im Briefing beschriebenen Ergebnis enden. Ein Rundgang, der zu angrenzenden Funktionen abschweift, nach denen der Prüfer nie gefragt hat, verschwendet dessen Aufmerksamkeit und kann neuen Scope in eine Prüfung bringen, die eigentlich alten Scope abschließen sollte.

Bubble-Workflows sind sichtbare Logik im Editor, eine Abfolge von Schritten, die an ein Ereignis geknüpft sind, aber ein nicht technischer Prüfer kann diese Abfolge nicht lesen und wird es auch nicht versuchen. Was er beurteilen kann, ist, ob der Klick auf die Schaltfläche die angekündigte Änderung bewirkt hat. Halten Sie den Rundgang an genau diesem einen beobachtbaren Ergebnis fest.

  1. Bestätigen Sie genau, was das Briefing verlangt hat, und wählen Sie den einen Workflow, der es beweist.
  2. Versetzen Sie die App genau in den Zustand vor dem Auslöser, damit die Aufnahme im relevanten Moment beginnt.
  3. Nehmen Sie den Rundgang auf und senden Sie ihn zusammen mit einer kurzen Notiz zu den noch offenen Punkten an den Prüfer.

Wie bereiten Sie die App vor der Aufnahme vor?

Öffnen Sie die App, entweder die Live-Version oder den Version-Test-Build, je nachdem, welche Stufe die Prüfung betrifft, und bringen Sie sie in den Zustand, der unmittelbar vor dem Auslöser liegt. Hängt der Workflow von vorhandenen Daten ab, etwa einem bereits angelegten Datensatz oder einem bereits registrierten Nutzer, bereiten Sie das vorab vor, statt auch die Einrichtungsschritte aufzunehmen. Ein Prüfer muss nicht zusehen, wie ein Konto angelegt wird, bevor er die Funktion sieht, nach der er eigentlich gefragt hat.

EinrichtungsschrittWarum er für den Rundgang wichtig istWas Sie weglassen sollten
Den genauen Wortlaut des Briefings bestätigenHält die Aufnahme an das gebunden, was angefordert wurdeFunktionen, die seit dem Briefing hinzugekommen, aber noch nicht freigegeben sind
Den Zustand vor dem Auslöser erreichenDie Aufnahme beginnt bei der relevanten AktionKontoerstellung, Onboarding, themenfremde Navigation
Live oder Version-Test wählenDer Prüfer weiß, welche Build-Stufe er freigibtBeides ohne Hinweis in einer Aufnahme mischen

Löst der Workflow nur für einen eingeloggten Nutzer aus, stellen Sie ein Demokonto über den genehmigten Prozess bereit, statt den echten Login eines Kunden weiterzugeben. Bei GogoScreen werden Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Formulieren Sie es so, falls die Frage aufkommt, denn die genaue Beschreibung ist zugleich die beruhigendere für einen Prüfer, der nachfragt.

Was sollte im einzeiligen Hinweis stehen?

Schreiben Sie den Hinweis so, wie Sie einen Kollegen briefen würden, der die App noch nie geöffnet hat. Benennen Sie den Startpunkt, die Aktion und das genaue Ergebnis, das das Briefing versprochen hat. "Genehmigen Sie in der Antragsliste den ausstehenden Antrag und zeigen Sie, wie sich sein Status auf genehmigt ändert" gibt ein präzises Ziel vor. Ein vager Hinweis wie "die Genehmigungsfunktion zeigen" lädt zu einer Aufnahme ein, die an dem einen Moment vorbeischweift, den der Prüfer eigentlich sehen muss.

Halten Sie den Wortlaut im Hinweis konsistent mit dem Wortlaut im Briefing und in der App selbst. Nennt das Briefing etwas einen Antrag und die Oberfläche der App nennt es eine Einreichung, entscheiden Sie sich für einen Begriff und verwenden Sie ihn im Hinweis, damit die Erzählung keine Unstimmigkeit einführt, über die der Prüfer erst rätseln muss.

Was geht schief, wenn der Rundgang zu breit angelegt ist?

Ein Rundgang, der versucht, den angeforderten Workflow plus drei weitere, zufällig naheliegende Dinge abzudecken, lässt den Prüfer meist unsicherer zurück, nicht sicherer. Stolpert ein sekundärer Ablauf mitten in der Aufnahme über einen Grenzfall, hat der Kunde nun eine neue offene Frage zu etwas, das er ursprünglich gar nicht prüfen wollte. Halten Sie jeden Rundgang eng gefasst, eine Anforderung, ein Ergebnis, und senden Sie für einen separaten Punkt im Briefing einen eigenen Rundgang, statt sie zusammenzulegen, um einen Renderdurchlauf zu sparen.

Etwa einer von fünf Renderdurchläufen schlägt fehl oder muss wiederholt werden, eine Tatsache, die Sie kennen sollten, bevor Sie einem Prüfer eine Lieferung noch am selben Tag versprechen. Planen Sie das im Zeitplan ein, statt den ersten Versuch als garantiert zu behandeln. Der Leitfaden zu fehlgeschlagenen Renderdurchläufen bei Demovideos behandelt, was vor einer erneuten Einreichung zu prüfen ist, wenn ein Renderdurchlauf nicht wie erwartet zurückkommt.

Wie hängt das mit dem restlichen Review- und Launch-Workflow zusammen?

Ein für die interne Prüfung gesendeter Bubble-Rundgang ist nur eine Etappe. Sobald ein Workflow genehmigt ist, muss derselbe Ablauf möglicherweise erneut für ein anderes Publikum erscheinen, und die zugrunde liegende Disziplin bleibt gleich, auch wenn sich die Plattformdetails ändern. Ein Firebase Studio Demovideo beginnt bei derselben Frage, was ein Ablauf beweist, während es im Leitfaden zum Firebase Studio Landingpage-Video um den Nachweis für einen Fremden geht statt für einen Prüfer, der das Projekt bereits kennt. Der Leitfaden zum Firebase Studio Product Hunt Launch-Video behandelt ein Publikum in einer Launch-Galerie, und der Leitfaden, ein Firebase Studio Projekt mit einem Kunden zu teilen sowie der Firebase Studio Portfolio-Demo-Leitfaden behandeln jeweils eine Version des Übergabeproblems, das diese Seite für Bubble löst.

Für einen Build, der aus einem Investorengespräch statt aus einem Kundenbriefing stammt, behandelt der Leitfaden zum KI-Agenten-Investoren-Demovideo ein verwandtes, aber eigenständiges Publikum mit anderen Erwartungen. Wurde die App selbst über einen KI-Website-Builder zusammengestellt statt von Hand im Bubble-Editor, passt der Leitfaden zum KI-Website-Builder-Demovideo besser. Sobald ein geprüfter Workflow später als Funktion ausgeliefert wird, behandeln der Leitfaden zum Feature-Launch-Demovideo und der Leitfaden zum Changelog-Video für ein SaaS die öffentliche Ankündigung, was eine andere Aufgabe ist als die private Prüfung, für die dieser Rundgang gedacht ist.

Schließen Sie den Kreis mit einer kurzen schriftlichen Notiz neben dem Video: was geprüft wurde, was bestanden hat und was noch offen ist. Das Video beweist, dass der Workflow gelaufen ist. Die Notiz ist das, was der Prüfer als Aufzeichnung der Entscheidung ablegt. Für alles andere im Workflow siehe Bubble-Alternativen zu einem geführten Bildschirmaufnahme-Tool, die Preisseite für Pläne und Aufladungen, die vollständige Leitfadenbibliothek, die Vergleichsseiten und die GogoScreen-Startseite für den URL- und Hinweis-Ablauf selbst.

Klarstellungen

Bevor Sie beginnen

Was sollte ein Review-Rundgang für eine Bubble-App beweisen?

Er sollte beweisen, dass der im Briefing angeforderte Workflow im Live-Build oder im Version-Test-Build vollständig durchläuft, vom Auslöser, den der Prüfer erwartet, bis zum Ergebnis, das ihm angekündigt wurde.

Wer ist die Zielgruppe für ein Bubble-Review-Rundgang-Video?

Meist ein Kunde, ein Projektmanager oder eine Agenturleitung, die den Bubble-Editor nicht selbst öffnen oder sich nicht selbst durch einen Version-Test-Link klicken wird. Sie müssen das Ergebnis sehen, nicht die Workflow-Logik prüfen.

Ersetzt ein Review-Rundgang ein schriftliches Statusupdate?

Nein. Er ersetzt den Teil eines Statusupdates, der sich schwer in Worten beschreiben lässt: den Moment, in dem ein Workflow tatsächlich auslöst und die App reagiert. Kombinieren Sie ihn mit einer kurzen schriftlichen Notiz darüber, was geprüft wurde und was noch offen ist.

Fügen Sie eine URL ein, beschreiben Sie einen Ablauf und erhalten Sie ein Demovideo Ihrer Webanwendung.

Die ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um das Video herunterzuladen.