Meine goldenen Regeln, um sicherzustellen, dass Ihr Produkt richtig versendet wird.
Der Produktmanager wird oft als „Brücke zwischen Business, Design und Tech“ bezeichnet. Die Brücke „zwischen Design und Technik“ ist besonders wichtig, wenn es um den Versand eines Qualitätsprodukts geht: fehlerfrei, pixelgenau und unter Berücksichtigung aller möglichen Szenarien und Randfälle. Um sicherzustellen, dass bridge gut funktioniert, gibt es verschiedene Möglichkeiten, wie das Designteam damit umgeht:
- Der Designer liefert einen umfassenden Prototyp aus, der alle Abläufe des Produkts zeigt. Leider wird dies oft viel Zeit in Anspruch nehmen und immer noch einige Randfälle vermissen.
- Der Designer wird nur einen Prototyp ausliefern, der die Hauptfunktionen des Features zeigt und für Fragen des Entwicklungsteams zur Verfügung steht. Leider sind diese Hin- und Herbewegungen sehr ineffizient (insbesondere in einem Remote-Setup) und verschwenden viel Zeit sowohl für das Design- als auch für das Entwicklungsteam.
- Der Designer schreibt zusätzlich zum umfassenden Prototyp ein korrektes Spezifikationsdokument, das alle möglichen Szenarien und Randfälle auflistet. Das Problem ist, dass es oft Zeitverschwendung ist, weil (1) die kostbare Zeit der Designer besser damit verbracht wird, andere Funktionen zu entwerfen, kein Spezifikationsdokument zu schreiben, und (2) sie nicht immer die gleiche 360 ° -Ansicht des Produkts haben wie Produktmanager, was dazu führt, dass sie einige Szenarien und Randfälle übersehen.
Deshalb vertrauen ausgereifte Produktteams in der Regel Produktmanagern das Schreiben ihrer Produktspezifikationen an.
Aber wie sollten Sie Produktspezifikationen schreiben? Ich habe in den letzten 5 Jahren Produktspezifikationen geschrieben und ein Format gefunden, das von den Softwareteams, mit denen ich zusammenarbeite, sehr geschätzt wird. In diesem Beitrag teile ich mehr über meine Methodik und die Tools, mit denen ich Produktspezifikationen schreibe. Ich beschreibe auch einige Einschränkungen, mit denen ich bei den von mir verwendeten Tools konfrontiert bin, und einige Verbesserungsideen, die ich im Sinn habe.
Hier sind die 5 Hauptthemen, die ich in einer Produktspezifikation anspreche:
- Kontext und Ziele
- Architecture map
- Epics und User Stories
- Akzeptanzkriterien
- Design, Inhalt und Übersetzungen
Kontext und Ziele
Auch wenn sich die Produktspezifikation hauptsächlich an Softwareteams richtet, möchten sie dennoch wissen, warum sie an dem arbeiten, woran sie arbeiten. Ich habe verstanden, dass einer der Hauptmotivationstreiber für Softwareentwickler die Wirkung ist. Die meisten von ihnen träumen davon, an Funktionen zu arbeiten, die von Millionen von Benutzern verwendet werden. Sie sind begeistert, wenn sie hören, dass die neue UX, die sie implementiert haben, die Kundenbindung beispielsweise um 15% erhöht hat. Daher ist es wichtig, den Kontext für die Funktion anzugeben, die sie implementieren werden:
- Worüber sprechen wir? Welcher Teil des Produkts? Fühlen Sie sich frei, jede Geschichte der Funktion hinzuzufügen, die nützlich ist, um die aktuelle Situation zu verstehen.
- Was ist das aktuelle Problem? Hinweis: Es können mehrere probleme zu lösen.
- Gibt es qualitatives Feedback / Wörtliches von Benutzern, das zitiert werden soll?
- Sollen Daten (z. B. Grafiken) angezeigt werden? In diesem Abschnitt können Sie Diagramme oder Grafiken einfügen, die die Daten verständlicher machen.
- Was ist die gewählte Lösung? (beschreibe es einfach in ein paar Sätzen)
- Wurde eine andere Lösung in Betracht gezogen? Wenn ja, warum wurde es beiseite gelegt?
- Wurde bereits eine andere Lösung implementiert? Wie hat es funktioniert?
- Was sind die Ziele ? Gibt es einen KPI, den wir beeinflussen wollen? Dies hilft insbesondere dem Softwareteam zu verstehen, ob neue Tracker / Tags / Ereignisse implementiert werden müssen, um die Daten ordnungsgemäß zu sammeln. Ich habe Teams gesehen, die sich von dem Projekt so angetrieben fühlten, dass sie die Initiative ergriffen haben, Dashboards einzurichten, um Metriken in Echtzeit zu verfolgen, ohne dass ich oder jemand anderes danach gefragt hat.
Architecture map
Bevor Sie zu sehr auf die Details der Funktion eingehen, ist es wichtig, einen allgemeinen Überblick darüber zu geben, was sich in Ihrem Produkt ändert und was gleich bleibt. Und selbst wenn Sie an einem völlig neuen Produkt arbeiten, ist eine Architekturkarte immer noch äußerst relevant, um zu verstehen, wie das Produkt strukturiert ist.
„Architecture Map“ nenne ich eine übergeordnete Diagrammdarstellung der Produktfunktionen (Flows, Bildschirme und Inhalte) und ihrer Beziehung zueinander. Einige Leute nennen es „Informationsarchitektur“, „Flusskarte“, „UX-Mapping“ usw.
Es gibt keine offizielle Methode zum Zeichnen einer Architekturkarte. In einer mobilen Anwendung versuche ich normalerweise, Flows, Bildschirme und „Teile eines Bildschirms“ (oder „In-Page-Content“) zu unterscheiden, indem ich für jeden von ihnen eine andere Form verwende, wie in der obigen Legende beschrieben.
Es kann auch hilfreich sein, mit dem Farbcode zu spielen. Im obigen Beispiel habe ich 3 Farben und auch eine durchgezogene vs. gepunktete Linie verwendet, um zu erklären, wie die aktuelle Informationsarchitektur mit der UX-Überarbeitung der Anwendung, an der wir arbeiteten, aktualisiert wird. (grün: bleibt wie es ist, orange: wird aktualisiert, rot: wird gelöscht; solide: bleibt an der gleichen Stelle, gepunktet: wird an einen anderen Ort verschoben). Auf diese Weise hatten die Ingenieure eine klare Vogelperspektive darauf, welcher Teil der Anwendung Änderungen unterliegen würde.
Ein weiterer Tipp, um eine verständliche Architekturkarte zu erstellen, besteht darin, die verschiedenen Teile der Navigation klar zu unterscheiden, wie unten mit separaten Bereichen für jeden von ihnen.
Eine Architekturkarte ist für Ihre Produktspezifikation äußerst nützlich; auf diese Weise können Sie in jeder Ihrer User Stories hervorheben, über welchen Teil des Produkts Sie sprechen.
Welches Werkzeug sollten Sie verwenden, um eine Architekturkarte zu zeichnen? Es gibt Unmengen davon, mein Favorit ist Whimsical (weil es optisch angenehm und sehr unkompliziert ist, nicht mit so vielen Funktionen überladen), aber ich habe auch verwendet Draw.io in der Vergangenheit – das ist interessant, weil es mit Google Drive integriert ist, so dass, wenn Sie mit Google Slides und Google Docs arbeiten macht es schön zu bedienen. Es ist auch in JIRA und Confluence integriert.
Wenn Sie mehr über Architekturkarten erfahren möchten (Do’s und Don’ts, welche Tools zu verwenden sind, einige Beispiele usw.), hat Toptal eine großartige Lektüre herausgebracht: Den umfassenden Leitfaden zur Informationsarchitektur.
Epics und User Stories
Das Aufschlüsseln und Erklären aller Teile Ihres Produkts kann sehr schnell ziemlich chaotisch werden. Schreiben von Produktspezifikationen In den letzten 5 Jahren habe ich festgestellt, dass der beste Weg, die Spezifikationen organisiert und verständlich zu halten, darin besteht, sie nach „User Stories“ aufzuschlüsseln.
Was ist eine User Story? Laut Agile Modeling ist eine User Story „eine sehr hochrangige Definition einer Anforderung, die gerade genug Informationen enthält, damit die Entwickler eine vernünftige Schätzung des Aufwands für die Implementierung erstellen können.“
Die Idee von User Stories besteht darin, die Benutzer an die erste Stelle zu setzen und zu vermeiden, ausschließlich obskures & technisches Vokabular zu verwenden, wenn Funktionen diskutiert werden. Wie Atlassian es ausdrückt: „Nach dem Lesen einer User Story weiß das Team, warum es baut, was es baut und welchen Wert es schafft.“
Sie zielen darauf ab, ein besseres Produkt zu entwickeln, bei dem der Benutzer im Mittelpunkt der Debatten steht, im Gegensatz zur guten alten Wasserfall-Produktentwicklung.
So sollte eine User Story formuliert werden:
Als < Art des Benutzers > möchte ich < ein Ziel > so dass < aus irgendeinem Grund >.
So könnten wir beispielsweise User Stories für den folgenden Teil der Architekturkarte formulieren, die ich für einen meiner Kunden gezeichnet habe:
- User Story #1: Als Mitarbeiter im Profilbereich möchte ich mein Profil bearbeiten, damit ich mein Foto, meinen Vor- und Nachnamen aktualisieren kann.
- Anwenderbericht #2: Als Mitarbeiter im Profilbereich möchte ich auf die Einstellungen zugreifen, damit ich mein Passwort und die Benachrichtigungseinstellungen aktualisieren kann.
- User Story #3: Als Mitarbeiter im Profilbereich möchte ich auf den Chat zugreifen, damit ich den Entwicklern der App Feedback geben kann
Es liegt am Produktmanager zu entscheiden, welche Detailebene er in der User Story abdecken möchte. Wenn wir wollten, könnten wir auch eine Ebene tiefer in die User Story #2 gehen, zum Beispiel:
- User Story #2.a: Als Mitarbeiter in den Einstellungen möchte ich auf den Abschnitt „Passwort bearbeiten“ zugreifen, damit ich mein Passwort aktualisieren kann
- User Story #2.b: Als Mitarbeiter in den Einstellungen möchte ich auf die Benachrichtigungseinstellungen zugreifen, damit ich aktualisieren kann, mit welcher Häufigkeit ich jede Art von Benachrichtigungen erhalte
Aber wie Sie sehen, ist dies etwas offensichtlich und redundant. Ich persönlich habe mich entschieden, diese Szenarien in den „Akzeptanzkriterien“ (siehe nächsten Abschnitt) der betreffenden Geschichten zu behandeln.
Um User Stories zu organisieren, verwenden wir oft „Epics“. In agilen Begriffen sind „Epics“ große Arbeitsmengen, die in kleinere User Stories zerlegt werden können. Ich persönlich verwende Epics, um Geschichten zu gruppieren, die Teil desselben Themas oder Bereichs im Produkt sind. Zum Beispiel habe ich beschlossen, die Geschichten oben als Teil des „Profil“ -Epos zu gruppieren. Einige Leute formulieren Epics auf die gleiche Weise wie User Stories, mit einer einfacheren Struktur (z. „Als Benutzer möchte ich auf mein Profil zugreifen“)
Akzeptanzkriterien
Um sicherzustellen, dass einer User Story genügend Details hinzugefügt werden, verwenden wir „Akzeptanzkriterien“ (manchmal auch „Bedingungen der Zufriedenheit“ genannt).
Nach LeadingAgile.com „Akzeptanzkriterien“ sind „die Bedingungen, die ein Softwareprodukt erfüllen muss, um von einem Benutzer, Kunden oder im Falle einer Funktionalität auf Systemebene vom konsumierenden System akzeptiert zu werden.“
In den Akzeptanzkriterien sollten Sie alle funktionalen Besonderheiten auflisten, die in der User Story nicht eindeutig festgelegt sind. Beispiel:
User Story
Als Mitarbeiter im Profilbereich möchte ich mein Profil bearbeiten, damit ich mein Foto, meinen Vor- und Nachnamen aktualisieren kann.
Akzeptanzkriterien
- Da ich mich auf dem Bildschirm Profil bearbeiten befinde, wenn ich auf das Symbol Vornamen bearbeiten klicke, sollte es in den Bearbeitungsmodus wechseln, sich auf die Eingabe konzentrieren und die Tastatur öffnen (dasselbe gilt für den Nachnamen)
- Da ich mich auf dem Bildschirm Profil bearbeiten befinde, wenn ich auf das Symbol Foto bearbeiten klicke, sollte es mich auffordern, zwischen Kamera und Bibliothek zu wählen
- Da ich meinen Vornamen bearbeite, wenn ich auf „Speichern“ klicke, sollte es mich in den Lesemodus umleiten und Ich sollte eine Erfolgsbenachrichtigung sehen
etc…
Stellen Sie sich die Akzeptanzkriterien als checkliste, die für den Versand des Produkts ausgefüllt werden muss. Das oben verwendete Format Given / When /Then ist eine gute Möglichkeit, Ihre Akzeptanzkriterien zu formulieren, aber in einigen Fällen kann die Verwendung schwierig sein.
Design, Inhalt und Übersetzungen
Aktuelle Designs in Ihren Produktspezifikationen haben
Bisher habe ich nicht erwähnt, mit welchem Tool ich Spezifikationen schreibe. In der Vergangenheit habe ich zwischen Google Docs, Google Slides und Notion gewechselt. Ich habe es wirklich genossen, Notion für all die coolen Integrationen zu verwenden, die es bietet (besonders die mit InVision und Figma). Aber ich bin jetzt komplett auf Google Docs umgestiegen: Ich bevorzuge mehr Freiheit bei der Formatierung meiner Produktspezifikationen. Es ist auch bequemer, Google-Produkte zu verwenden, wenn Sie mit externen Partnern oder Kunden zusammenarbeiten.
Um sicherzustellen, dass die visuelle Identität Ihres Produkts vom Entwicklungsteam genau zum Leben erweckt wird, ist es wichtig, ihnen Zugriff auf die aktuellsten Bildschirme zu gewähren, die von Ihren Designern geliefert werden. Da es jedoch keine echte Integration zwischen Google Text & Tabellen und Designtools wie Figma, InVision oder Zeplin gibt, habe ich Bildschirme exportiert und in meine Produktspezifikationen kopiert / eingefügt.
Dies würde sehr schnell zu einem Problem werden: Designer iterieren täglich auf ihren Bildschirmen, und selbst wenn auf einem Bildschirm alles vereinbart wurde, kann sich dies einige Wochen später ändern, da eine bestimmte Komponente in der Designbibliothek aktualisiert wird. Dies würde dazu führen, dass meine Spezifikationen die meiste Zeit veraltet sind.
Deshalb verwende ich heute nur den Namen der Bildschirme. Wenn es sich bei einer User Story zur Profiledition beispielsweise um 2 Bildschirme handelt, die auf Figma entworfen wurden, schreibe ich nur „Figma-Bildschirmname: edit-profile-1 und edit-profile-2“.
Natürlich ist dies nicht ideal und zwingt Entwickler oder andere, die meine Spezifikationen lesen, zwischen mehreren Tools zu wechseln.
Aber das zeigt, dass es heute etwas Ineffizientes in der Art gibt, wie wir Produktspezifikationen schreiben. Die Verwendung mehrerer Produkte wirft die Fragen der Integration und Synchronisierung auf. Wie kann sichergestellt werden, dass alle für die Erstellung eines Produkts erforderlichen Informationen an einem einzigen Ort sichtbar sind, ohne veraltet zu sein? (Eigentlich gilt dies nicht nur für Designs, sondern auch für Architekturkarten und Inhalte).
→ Wenn Sie dieses Problem ebenfalls haben und eine Lösung gefunden haben, würde ich mich über Ihr Feedback freuen!
Einfacher Zugriff auf Inhalte und Übersetzungen, um Tippfehler zu vermeiden
Wenn Sie Bildschirme mit einer großen Menge an Inhalten entwerfen, ist es schön, Entwicklern die Möglichkeit zu geben, sie einfach zu kopieren / einzufügen, anstatt sie selbst neu eingeben zu müssen. Andernfalls könnten Sie (1) viele Tippfehler und (2) verärgerte Entwickler haben. Es gibt verschiedene Möglichkeiten, wie Sie ihnen Zugriff auf den Inhalt gewähren können:
- Indem Sie ihnen Zugriff auf die Quelldateien der Entwurfsarbeiten gewähren, z. B. auf Sketch, Figma oder Zeplin.
- Durch Kopieren / Einfügen des Inhalts direkt in die Spezifikation (es kann es ein bisschen chaotisch machen).
Wenn Ihr Produkt in mehreren Sprachen vorhanden ist, geben Sie auch Zugriff auf jede Übersetzung. Sie können beispielsweise ein Array verwenden, um die Übersetzung Ihres Originalinhalts in jeder Sprache anzuzeigen. Die nächste Stufe des Übersetzungsmanagements besteht darin, ein Lokalisierungstool (wie Phrase) zu verwenden und nur die „Übersetzungsschlüssel“ in Ihrer Produktspezifikation hinzuzufügen. Aber auch dies bedeutet ein weiteres Hin und Her zwischen Ihren Produktspezifikationen und einem anderen Tool.