LCP LCP LCP

Der zeitlos skalierbare Designprozess Teil 5

Der zeitlos skalierbare Designprozess Teil 5
share-article-arrow-image

Im letzten Blogbeitrag habe ich die historische Entwicklung von Designprozessen sowie andere Referenzen nachgezeichnet, die zu den zeitlosen Grundlagen und den Quellen des Timeless Scalable Design Process beitragen.

Die Reise begann mit frühen Designpionieren wie László Moholy-Nagy am Bauhaus und setzte sich mit der Annäherung zweier beruflicher Strömungen fort: HCI und Design konvergierten und schufen eine neue Disziplin und neue Prozesse. Durch die Synthese all dieser Erkenntnisse aus fast einem Jahrhundert Designtheorie und -praxis kam ich auf den Prozess, den wir in den Blogs 1-3 behandelt haben. Am Ende dieses Beitrags habe ich auch die Ressourcen und das Quellenmaterial für vieles, was Sie in diesen Blogbeiträgen finden, genannt.

Teil 5: Der Prozess in Aktion

Nach einem umfassenden Überblick über die historische Designtheorie in meinem vorherigen Beitrag wenden wir uns nun der Designpraxis zu.

„Stellen Sie sich den Designprozess so vor, dass zunächst Alternativen entwickelt und diese dann anhand einer ganzen Reihe von Anforderungen und Einschränkungen getestet werden.“ - Herbert Simon

 

Verwaltung eines Designprozesses: Phasennamen

Zuerst konzentrieren wir uns auf ein Beispiel, wie dieser Designprozess in einem typischen Projekt verwaltet wird. Der Fokus liegt hier darauf, den Designprozess für Nicht-Designer zu entmystifizieren und der Design-Community eine Best Practice im Design zu bieten.

Das erste, was ich ansprechen wollte, sind die Namenskonventionen der einzelnen Schritte. Es ist wichtig, die allgemeine Funktion der Phasen des Designprozesses zu verstehen. Zu diesem Zweck gibt es Bezeichnungen für jeden Schritt, die ihr Bestes tun, um zu beschreiben, was während dieser Phasen passiert:

  • Entdecken — das Designproblem erkunden und definieren
  • Konzept — das Konzept und die Lösung für das Designproblem definieren
  • Detail — ein detailliertes Design aus dem konzeptionellen Design erstellen
  • Liefern — Assets iterativ mit Ingenieuren und anderen Stakeholdern erstellen und liefern.

Diese Bezeichnungen sollen so genau wie möglich sein. Und ich habe sehr hart daran gearbeitet, diese verallgemeinerbaren Titel in fast jeder Situation gut zu machen. Im Allgemeinen jedoch, wann immer jemand (oder eine Gruppe) versucht, etwas universell anwendbar zu machen, endet es unweigerlich mit etwas sehr Persönlichem. Daher ist es wichtig, Designern die Möglichkeit zu geben, diese Phasennamen an die Gruppe anzupassen, mit der sie gestalten.

 

Ein paar Begriffe, bevor Sie gehen

Für die Zwecke dieses Artikels und insbesondere für ein vereinbartes Vokabular zur Diskussion der Phasen gelten die folgenden Definitionen. Diese sind nicht semantisch reine Definitionen, sondern eine Erklärung, wie ich die Wörter verwende und Ihnen erlaube, sie in Begriffe Ihres eigenen Verständnisses zu übersetzen.

Ziele — ein universelles Ziel für eine Phase in einem Projekt (z. B. „das Problem neu formulieren“ während Entdecken und „konzeptionelles Design“ während Konzept).

Ergebnis — das Dokument oder Designartefakt oder anderweitig ein Substantiv, das eines oder mehrere der Ziele adressieren wird (z. B. eine Problemstellung in Entdecken oder ein Prototyp in Konzept).

Aktivität — die Methode oder Technik oder anderweitig ein Verb, das eines oder mehrere der Ergebnisse adressieren wird (z. B. kann eine Aktion eine einfache Tat wie ein Gespräch mit einem Produktmanager sein).

Methode — ein Mini-Prozess, bei dem Techniken und Ergebnisse kombiniert werden, z. B. ist szenariobasiertes Design eine Forschungsmethode zur Bereitstellung von Endbenutzeranforderungen.

Technik — Eine Designaktivität generisch oder spezifisch. Z. B. ein Usability-Test vs. ein formativer Usability-Test. Ein generischer Begriff würde für einen Nicht-Designer mehr bedeuten als der spezifische. Ebenso gibt ein spezialisierterer Begriff einem Designer mehr Richtung, was er tun wird.

 

Phasen-Namenskonventionen

Der einfachste Weg ist, einfach die hier besprochenen Namen zu verwenden, weil sie aus den oben beschriebenen Gründen funktionieren; nicht weil diese Namen perfekt sind, sondern weil sie da sind und eine Diskussion darüber, wie man diese Phasen nennt, leicht in einen Glaubenskrieg ausarten kann, der aus einem unentwirrbaren Mix aus Semantik, Geschmäckern und Vorlieben besteht. Die Wahrheit des einen ist die Fiktion des anderen. Dasselbe gilt, wenn man die Schritte im Prozess benennt.

Aber wenn Sie entschlossen sind, diese Büchse der Pandora zu öffnen und sich auf eigene Faust für Ihre benutzerdefinierten Namen zu entscheiden, dann lassen Sie uns damit beginnen, einige sehr gültige Gründe anzuerkennen, diesen Sturm zu wagen.

Es gibt gute Gründe, sich andere Namen für die Phasen auszudenken. Zum Beispiel könnte es sein, dass der Name einer der Phasen in einem bestimmten Unternehmen oder einer bestimmten Domäne eine völlig andere Bedeutung hat. Zum Beispiel war es in den 60er Jahren üblich, dass Designer eine detaillierte Phase als „Programmierungsphase“ bezeichneten. Da Design jetzt im Kontext von Software stattfindet, ist dieser Begriff unangemessen und irreführend.

Andere Gründe können sein: Sprecher- und Zuhörerfaktoren können ebenfalls eine Rolle spielen, da die beabsichtigte Bedeutung und die interpretierte Bedeutung je nach individuellem Wissen, Erfahrungen und Annahmen unterschiedlich sein können. Pragmatische Einflüsse müssen möglicherweise ebenfalls berücksichtigt werden, z. B. hängt die Bedeutung von etwas oft stark davon ab, warum es gesagt wird, nicht nur vom wörtlichen semantischen Inhalt. Kulturelle Stolpersteine und gemeinsames Verständnis oder andere Begriffe können Gründe sein, die Namen zu ändern, ebenso wie die seltsame Chance, dass jemand einen Elternteil wie eine Designer-Version von Frank Zappa hatte und sein Kind „Konzept“ nannte, das jetzt der leitende Entwickler im Projekt ist.

Aber bevor man in eine ausführliche Diskussion über Namenskonventionen einsteigt, wenn es um Bezeichnungen geht, würde ich einem meinungsstarken, aber aufrichtigen Stakeholder lieber einen Gefallen tun und die Namen ändern, solange dies die Ziele der Phase nicht ändert. Die Ziele in diesen Phasen bilden das Rückgrat des Designs, nicht wie man sie nennt. Diese Ziele in verschiedenen Aktivitäten zu erreichen, kann den Prozess biegen (oder was ich Skalierung nenne), aber ein Ziel ganz zu ignorieren, lässt den Prozess aus der Sicht eines Designers brechen.

Es ist auch wichtig zu beachten, dass, wenn Sie einen Begriff ändern, dies die Bedeutung und das Verständnis der anderen beeinflussen kann. Folglich sollten Sie bei der Änderung von Namen Begriffe verwenden, die zusammen als Familie oder Konzept funktionieren. Hier sind einige alternative Namen, die, zum Besseren oder Schlechteren, von anderen Designagenturen, Designern und Experten verwendet wurden (die Namen wurden entfernt, um andere Menschen wie mich zu schützen):

 

Benennung
Figur 1: Benennung

 

Und diese Liste könnte weitergehen. Sie können auch alle möglichen vollkommen gültigen Werturteile treffen, wenn eines der oben genannten Sets besser oder schlechter ist; denn es gibt keine wahre Semantik. Eine Semantik hängt von einer gemeinsamen Referenzbasis ab. Mit anderen Worten, es gibt keine wahre Benennung – nur eine wahre Übereinkunft über die Benennung. Es muss auch gesagt werden, dass solange eine einzige gemeinsame Basisreferenz die Designrationalität für alle Namen der Phasen ist, die resultierenden Namen sowohl verständlich als auch konzeptionell einheitlich sein sollten. Mit anderen Worten, Semantik ist die Kunst, das Willkürliche unvermeidlich erscheinen zu lassen.

Oder um Lewis Carroll aus „Alice hinter den Spiegeln“ zu zitieren, mit Humpty Dumpty, der für ein ganzes Designteam spricht:

„Wenn ich ein Wort benutze“, sagte Humpty Dumpty in einem ziemlich verächtlichen Ton, „bedeutet es genau das, was ich wähle – nicht mehr und nicht weniger.“ „Die Frage ist“, sagte Alice, „ob man Wörter so viele verschiedene Dinge bedeuten lassen kann.“ „Die Frage ist“, sagte Humpty Dumpty, „wer der Meister ist – das ist alles.“

 

Erweiterung/Teilung der Phasen

Die Schritte sind so konzipiert, dass sie nacheinander folgen. Zum Beispiel kann niemand die Konzeptphase beginnen, ohne das Problem zu kennen, das sie lösen, wie in den vorherigen Phasen festgelegt. Ebenso kann man kein detailliertes Design ohne ein Konzept erstellen, es sei denn, man mag Geschmacksstreitigkeiten und ineffektive Software. Um klar zu sein, das Umordnen der Schritte ergibt keinen Sinn und wird für professionelle Ergebnisse nicht empfohlen (für ein Beispiel, wie ein solches Projekt aussieht, siehe diesen lehrreichen Buster Keaton Film: https://youtu.be/Xd6ddOlbKp8?feature=shared).

Dennoch stellt sich die Frage nach der Erweiterung oder Teilung der Schritte.

 

Erweiterung der Phasen

Mit der Erweiterung der Phasen meine ich das Hinzufügen von Nicht-Design-Aktivitäten und -Zielen zum Projekt. Dies hilft, einheitliche Projektpläne zu erstellen und abhängige Aktivitäten zu koordinieren. Beim Hinzufügen von Zielen sollten diese klar getrennt werden – Designziele vs. Ingenieurwesen vs. Marketing – um die Arbeit jedes Teams zu klären, ohne konkurrierende Prioritäten zu schaffen. Dieser Ansatz macht Designprioritäten für andere Stakeholder klar und hilft, wenn Nicht-Designer Ideen vorschlagen, die bereits in Designzielen abgedeckt sind, aber andere Terminologie verwenden. Es koordiniert auch die Designbemühungen mit der Arbeit anderer Stakeholder, informiert das Designteam und eliminiert doppelte Anstrengungen.

Eine Sache, auf die man achten sollte, auch wenn dies nicht oft vorkommt, ist, wenn man in einer feindlichen Umgebung entwirft (z.B. wenn ein Stakeholder gegen die Nutzung von Design ist und es ihnen aufgezwungen wird), könnten einige Personen mit weniger ehrenhaften Absichten versuchen, Ziele zu planen, um Ihre eigenen zu ersetzen. Es ist wichtig, die Ziele nicht zu verhandeln. Die Werkzeuge oder Methoden können aus verschiedenen validen Gründen verhandelt werden, aber nicht die Ziele; sie bleiben immer der Schlüssel zu gutem Design.

 

Teilung der Phasen

Mit oder ohne Hinzufügen von Zielen ist es möglich, die Schritte in eine beliebige Anzahl von Unterkategorien zu unterteilen. Sechs- oder Sieben-Schritt-Prozesse sind üblich. Bruce Archer zum Beispiel hat seinen akademischen Designprozess in 239 Schritte unterteilt.

Es ist alles eine Frage der kleinsten Anzahl von Phasen, die erforderlich sind. Angenommen, es wird eine große formale Forschungsanstrengung geben, die zwischen den Phasen 1 und 2 beginnt und endet. Und diese Phase muss isoliert von den anderen verwaltet werden. Dann wäre das ein überzeugender Grund, einen zusätzlichen Schritt hinzuzufügen, um diesen Schritt allein einzuschließen. Im Allgemeinen sind 4-9 Schritte wahrscheinlich groß genug, um selbst die komplexesten Projekte zu bewältigen. Der wichtigste Faktor ist, dass die Integrität von Entdecken - Konzept - Entwickeln - Liefern intakt bleibt. Mit anderen Worten, die Ziele und ihre Abhängigkeiten von den vorherigen Schritten werden beibehalten. Zurück zu unserem Beispiel der Forschungsanstrengung könnte die Projektbenennung so aussehen:

Entdecken - Forschungsanstrengung - Definieren - Entwickeln - Liefern

Aber aus der 4-Schritt-Perspektive ist es:

Entdecken - Definieren 1 (Forschungsanstrengung) - Definieren 2 (Andere Definieren-Phasenziele) - Entwickeln - Liefern

Bei der Teilung einer Phase ist es wichtig sicherzustellen, dass voneinander abhängige Aktivitäten dem richtigen Teilungsabschnitt der Phase hinzugefügt werden. Mit diesem Wissen ist die Teilung der Schritte durchaus möglich, aber ob sie notwendig ist oder nicht, hängt vom Projekt oder der Methode ab.

 

Verwaltung des Designprozesses

Die Verwaltung des Prozesses ist entscheidend für ein gutes Design. Lassen Sie uns klarstellen, dass dies nicht das Designmanagement ist, sondern das Prozessmanagement, das völlig anders ist. Ich beziehe mich hier rein auf die Verwaltung der Designaktivitäten und -ergebnisse, die einen kleinen, aber wesentlichen Teil des Designmanagements ausmachen. Die Verwaltung des Prozesses muss die iterative Natur des Designs unterstützen, mit anderen Worten die Fähigkeit, Ihre Schritte basierend auf neuen Erkenntnissen zu überdenken oder sogar zurückzuverfolgen.

Diese Prozessverwaltung macht den Designprozess auch explizit und transparent, weniger undurchsichtig für die Nicht-Designer. Diese Prozessverwaltung sollte auch Prozessabkürzungen unterstützen: wie der Prozess sich biegen kann, ohne zu brechen. Ein Beispiel für eine Prozessabkürzung wäre die Reduzierung der Forschungsanstrengungen auf etwas, das weniger Zeit in Anspruch nimmt, aufgrund einer neuen Zeitbeschränkung. Aber indem man die Änderungen oder Opfer in Aktivitäten oder Ergebnissen im Designprozess explizit macht, kann man auch das erhöhte Risiko klarstellen, das mit einer Projektänderung während des Fluges einhergeht.

Um den Designprozess zu verwalten, empfehle ich eine Struktur, die am einfachsten in einer Tabellenstruktur ausgedrückt wird. Eine Tabellenstruktur, die mit dem Projekt in mehrere parallele Funktionen wachsen kann, während es durch verschiedene Iterationen geht:

  1. Designprojekt-Referenz für Kunden und internes Team Projektdesign
  2. Tool Projektvorschlags
  3. Tool Design
  4. Lern-Tool
  5. Projektverfolgungs-Tool
  6. Design- und Projekt-Referenz

Bevor ich auf die Details jeder Version dieses Tools eingehe, möchte ich darauf hinweisen, dass ich eine Tabellenversion zeige, um die Gesamtstruktur klar zu machen, ohne auf eine Erklärung von Datenbankstrukturen und anderen technischen Elementen zurückzugreifen. Diese Tabelle kann leicht in Apples Numbers, Excel oder anderen Tabellenkalkulationen implementiert werden. Aber sie ist noch leistungsfähiger, wenn sie einige Datenbankfunktionen dahinter hat und/oder in eine bestehende Designinfrastruktur wie Miro, Jira, Slack, GitHub usw. integriert ist.

 

Designprojekt-Referenz

Auf der einfachsten Ebene beginnt die Tabelle als Tabelle mit einer Spalte für jede Phase und einer Liste von Zielen für jede Phase. Dieses Dokument allein ist eine großartige Möglichkeit, sowohl ein Team als auch einen Kunden darauf vorzubereiten, was im Designprozess zu erwarten ist. Die Diskussion über hochrangige Ziele ist auch eine Gelegenheit für Stakeholder, zusätzliche Ziele hinzuzufügen, die für dieses spezielle Projekt wesentlich sind.

UX Projekt Plan
Figur 2: Ein UX Projekt Plan

 

Das Dokument dient auch als Gesprächspunkt speziell für einen Kunden, als eine Art Design-Grundrechte: etwas, das ein Kunde oder Teamleiter nutzen kann, um das Design zur Erreichung aller notwendigen Projektziele zur Verantwortung zu ziehen.

 

Projekt-Design-Tool

Eine weitere Iteration dieses Projekts ist, wenn Sie jeder Phase eine Liste von Aktivitäten und Ergebnissen hinzufügen. Der Projektplan kann geleitet werden, indem ein Ergebnis mit einem Ziel verknüpft wird. Diese Verbindung bestimmt, in welcher Phase ein Ergebnis fällig ist. Ebenso, wenn Sie Aktivitäten mit einem Ergebnis verknüpfen, kann die ausgewählte Aktivität ebenfalls ein Fälligkeitsdatum am Ende der Phase haben. Mit der Verwendung von verknüpften Listen oder einer Datenbank ist es möglich, die Liste der Aktivitäten basierend auf den ausgewählten Ergebnissen zu filtern, was dem Designer hilft, die richtigen Aktivitäten für ein Ergebnis auszuwählen, aber auch Aktivitäten auszuwählen, die er nicht in Betracht gezogen hat oder vielleicht nicht kannte. Eine verknüpfte Liste kann eine Anzahl von Tagen oder Ressourcenstunden an die ausgewählten Aktivitäten anhängen. Die Gesamtaktivitäten in einer Phase können Ihnen eine Dauer und eine grobe Schätzung des Projekts geben. Dies kann den Designer bei der Erstellung eines Budgets und Umfangs für das Projekt leiten, das die Grundlage für einen Projektplan sein kann.

 

Projektvorschlag-Tool

Sobald ein Designer seinen Designprozess abgeschlossen hat, kann er den Aktivitäten ein Startdatum hinzufügen. Sie können damit beginnen, ein Startdatum festzulegen (ein bestimmtes Datum oder ein „Woche 0“-Start) und dann ein Startdatum für die erste Aktivität zu erstellen, normalerweise ein Projekt-Kick-off, und dann den Start der nächsten Aktivität basierend auf der Dauer der vorherigen Aktivität festzulegen. Dies generiert nicht automatisch einen Projektplan, da ein Designer analysieren und entscheiden möchte, ob eine Aktivität die vorgeschlagene Länge benötigt oder ob der Kontext des Plans weniger oder mehr Zeit erfordert. Zum Beispiel kann ein Kick-off-Meeting in vielen Fällen ein 2-stündiges Meeting sein, aber bei wirklich komplexen Problemen könnte es einen halben Tag dauern oder sogar mit anderen Aktivitäten kombiniert werden, wie einem Produktinnovations-Workshop. Ein weiteres Beispiel ist die Zeit, die benötigt wird, um Benutzer für einen Usability-Test zu planen. Wenn das Designteam bereit Zugang zu Benutzern hat, wie bei einem internen Benutzerteam, kann die Planung Tage dauern; andererseits, für Benutzer, die geografisch verstreut und schwer zu kontaktieren sind, könnte der Rekrutierungsprozess Wochen dauern. Die Analyse dieser Variablen hilft dem Designer dann, die richtige Zeitmenge abzuschätzen. Darüber hinaus kann ein Designer auch entscheiden, einer Aktivität eine gewisse Pufferzeit hinzuzufügen, um mögliche Verzögerungen zu berücksichtigen – besonders wichtig für einen festen Projektzeitplan.

Sobald diese Bestimmungen abgeschlossen sind, ist das Ergebnis ein Projektvorschlag, der mit einigen Stakeholdern neu verhandelt und dann kalkuliert und den entscheidungsbefugten Stakeholdern präsentiert oder gesendet werden kann.

 

Design-Lern-Tool

Wie bereits erwähnt, kann ein Designer mit einer Liste von Aktivitäten neue Designmethoden und -aktivitäten entdecken. Dies ist besonders hilfreich, wenn es eine Verbindung zu den Phasenzielen und den Aktivitäten/Ergebnissen gibt; aber nicht notwendig, besonders für den erfahreneren Designer, der diese Dinge bereits aus dem Kopf kennt.

Allerdings kennt kein Designer, selbst diejenigen mit über dreißig Jahren Erfahrung, alles. Es kann Designaktivitäten geben, die effektiver sind als die, die er kennt.

Eine Liste von Aktivitäten, die jeder im Team kennt, kann einem Designer helfen, neue Methoden zu erkunden und zu lernen. Ebenso könnte ein Designer oder eine Design-Operations-Person eine Verbindung zu neuen und interessanten Aktivitäten oder Ergebnissen pflegen, sodass der Designer auch neue Methoden oder Techniken erkunden kann, die er zuvor nicht ausprobiert hat. Sie können diesen Links folgen und Lernmöglichkeiten oder Beispiele für eine neue Methode erkunden.

Ein echter zusätzlicher Vorteil der Liste von Aktivitäten kann jedoch sein, wenn sie den Namen oder die Namen von Mitarbeitern enthält, die eine bestimmte Methode kennen. Diese Art von Liste oder für ein großes Unternehmen eine Datenbank ist sehr nützlich, um den Designer über die vielen verschiedenen Methoden, Techniken und Ergebnisse zu informieren, die es gibt, um dasselbe Ziel zu erreichen.

Der Designer kann den Projektkontext analysieren und die Auswahl der Methoden an den Kontext anpassen. Der wirkliche Vorteil einer solchen Datenbank besteht jedoch auch darin, neue interne Methoden oder Techniken zu entdecken, mit denen der Designer nicht vertraut ist und die ein Projektproblem lösen können, das er nicht zu lösen weiß.

Angenommen, ein Designer verlässt sich auf einen Usability-Test, um einen Prototyp zu bewerten. Aber sie haben nicht genug Zeit für einen formellen Usability-Test oder sogar einen „Guerilla“-Usability-Test.

Wenn sie nachsehen, wie dasselbe Ziel erreicht werden kann, stoßen sie möglicherweise auf die Technik einer anderen Person, die viel weniger Zeit in Anspruch nimmt und ein akzeptables Risiko birgt. Mit dem Namen der Person, die damit verbunden ist, können sie diese Person kontaktieren, die sie entweder schulen oder betreuen kann oder sogar für diese Aktivität dem Projekt hinzugefügt werden kann.

Auf diese Weise lernt das Design mehr über neue Methoden oder Ergebnisse, die sie nicht kennen, aber ein Kollege darauf spezialisiert ist.

 

Projektverfolgungs-Tool

Sobald ein Projektvorschlag akzeptiert und begonnen wird, weisen Sie feste Termine und Hauptressourcen zu, die für jede Aktivität oder jedes Ergebnis verantwortlich sind. Platzieren Sie die Daten in der Zeile mit jedem Element zusammen mit den zugewiesenen Ressourcen.

Designprojekte sind iterativ – abgeschlossene Phasen müssen manchmal erneut besucht werden, wenn Ergebnisse aufgrund neuer Informationen veraltet sind. Verfolgen Sie diese Iterationen mit Typografie: Verwenden Sie roten Text für neue Daten, wenn Arbeit erneut durchgeführt werden muss, und ändern Sie ihn dann zurück zu Grau, wenn sie abgeschlossen ist.

Verwalten Sie, ob Ergebnisse tatsächlich die erwarteten Ziele ansprechen, indem Sie Ziellisten in jede Phasenkopfzeile einfügen. Markieren Sie abgeschlossene Ziele ab und ergänzen Sie unvollständige mit unterstützenden Ergebnissen.

 

Plan Beispiel
Figur 3: Beispiel eines Planes

 

Darüber hinaus können dank der allgegenwärtigen Verlinkungsmöglichkeiten, die in fast jedem Tool verfügbar sind, Liefergegenstände und Aktivitätsartefakte leicht verknüpft werden, was es einfach macht, den Überblick über Projektliefergegenstände zu behalten.

Projekt Deliverables werden normalerweise in ein allgemein zugängliches Cloud-Speicherverzeichnis hochgeladen. Aber durch die Verknüpfung dieser Liefergegenstände und Aktivitäten muss man nicht wissen, wo die Datei aufbewahrt wird; sie haben über dieses Dokument mit einem Klick Zugriff darauf.

Der Liefergegenstandslink könnte den Benutzer direkt zum Liefergegenstand führen und ihn öffnen. Ein Aktivitätslink oder Liefergegenstandslink, bei dem es mehrere Artefakte gibt, kann den Benutzer direkt zu dem Verzeichnis mit allen für eine Aktivität benötigten Dokumenten führen, z. B. dem Testskript für den Test sowie Sitzungsprotokollen, Videos usw.

Fast alle diese kollaborativen Dokumente haben einige einfache rollenbasierte Einschränkungen, sodass einige Benutzer nur Lesezugriff auf das Dokument haben können, sodass sie Links anklicken, aber das Projekt-Tracking nicht ändern können. Darüber hinaus können Nicht-Editoren beim Betrachten des Dokuments den aktuellen Status des Projekts auf einen Blick sehen und dem Projektmanager von allen Updates berichten, die sie verpasst haben: zum Beispiel eine gerade abgeschlossene Aktivität zu einem abgelehnten Liefergegenstand.

 

Design- und Projektreferenz

Nach Projektabschluss lässt sich überprüfen, welche Aktivitäten oder Ergebnisse Best Practices sind. Es bleibt nur noch, die Ergebnisse hervorzuheben (und ggf. auch eine Kommentarfunktion zu nutzen, um zu erwähnen, was funktioniert hat und was nicht).

Sie können diese gewonnenen Erkenntnisse oder Best Practices in einem zentralen Bereich Ihrer Design-Infrastruktur zusammenfassen. Wenn Sie eine Seite für eine bestimmte Aktivität oder ein bestimmtes Ergebnis pflegen, können Sie Projektlinks als zusätzliche Beispiele hinzufügen. Beispielsweise könnte eine Seite, die sich auf Usability-Tests bezieht, das besonders effektive Testskript enthalten.

 

Blog-Benachrichtigung

Bleiben Sie mit unseren neuesten Artikeln auf dem Laufenden!

Quote_Julie_Keen_Design
Stehen Sie vor einer ähnlichen Herausforderung?

Lassen Sie uns eine Lösung finden!

Julie Pontier

Sales Consultant