Leitfaden für technisch nicht versierte Bauherren

Entscheiden Sie, was Ihre erste App beweisen muss.

Verwandeln Sie eine allgemeine Idee in ein kurzes, testbares Briefing, bevor Sie nach Bildschirmen und Funktionen fragen.

01 – Beschreiben Sie eine Person und eine Aufgabe

Angenommen, Sie helfen einer Gemeindegruppe bei der Organisation von Freiwilligenschichten. Eine nützliche erste Frage könnte sein, ob ein Freiwilliger eine geeignete Schicht finden und verstehen kann, wie er Interesse bekundet. Das ist kleiner und einfacher zu überprüfen als ein vollständiges Planungssystem mit Erinnerungen, Berechtigungen und Gehaltsabrechnung.

  • Beschreiben Sie, was die Person heute tut und was schwierig ist.
  • Wählen Sie die Aktion aus, die Sie klarer oder einfacher machen möchten.
  • Schreiben Sie auf, was Sie beobachten würden, wenn die erste Version funktionieren würde.

02 – Gehen Sie die Reise auf Papier durch

Skizzieren Sie für das Freiwilligenbeispiel eine Schichtliste, Schichtdetails und ein Interessenformular. Geben Sie jedem Bildschirm einen Job. Verwenden Sie einige realistische Beispielschichten, einschließlich einer vollständigen Schicht oder einer leeren Liste, damit die Überprüfung mehr als nur einen ausgefeilten, glücklichen Weg abdeckt.

  • Benennen Sie den Startbildschirm und die nächste Aktion.
  • Listen Sie die Felder auf, die für diesen Test erforderlich sind.
  • Schließen Sie einen leeren Status und einen fehlgeschlagenen Aktionsstatus ein.
  • Halten Sie echte persönliche Informationen aus explorativen Aufforderungen und Beispielen fern.

03 – Trennen Sie eine Demo von einem Betriebsdienst

Entscheiden Sie, ob diese Version nur die Reise demonstriert oder eine tatsächliche Anfrage speichern muss. Eine Demo kann eine deutlich gekennzeichnete Beispielbestätigung zeigen. Ein Betriebsdienst benötigt ein Ziel, einen geeigneten Zugriff und eine Möglichkeit, die Anforderung abzurufen. Bestätigen Sie diese Anforderungen, bevor Sie echte Teilnehmer einladen.

  • Markieren Sie jede Nur-Beispiel-Aktion im Briefing.
  • Listen Sie Verbindungen, Berechtigungen und Veröffentlichungsanforderungen separat auf.
  • Bewahren Sie Konten, Zahlungen und Mahnungen für später auf, es sei denn, der erste Test hängt davon ab.
  • Bitten Sie um qualifizierte Hilfe, wenn es sich bei der Aufgabe um vertrauliche Informationen oder komplexe Zugriffe handelt.

04 – Vergleichen Sie das Ergebnis mit dem Brief

Verwenden Sie das Arbeitsblatt unten und folgen Sie dann der Produktaufforderungsanleitung, um daraus eine Build-Anfrage zu machen. Gehen Sie nach jeder Generation dieselbe Reise durch und notieren Sie, was passiert ist. Im Beispiel des Freiwilligen könnte eine erfolgreiche Demo bedeuten, dass ein neuer Besucher die richtige Schicht finden und den nächsten Schritt verstehen kann, ohne dass Sie eine Erklärung dafür benötigen.

  • Bitten Sie jemanden, der mit der Idee nicht vertraut ist, die Aufgabe auszuprobieren.
  • Zeichnen Sie verwirrende Schritte auf, bevor Sie weitere Funktionen anfordern.
  • Nehmen Sie eine gezielte Änderung vor und wiederholen Sie die gleiche Prüfung.
  • Erweitern Sie den Umfang nur, wenn die erste Reise Ihre ursprüngliche Frage beantwortet.

Ein Ausgangspunkt

Formulieren Sie das Briefing konkret.

Passen Sie dieses Beispiel an Ihr Unternehmen an. Halten Sie Beispieldaten getrennt von echten Kundeninformationen.

Scope-Arbeitsblatt der ersten Version Person, die es verwendet: ___ Problem, mit dem sie heute konfrontiert sind: ___ Eine Aufgabe, die sie erledigen sollten: ___ Für diese Aufgabe benötigte Seiten: ___ Angezeigte oder eingegebene Informationen: ___ Was nach der Hauptaktion passiert: ___ Was nur als Beispiel übrig bleibt: ___ Für später verbleibende Funktionen: ___ Die erste Version ist erfolgreich, wenn ich Folgendes beobachten kann: ___

Wenn Sie den nächsten Schritt brauchen

Befolgen Sie die Produktdokumentation.

Bevor Sie beginnen.

Muss ich zuerst eine Programmiersprache auswählen?

Beginnen Sie mit dem Benutzer, der Aufgabe, den Informationen und dem beobachtbaren Ergebnis. Wenn ein bestehendes System oder eine technische Einschränkung die Sprache oder Plattform bestimmt, nehmen Sie dies in das Briefing auf und bestätigen Sie es mit der für dieses System verantwortlichen Person.

Wie viele Funktionen sollte eine erste Version enthalten?

Verwenden Sie das kleinste Set, mit dem Sie eine komplette Fahrt inspizieren können. Es gibt keine universelle Funktionsanzahl. Ein Feature gehört in die erste Version, wenn die Aufgabe ohne es nicht sinnvoll getestet werden kann.

Beginnen Sie mit einer nützlichen Aufgabe

Machen Sie etwas, das Sie bewerten können.