Bessere Dokumentation und Teamkommunikation mit Produktdesign-Dokumenten

Der typische Arbeitsablauf als Produktdesigner in einem Unternehmen oder Startup dürfte Ihnen bekannt sein: Ein neues Produkt wird entwickelt, für das eine Designlösung bereitgestellt werden soll. Dann arbeitest du an einigen Designvorschlägen und stellst sie vor 1–3 Personen vor, um Feedback zu erhalten.

Manchmal funktioniert dieser Prozess gut, aber manchmal nicht. Zum Beispiel sind einige Leute damit beschäftigt, ihre eigenen Aufgaben zu erledigen, und nehmen sich nicht genug Zeit, um klares und prägnantes Feedback zu Ihrem Designvorschlag zu geben.

Es kann auch vorkommen, dass Sie, obwohl Ihr Prozess gut ist, den Prozess dennoch formalisieren möchten, indem Sie Entscheidungen aufschreiben, Iterationen und den Designprozess im Allgemeinen verfolgen, insbesondere in den aktuellen Zeiten, in denen wir aufgrund von COVID19 aus der Ferne arbeiten.

Die Dokumentation des Prozesses hat viele Vorteile. Zum Beispiel macht es Ihre Arbeit sichtbarer, schafft Möglichkeiten, Feedback von viel mehr Menschen zu erhalten, verbessert die allgemeine Kommunikation und liefert ein klares Bild davon, wie ein Feature mit all dem Kontext und den Überlegungen dazu entworfen wurde.

Der Fall des Heldendesigners

Um 2018 herum arbeitete ich als Remote-Produktdesigner von Madrid aus in einem Unternehmen, das in Lateinamerika tätig ist, und bezog in diesen Prozess andere Teams aus Mexiko und Sao Paulo, Brasilien, ein.

Bevor ich bei diesem Unternehmen zu arbeiten begann, sammelte ich viele verschiedene Erfahrungen in meiner Karriere in kleinen und großen Umgebungen aus vielen verschiedenen Branchen wie Nachrichtenmedien, Designstudios, einem sozialen Netzwerk, einem mobilen Betriebssystem und gründete ein Startup für E-Lebensmittel , und hatte sogar einige freiberufliche Auftritte mit anderen kleinen Startups.

In diesen Jahren verfolgte ich den gleichen Ansatz, Sie lassen einige Leute im selben Raum sitzen, stellen Ihre Lösung vor, stellen einige Bildschirme und Flows bereit, erhalten Feedback und präsentieren sie erneut. Nach einigen Iterationen ist Ihre Arbeit bereit, die Entwicklungsphase zu erreichen.

Dieser Ansatz funktionierte jedoch nicht mehr. Kurz nachdem ich dem Team beigetreten war, wurde mir klar, dass es nicht ausreichte, meine Designs nur in einem Videoanruf vorzustellen. Ich habe viele Vorschläge erstellt, aber ich konnte keine endgültige Zustimmung von meinen Stakeholdern und Teamkollegen erreichen. Ich war verwirrt und fragte mich immer wieder: Was war los? Entwarf ich nicht die bestmögliche Lösung? Habe ich nicht qualitativ hochwertige Arbeit geliefert? Jede dieser Fragen ließ mich das Vertrauen in mich selbst verlieren. Das Problem war, dass ich meinen Prozess an diese Umgebung anpassen musste.

Sobald ich merkte, dass mein Prozess nicht funktionierte, fing ich an, viele Artikel darüber zu lesen, wie man als Designer aus der Ferne arbeitet, den Möweneffekt (wenn jemand in deine Arbeit kommt, sie scharf kritisiert und dann davonfliegt), wie Andere Unternehmen näherten sich der Remote-Zusammenarbeit und wie sie ihren Prozess formalisierten, indem sie ihn aufschrieben. Nachdem ich all dieses Material gelesen hatte, fragte ich mich, wie Entwickler mit demselben Problem konfrontiert waren. Wie arbeiten sie nahezu asynchron in entfernten Umgebungen zusammen? Wie kommen sie zu endgültigen Vereinbarungen? Ich habe festgestellt, dass die Entwickler-Community tatsächlich bereits einen Prozess hat, der für sie ziemlich gut funktioniert: Er wird Pull-Requests genannt.

Mit Pull-Requests können Sie Änderungen in eine größere Codebasis einführen, indem Sie sie dokumentieren und Ihre Entscheidungen mit dem Feedback anderer Personen validieren. Auf diese Weise mischen sich die von Ihnen eingeführten Änderungen perfekt mit allen Standards und Verbindungen, die der Code bereits enthält. Das ist genau das, was ich erreichen wollte, aber natürlich in einem Design-Fashion-Ansatz. Lassen Sie mich Ihnen das Product Design Doc vorstellen.

Das Produktdesign-Dokument

Ein Product Design Doc (PDD) ist ein Dokument, das die Probleme, die Sie lösen möchten, den Kontext und die endgültige Lösung in einen iterativen oder stufenbasierten Ansatz umwandelt.

Das bedeutet, dass Sie Ihren gesamten Designprozess in einem einzigen Dokument dokumentieren können, das mit jedem in Ihrem Unternehmen geteilt werden kann und als Wissensbasis für Ihre Produktentscheidungen dient. Klingt cool, oder? Lassen Sie uns in die Details eintauchen.

Gesamtkonzepte

Ein PDD kann in 4 Hauptkonzepten beschrieben werden: Metadaten, Kontext, Phasen und Feedback .

• Metadaten sind nur nützliche Informationen über das Dokument wie Titel, Datum, Status usw.

  

• Kontext ist das, was andere Leute lesen müssen, um die von Ihnen gemachten Designvorschläge zu verstehen, denken Sie darüber wie die Beschreibung, das Problem, die Zusammenfassung oder die Ziele dessen, was Sie erreichen müssen.

• Phasen sind die verschiedenen Iterationen Ihres Designs, die sich üblicherweise auf die umfassendere Lösung konzentrieren und sich in jeder Phase auf spezifischere Details konzentrieren. Jede Phase baut auf der vorherigen auf und geht auf das erhaltene Feedback ein. Dies ist ein strukturierter Weg, um einen Endpunkt zu erreichen, an dem gelöste Probleme nicht erneut auftreten können.

• Feedback bezieht sich auf alle Meinungen, Kommentare, Anfragen und Empfehlungen, die Sie von anderen Personen erhalten. Sie können Feedback von Ihren Stakeholdern oder Teammitgliedern einholen.

Mit diesen vier Konzepten können Sie verschiedene PDD-Varianten für Ihre Bedürfnisse erstellen, jedes Unternehmen/Projekt ist anders und was für mich funktioniert hat, muss nicht auf die gleiche Weise für Sie funktionieren. Aber wenn Sie diese 4 Hauptkonzepte in Ihrem PDD abdecken, wird es wahrscheinlich in fast jeder Situation funktionieren.

Beispielstruktur

Nachdem ich die Hauptkonzepte verstanden habe, werde ich Ihnen die Struktur mitteilen, die ich während meiner Zeit in diesem Unternehmen verwendet habe. Es hat die folgenden Abschnitte:

• Der Titel sollte prägnant, klar und leicht von anderen PDD-Titeln zu unterscheiden sein, die Sie bereits haben.
• Der Status zeigt an, in welchem ​​Stadium sich Ihr Dokument gerade befindet:
• Entwurf
  Arbeite immer noch daran, den Kontext zu definieren. Nicht bereit für Feedback.
• S30, S60, S90
  Die verschiedenen Phasen (30 %, 60 %, 90 %) Ihrer Lösung (mehr Details zu den Phasen später).
• Vollständig
  Alle Rückmeldungen wurden berücksichtigt und es gibt keine fehlenden Punkte. Das PDD ist fertig.
• Die Zusammenfassung ist die Beschreibung des Problems, für das Sie entwerfen müssen, und enthält häufig Links zu anderen hilfreichen verwandten Lektüren, die Sie möglicherweise haben.
• Ziele sind die wichtigsten Punkte, auf die sich Ihre Lösung konzentrieren muss. Dies ist eine Checkliste, die Sie ständig überprüfen, um sicherzustellen, dass Sie auf dem richtigen Weg sind.
• S30 (oder Stufe 30% ) ist der erste Vorschlag, den Sie auf der Grundlage der Zusammenfassung und der Ziele machen, wobei Sie sich auf die umfassendere Lösung statt auf die Details konzentrieren, möglicherweise durch Bereitstellung eines Low-Fidelity-Drahtmodells oder einer ähnlichen Technik. Dies ist die Phase, in der die vorgeschlagene Lösung einen völlig anderen Ansatz verfolgen könnte und ein großes Feedback erwartet wird.
• S60 (oder Stufe 60 % ) ist Ihre Lösung bei 60 % der Vollständigkeit und wendet das Feedback von S30 an. Es hat weniger Details als S90, zeigt aber deutlich die Absicht Ihrer Lösung. Sie stellen ein High-Fidelity-Drahtmodell mit mehr beteiligten Fällen und einigen Flussdefinitionen bereit. Möglicherweise erhalten Sie eine Art Feedback, das sich hauptsächlich auf verpasste Fälle und kleine unerwartete Szenarien konzentriert.
• S90 (oder Stufe 90 % ) ist die Stufe, die die Lösung zu 90 % vollständig hat und das Feedback von S60 anwendet. Diese Phase konzentriert sich auf die feinsten Details Ihres Designs, einschließlich aller verschiedenen Szenarien, Eckfälle, visuelles Design und sogar Prototypen. Es wird erwartet, dass es eine Art geringfügiges Feedback gibt.

Sie fragen sich vielleicht, muss ich die gleiche Reihenfolge und Benennungskonvention befolgen? Nun, nein, tust du nicht. Sie können die Phase von S30, S60 und S90 umbenennen in nur: Exploration, Proposal, Solution.

Sie können auch die Reihenfolge ändern, sodass die ausgefeilteste Arbeit (S90, Lösung) an den Anfang des Dokuments kommt und der Lesefluss von der letzten Phase zur frühen (S30, Exploration) geht.

Vorlagen

Beginnen Sie schnell mit einer der bereitgestellten Vorlagen für die gängigsten Schreibplattformen. Denken Sie daran: Die Namenskonventionen der Abschnitte sind vollständig anpassbar. Wenn Sie Abstract nicht mögen, verwenden Sie einfach Brief , About oder irgendetwas, das Ihren Anforderungen entspricht. Das Hauptkonzept, das Sie beibehalten müssen, besteht darin, verschiedene Iterationen zu erstellen, um sich auf jede Phase zu konzentrieren. Sie können einfach S30 nach Exploration, S60 nach Vorschlag und S90 nach Lösung umbenennen.

• Papier
• Vorstellung
• Google Dokumente
• Beispiel aus dem wirklichen Leben

Hauptvorteile der Verwendung von PDD

1. Jede Entscheidung wird dokumentiert.
   Das bedeutet, dass selbst wenn Sie Ihr Unternehmen/Projekt verlassen (und das wird früher oder später passieren), das gesamte Wissen, das um Sie herum generiert wird, für immer im Unternehmen bleiben wird, sodass andere Leute es sich ansehen und an der Stelle weiterarbeiten können, an der Sie es verlassen haben.

2. Verbessert die Kommunikation.
   Wenn Sie verschiedene Personen aus Ihrem Team auf dem PDD dazu bringen, Feedback zu geben, hilft es allen, auf dem gleichen Stand zu bleiben und sich der getroffenen Entscheidungen bewusst zu sein.

3. Begrenzt endlose Änderungen von Stakeholdern.
   Jede Phase konzentriert sich auf einen anderen Blickwinkel des Problems und geht von weiter gefassten Lösungen zu engeren. Dies ermöglicht es den Mitarbeitern, sich jeweils auf ein einzelnes Problem zu konzentrieren, was ihnen in der Abschlussphase hilft.

4. Das Produkt wird kollaborativ erstellt.
   Anstatt dass die Stakeholder spezifische Lösungen definieren, lassen wir Engineering-, Design- und andere Teams sich mit der Lösung beschäftigen und werden zu einem Teil davon.

Schlussbemerkungen

Um die Geschichte über dieses abgelegene Unternehmen abzuschließen, durfte ich dort noch einige Monate arbeiten und konnte die Produktdesign-Dokumentation in mindestens 5 verschiedenen Projekten implementieren. Meine Frustration wurde stark reduziert und ich konnte einen Konsens über meine Designvorschläge erzielen, sodass sich das Produkt weiterentwickelte. Seitdem ist das Unternehmen stark gewachsen und ein Teil der Arbeit, die ich während meiner Zeit geleistet habe, wird immer noch verwendet.

PS: Ich habe 2019 mit dem Schreiben dieses Artikels begonnen, dann sah ich 2021, dass Abstract ein Produkt zur Dokumentation des Designprozesses erstellte, also beschloss ich, wieder auf die Spur zu kommen und es fertigzustellen. Sieht so aus, als wäre es immer noch ein ziemlich relevantes Thema.

Literaturverzeichnis

• Wie man Designübungen in einem Remote-Team durchführt von Hannah Hearth
• Vermeiden Sie den Möweneffekt: Das 30/60/90-Framework für Feedback von Lauren Moon
• Wie entwirft man ein Designdokument? von John Saito
• Die Macht des Designdokuments von Brendan Fagan
• Wir stellen Notizbücher von Matt Colyer vor