Objektmodellierung für Designer: Eine Einführung

Als User Experience Designer kann es sich so anfühlen, als würde ich einen ständigen Kampf gegen die Komplexität führen, besonders wenn ich an Unternehmenssystemen arbeite.

Ein beliebter Weg zur Vereinfachung eines Erlebnisses ist die Implementierung eines Entwurfssystems. Eine Reihe von vollwertigen Design-Systemen ist im Internet verfügbar, und es bedarf keines besonderen Augenscheins, um zu sehen, welchen Einfluss diese Systeme auf das Anwendungsdesign hatten (einen Einfluss, über den ich später in diesem Artikel mehr sagen werde). .

Entwurfssysteme sind wichtig, aber ich hoffe in diesem Artikel zu zeigen, dass ein Entwurfssystem allein - insbesondere wenn es sich in erster Linie um ein Entwurfssystem auf Komponentenebene handelt - keine einfache, konsistente Erfahrung garantiert. Ich glaube das, weil ich es regelmäßig mit den Unternehmenskunden sehe, mit denen ich arbeite. Die meisten (wenn auch nicht alle) sind zu einem Entwurfssystem umgezogen. Und wenn ich mir das Ergebnis ansehe, gibt es immer noch erhebliche Inkonsistenzen zwischen den Bildschirmen, die grundsätzlich ähnlich sein sollten.

Design-Systeme verhindern auch nicht das, was ich als "Feature-Tack-On" bezeichne, bei dem neue Funktionen lediglich an das bereits Vorhandene angepasst werden. Im Laufe der Zeit kann so eine labyrinthartige Anwendungsstruktur erstellt werden. Feature-Tack-On ist besonders bei Unternehmenssystemen weit verbreitet, wo Kundenwünsche die Entwicklung hochspezialisierter Features vorantreiben können.

Wie ein Objektmodell helfen kann

Warum haben Systeme keine bewährten Systeme entwickelt? Ein Problem ist, dass Design-Systeme häufig auf Komponentenebene fokussiert sind (oder die Komponentenebene als Ausgangspunkt verwenden). Die Systeme reifen dann nicht über eine Sammlung von Komponenten hinaus.

Hier kann ein Objektmodell helfen.

Ein Objektmodell ist eine visuelle Darstellung der Objekte, Aktionen und zugehörigen Attribute eines Systems. Ein Objektmodell kann in Verbindung mit einem Entwurfssystem verwendet werden, um eine konsistente Erfahrung für die übergeordneten Konstrukte eines Systems zu schaffen.

Was genau ist ein übergeordnetes Systemkonstrukt? Diese Idee wird von Brad Frosts Atomic Design Methodology veranschaulicht, die mithilfe einer biologischen Metapher beschreibt, wie ein Design-System organisiert werden kann. Die kleinstmöglichen Systemkomponenten (z. B. eine einzelne Schaltfläche) werden als Atome betrachtet. Atome wiederum können in Molekülen angeordnet werden (z. B. eine Gruppe von Komponenten, die für die globale Suche verwendet werden). Organismen sind als übergeordnetes Konstrukt eine Gruppierung von Molekülen. Die Metapher ist nicht perfekt, vermittelt aber das allgemeine Schema.

Brad Frosts Atomic Design-Methode
Ich glaube, dass Entwurfssysteme oft Mühe haben, Systemkonstrukte auf höherer Ebene darzustellen, da nicht genügend Rahmen vorhanden sind, um herauszufinden, was dort enthalten sein sollte. Dieses Problem kann durch die Objektmodellierung gelöst werden.

Wurzeln der Objektmodellierung

Die gesamte Idee von Schnittstellenobjekten stammt aus der Entwicklung der grafischen Benutzeroberfläche (GUI). Mit einer GUI können Benutzer direkt mit auf dem Bildschirm dargestellten Objekten interagieren. Es war eine radikale Abkehr von den damals verwendeten Befehlszeilenschnittstellen. Das 1981 veröffentlichte Xerox Star-System war das erste kommerziell verfügbare System mit einer grafischen Benutzeroberfläche (GUI) - und diente als Inspiration für die Apple Lisa (1983) und später für den Apple Macintosh (1984).

Eine BefehlszeilenschnittstelleXerox Star 8010, 1981. Beachten Sie das Fenster mit der Konferenzarbeit: Sie sprechen über Objekte und Aktionen! Dies sind Schlüsselkonstrukte, die einer GUI zugrunde liegen.

In den 1990er Jahren, als Software zu wachsen begann, wurden die Entwicklungsprozesse stärker formalisiert, und es bestand das Interesse, die Softwareanforderungen konsistent darzustellen. UML (Unified Modeling Language) wurde entwickelt, um diesen Bedarf zu decken. Die UML-Diagramme, die den UX-Benutzern auch heute am wahrscheinlichsten bekannt sind, sind das Use-Case-Modell und das Klassendiagramm.

Das Use Case-Modell ist ein Verhaltensmodell, das das System aus einer Aufgabenperspektive darstellt (ähnlich den User Storys in Agile).

Ein einfaches Anwendungsfalldiagramm für ein Bankensystem.

Das Klassendiagramm ist ein Strukturmodell, das die Objekte eines Systems und die Beziehung zwischen ihnen zeigt. Jedes Objektrechteck enthält die mit dem Objekt verknüpften Aktionen (im unteren Bereich) und die Attribute (im mittleren Bereich).

Ein Beispiel für ein UML-Klassendiagramm für einen Geldautomaten.

Innerhalb der UML-abhängigen Entwicklungsprozesse wurde der Schwerpunkt auf das objektorientierte Design von Benutzeroberflächen gelegt, wobei das Klassendiagramm als Grundlage dient. In der Tat wurden in den 1990er Jahren ganze Bücher über diese Methode geschrieben.

Bücher, die objektorientiertes Interface-Design fördern. Sie können diese noch heute über Amazon erwerben.

Zwar kann ein vollständiges Klassendiagramm zeitaufwändig sein und erfordert eine Reihe von Analysefähigkeiten, die typisch für einen Ingenieur oder Analyst sind. Normalerweise bereitet sich ein UX-Profi heute nicht vor.

Ich würde jedoch argumentieren, dass Objektorientierung ein verlorener und notwendiger Bestandteil des UX-Designs ist, insbesondere für komplexere Anwendungen.

Das narrative Objektmodell

Was ich vorschlage, ist ein vereinfachtes Objektmodell, das ich Narrative Object Model - Erzählung nenne, weil es die UML-Notation im Wesentlichen durch eine rein englische Erzählung ersetzt. Auch wenn das Klassendiagramm nach den Regeln der UML stark strukturiert ist, ist das narrative Objektmodell leichter und flexibler.

Erstellen eines narrativen Objektmodells

In diesem nächsten Abschnitt werden wir den Prozess der Erstellung eines Modells durchlaufen und den Prozess in drei Schritte aufteilen:

1) Identifizieren der Objekte

2) Charakterisierung der Beziehung zwischen Objekten

3) Identifizieren der Aktionen und Attribute jedes Objekts

Ausgangsmaterialien für das Modell

Das Erstellen des Modells beginnt mit der Identifizierung der verfügbaren Quellmaterialien. Welche Arten von Artefakten haben Sie, die die beabsichtigte Funktionalität beschreiben oder anderweitig darstellen?

In meiner Beratungsarbeit beginne ich normalerweise mit einem bestehenden System, das wir neu gestalten oder in irgendeiner Weise neu planen. Das Starten des Modells durch Überprüfen der vorhandenen Schnittstelle des Systems bewirkt zwei Dinge: 1) Es macht mich mit dem System in seinem aktuellen Zustand vertraut. 2) Es stellt ein Basisobjektmodell bereit, das dann erweitert werden kann, um den gewünschten zukünftigen Zustand darzustellen.

Die andere primäre Quelle für ein Objektmodell sind User Storys oder andere anforderungsorientierte Artefakte. Für die Greenfield-Designarbeit sind dies möglicherweise die einzigen verfügbaren Quellen.

Wir beginnen ein Beispielmodell, indem wir uns eine vorhandene Schnittstelle ansehen, wobei wir das relativ einfache Beispiel von Twitter.com verwenden.

Zunächst ist es jedoch wichtig, zwei zentrale Konzepte zu definieren: ein Objekt und eine Aktion. Einfach ausgedrückt, Objekte sind die Substantive in einem System und Aktionen die Verben. In einer vorhandenen Benutzeroberfläche enthalten Menüs und Schaltflächen häufig Hinweise auf die Objekte und Aktionen eines Systems.

Bei der Arbeit mit Objekten ist es auch wichtig, sich an den Unterschied zwischen dem Objekt, das das Konzept darstellt, und einer Instanz eines Objekts zu erinnern. Zum Beispiel haben die meisten Systeme das Konzept eines Kontos, das ein Objekt wäre. Es gibt jedoch viele Fälle eines Kontos: das Konto von Louise Hughes, das Konto von Ramon Woods usw.

Objekte identifizieren

Unten ist ein Screenshot eines Tweets von Twitter.com. Wir haben eine Button-Leiste unter dem Tweet und ein Menü (erweitert dargestellt) rechts. Wir werden diese verwenden, um einige Substantive (aka Objekte) zu identifizieren.

Die Schaltflächenleiste (unten) und das Menü (rechts) können eine Quelle zum Identifizieren von Objekten sein.

Wenn ich mir die Menübeschriftungen ansehe, sehe ich, dass ein Substantiv ein Tweet ist. Wir haben zum Beispiel:

  • Link zum Tweet kopieren
  • Fixierter Tweet
  • Tweet melden
  • Ich mag diesen Tweet nicht

Zusätzliche Nomen, die ich identifizieren kann, sind:

  • Ein Konto, in diesem Fall durch den Kontonamen Fine Cooking Mag (eine Instanz des Kontos) dargestellt.
  • Ein Moment, angezeigt durch den Menüpunkt "Zu neuem Moment hinzufügen".
  • Eine Direktnachricht, die durch das Umschlagsymbol gekennzeichnet ist, dh "Direktnachricht senden"

Die markierte Bildschirmaufnahme zeigt die Objekte, die wir bisher identifiziert haben:

Objekte, die über eine Tweet-Tastenleiste und ein Menü identifiziert wurden.

In unserem Modell werden die Objekte zu Rechtecken mit Titel, die wir miteinander verbinden, um Beziehungen zu zeigen. Hier sind bisher unsere Objektrechtecke:

Eine Reihe von anfänglichen Objektrechtecken.

Wir können (und werden) definitiv mehr mit unseren Objekten tun. Wenn ich jedoch versuche, ein schlecht organisiertes System zu verstehen, reicht es zumindest anfangs aus, die Objekte zu erkennen und auf einer Seite abzulegen.

Der logischste nächste Schritt ist, sobald ich die Objekte identifiziert habe, die Beziehungen zwischen Objekten zu identifizieren.

Beziehung zwischen Objekten

Wenn Sie das UML-Klassendiagramm erneut betrachten, werden Sie feststellen, dass es ein etwas kryptisches Notationsschema für die Darstellung von Beziehungen zwischen Objekten gibt. Dieses Schema beinhaltet das Aufzeichnen der Vielheit der Beziehung und das Anzeigen von Beziehungstypen unter Verwendung verschiedener Linienende-Behandlungen.

Ein UML-Klassendiagramm verwendet verschiedene Liniennotationen, um die Beziehungen zwischen Objekten zu beschreiben.

Anstatt sich auf die Notation zu stützen, um die Beziehung zwischen Objekten zu charakterisieren, verwendet das Narrative Object Model beschreibenden Text. Das folgende Diagramm zeigt die Objekte, die wir bisher mit den beschriebenen Beziehungen identifiziert haben.

Narratives Objektmodell, das die Beziehungen zwischen Objekten beschreibt.

Die Beschreibungen helfen, den Zweck jedes Objekts im Kontext des größeren Ganzen zu beleuchten:

  • Ein Konto kann eine direkte Nachricht senden
  • Ein Konto kann Tweets veröffentlichen
  • Tweets können in Gruppen zusammengestellt werden, die Moments anrufen

Wieder können Sie Ihr Modell an diesem Punkt stoppen, nachdem die Beziehungen definiert wurden, wenn Sie der Meinung sind, dass das Modell Ihrem Zweck dient. Es kann jedoch hilfreich sein, weitere Informationen zu jedem Objekt einzugeben, insbesondere die zugehörigen Aktionen und Attribute.

Aktionen identifizieren

Als Nächstes wollen wir einige mit einem Tweet verknüpfte Aktionen identifizieren. Wir können wieder die Schaltflächenleiste und das Menü als Ausgangspunkt verwenden:

Aktionen (gelb hervorgehoben), die über eine Tweet-Tastenleiste und ein Menü identifiziert werden.

In einem Objekt werden die Aktionen im unteren Bereich des Objektrechtecks ​​aufgeführt (siehe unten).

Das Objekt Tweet mit den zugehörigen Aktionen.

Eine stilistische Anmerkung: Ich bewahre die traditionelle Notation für Aktionen in einem Objektmodell auf und füge jede Aktion mit Parens hinzu. Diese Notation ist eine Präferenz meinerseits (völlig unnötig), hilft jedoch bei der visuellen Unterscheidung von Aktionen, was bei größeren, komplexeren Objektmodellen hilfreich sein kann.

Beachten Sie auch, dass ich einige Aktionen hinzugefügt habe, die nicht in der Bildschirmaufnahme des Tweet dargestellt werden, sondern an anderer Stelle in der Benutzeroberfläche zu finden sind, z.

Wir werden jetzt schnell vorwärts gehen und davon ausgehen, dass ich wiederholt Aktionen für unsere verbleibenden Objekte identifiziert habe. So sieht das Modell an dieser Stelle aus:

Narratives Objektmodell für Twitter, das die Beziehung zwischen Objekten und den Aktionen jedes Objekts zeigt.

Attribute identifizieren

Attribute lassen sich am einfachsten als Datenfelder für jedes Objekt betrachten. Attribute kennzeichnen jede Instanz eines Objekts. Sie sind im mittleren Bereich des Objektrechtecks ​​aufgeführt, wie unten für das Tweet-Objekt gezeigt:

Das Objekt Tweet mit Attributen (mittlerer Bereich) und Aktionen (unterer Bereich).

Auch hier habe ich einige Notationen aus einem Klassendiagramm erhalten. Der Doppelpunkt hinter dem Attribut Text gibt den Datentyp an - in diesem Fall ist die Länge von Text begrenzt (280 Zeichen oder weniger). Ich habe nur den Datentyp für das Textattribut aufgenommen, weil ich es für die Benutzererfahrung als besonders wichtig erachtet habe.

Modell ausbauen

Lassen Sie uns als Nächstes unser Modell umfassender betrachten und einige zusätzliche Elemente hinzufügen.

Narrative Object Model für Twitter

Zusätzlich zum Hinzufügen weiterer Objekte habe ich einige visuelle Elemente hinzugefügt, die mir helfen, das Modell leichter zu interpretieren Diese schließen ein:

  • Angabe, welche Objekte die Kernsystemobjekte sind (fettgedruckt)
  • Verwendung traditioneller UML-Line-End-Behandlungen zur weiteren Charakterisierung von Beziehungen
  • Verwenden von Farben zum Verknüpfen von Objekten mit einem ähnlichen Zweck

Anzeige von Kernsystemobjekten

Nicht jedes Objekt ist in einem System gleich wichtig. Einige Objekte repräsentieren das einzigartige Wertversprechen eines Systems oder sind anderweitig von zentraler Bedeutung für das Erleben. Es ist normalerweise sinnvoll, zuerst Konventionen für die Kernobjekte zu entwerfen und diese dann auf andere Objekte im System auszudehnen.

Bei Twitter habe ich die Tweet- und die Timeline-Objekte als Kern angegeben, wobei der Objektname großgeschrieben und eine fett umrandete Behandlung verwendet wurde.

Angabe bestimmter Arten von Objektbeziehungen

Im Modell kann es hilfreich sein, bestimmte Beziehungsarten darzustellen. Beziehungstypen beleuchten mehr über die Objekte und wie sie aus Designperspektive behandelt werden könnten.

Die vier Haupttypen von Beziehungen sind:

  • Verband
  • Anhäufung
  • Komponente
  • Erbe

Verbandsbeziehung

Die einfachste Art der Beziehung ist eine Assoziation. Hier zeigen wir die Beziehung zwischen einem Konto und einem Tweet mit einer einfachen Linie. In unserem Narrative Object Model enthält die Zeile eine verbale Beschreibung der Beziehung. Die Beschreibung enthält einen Verweis auf beide Objekte (in Fettdruck).

Eine Assoziationsbeziehung, die durch eine klare Linie angezeigt wird.

Aggregationsbeziehung

Eine Aggregationsbeziehung gibt ein Objekt an, bei dem es sich lediglich um eine Sammlung oder Liste anderer Objekte handelt. In Twitter können Benutzer beispielsweise Tweets zu einer Sammlung mit dem Namen Moment hinzufügen. Ein Moment ist eine Art Tweetsammlung.

Ein ungefüllter Diamant notiert eine Aggregationsbeziehung.

Eine Aggregationsbeziehung, angezeigt durch einen ungefüllten Diamanten.

Komponentenbeziehung

Eine Komponentenbeziehung ist eine Art Abhängigkeitsbeziehung, bei der ein Objekt eine Komponente eines anderen ist. Für Twitter ist ein Hashtag eine wichtige Komponente eines Tweets. Das Konzept eines Hashtags hängt vollständig von der Idee eines Tweet ab. Wenn Sie das Konzept eines Tweet aus dem System entfernen, existiert das Konzept des Hashtags notwendigerweise nicht mehr.

Eine Komponentenbeziehung wird von einem ausgefüllten Diamanten notiert.

Eine Komponentenbeziehung, angezeigt durch einen ausgefüllten Diamanten.

Vererbung Beziehung

Last but not least ist die Erbschaftsbeziehung. Dies ist eine Parent-Child-Beziehung, bei der die untergeordneten Objekte alle oder einige der Eigenschaften des übergeordneten Objekts erben.

Unser Beispielmodell für Twitter zeigt keine Vererbungsbeziehungen. Wenn ich jedoch ein vollständiges Objektmodell für Twitter erstellt, kann ich die Vererbung verwenden, um verschiedene Kontotypen darzustellen, beispielsweise ein Benutzerkonto und ein Administratorkonto. Diese Objekte, die eine Teilmenge von Merkmalen gemeinsam haben, werden am besten als untergeordnete Elemente eines Kontos behandelt.

Eine Vererbungsbeziehung wird mit einem ungefüllten Pfeil gezeigt, der auf das übergeordnete Objekt zeigt. Das übergeordnete Objekt enthält die gemeinsam genutzten Merkmale. Nur die einzigartigen Eigenschaften werden für die Kinder gezeigt.

Eine Vererbungsbeziehung, die durch einen nicht ausgefüllten Pfeil angezeigt wird.

Beachten Sie jedoch, dass Konto in diesem Beispiel kein tatsächliches Objekt im System ist - es ist eine Abstraktion, die wir zum Erstellen eines übergeordneten Elements verwendet haben Auch hier können wir die klassische Klassendiagrammnotation verwenden, um das abstrakte Objekt << Account >> anzuzeigen.

Obwohl die Vererbung im Modell etwas kompliziert erscheinen mag, ist sie auch eine der nützlichsten Beziehungen, die man verstehen kann. Beim Entwerfen möchten Sie sicherstellen, dass übergeordnete Funktionen über alle untergeordneten Elemente hinweg konsistent dargestellt werden.

Objekte mit einem ähnlichen Zweck anzeigen

Große Modelle können visuell komplex werden. Um die Lesbarkeit zu verbessern, ist es hilfreich, Objekte mit einem ähnlichen Zweck farblich zu kennzeichnen. Für Twitter habe ich zum Beispiel drei Objektkategorien verwendet:

  • Core Experience (blau)
  • Kategorisierung & Entdeckung (grün)
  • Kontoführung (orange)

Ein realistischeres Modell

Ich habe Twitter verwendet, um ein Beispielmodell zu erstellen, da es ein relativ einfaches, bekanntes System ist. Bei einfachen Systemen können die Objekte und ihre Beziehungen selbstverständlich sein. Dies ist jedoch in der Regel nicht der Fall bei komplexeren Systemen, bei denen das Objektmodell eine prägnante Darstellung einer ansonsten inkohärenten zugrunde liegenden Struktur liefern kann.

Im Folgenden finden Sie ein realistischeres Modell für ein Unternehmenssystem. Dieses Modell basiert auf einem tatsächlichen Workflow-Managementsystem, obwohl einige Details für die Darstellung hier geändert wurden. Sie können die umfassendere Verwendung von Vererbungs-, Komponenten- und Aggregationsbeziehungen sowie die erweiterte Verwendung verbaler Beschreibungen sehen, um die strukturelle Geschichte des Systems besser zu verstehen.

Narrative Object Model für ein System zur Verwaltung von Unternehmensabläufen.

Objektmodellierung beherrschen

Die Objektmodellierung erfordert etwas Übung: Der beste Weg zu lernen ist, etwas zu tun. Wenn Sie an einem aktuellen Projekt arbeiten, gehen Sie zurück und erstellen Sie ein Objektmodell, auch wenn Sie im Entwurfsprozess bereits weit fortgeschritten sind. Wenn Sie noch kein reales Projekt haben, können Sie vorhandene Systeme im Web einfach modellieren, wie wir es hier bei Twitter gemacht haben.

Tipps zum Erstellen eines Modells:

  • Beginnen Sie mit den einfachen Dingen - zum Beispiel nur das Identifizieren einiger Objekte.
  • Bei größeren Systemen kann es sinnvoll sein, zwei oder mehr kleinere Modelle zu erstellen und diese dann zusammenzuführen.
  • Erstellen Sie das Modell im Laufe der Zeit in kürzeren Arbeitssitzungen.
  • Tun Sie gerade genug, um Ihren Zweck zu erfüllen. Analyse-Paralyse vermeiden.
  • Zwei Personen modellieren dasselbe System möglicherweise etwas anders, und das ist in Ordnung.

Verwenden des Modells

Natürlich erstellen wir Modelle nicht nur als analytische Übung. Wir möchten das Modell verwenden, um die Designergebnisse zu verbessern.

Zu Beginn möchte ich betonen, dass das Narrative Object Model eine einzige, spezifische Sicht auf ein System bietet - eine strukturelle Sicht. Es ist nicht dazu gedacht, andere Artefakte wie Storyboards, Reisekarten, Benutzergeschichten und Anwendungsfälle zu ersetzen, die die Benutzererfahrung aus Sicht der Aufgaben darstellen. Das Objektmodell ist immer eine Ergänzung zu anderen Designartefakten.

Schauen wir uns an, wie das Objektmodell in den Entwurfsprozess passt. Das Modell kann verwendet werden, um Folgendes zu identifizieren:

  • Signaturelemente eines Systems
  • Objekte, deren Zweck oder Funktion ähnlich sind
  • Was kann funktional unvollständig sein?
  • Kontrollierte Vokabeln

Ich verwende das Objektmodell auch beim Design auf Bildschirmebene, um sicherzustellen, dass eine klare Beziehung zwischen einem Objekt und allen zugehörigen Aktionen besteht.

Identifizieren der Signaturelemente des Systems

Mit dem Aufkommen vorgefertigter Design-Systeme wie Google Material Design ist es für ein Unternehmen einfacher denn je, mit seinem Design-System zu beginnen. Das Risiko bei der Verwendung öffentlich verfügbarer Komponenten (oder deren direkter Ableitung) besteht darin, dass Ihre Anwendung wie alle anderen aussieht und sich anfühlt. Eine Möglichkeit, dies zu vermeiden, besteht darin, zunächst Konventionen für Ihre Kernobjekte zu entwickeln - diejenigen, die für das Erleben von zentraler Bedeutung sind - und das Design dieser Objekte unverwechselbar machen. Diese werden gemeinsam zu den Signaturelementen des Systems, die für die verbleibenden Konstruktionskonventionen erweitert und erweitert werden. Dieser Ansatz wurde sowohl von Dan Mall in "Distinct Design Systems" als auch von Emmet Connolly in "The Full Stack Design System" vorgeschlagen.

Identifizieren von Objekten, die in Funktion oder Zweck ähnlich sind

Eine andere Möglichkeit, die Modell- und Laufwerkkonstruktionskonventionen anzuzeigen, besteht darin, diese Objekte mit einer ähnlichen Funktion oder einem ähnlichen Zweck zu identifizieren und diese Objekte als Einheit zu entwerfen. Aggregatobjekte sind z. B. häufig Listen oder Sammlungen, deren Funktionen sich inhärent ähneln. Durch das gleichzeitige Entwerfen von Konventionen für diese Objekte können Sie den Fall vermeiden, in dem Sie ein auf einem Objekt basierendes Design erstellt haben, dann jedoch feststellen, dass es sich nicht auf ein im Wesentlichen ähnliches Objekt erstreckt.

Es ist auch hilfreich, Objekte zu identifizieren, die einen ähnlichen Zweck haben. Im vorherigen Abschnitt haben wir die Farbcodierung verwendet, um Objekte in Kategorien zu gruppieren.

Im Twitter-Modell gibt es drei Objektkategorien:

  • Kernerfahrung
  • Kategorisierung & Entdeckung
  • Kontoführung

Im Enterprise-Workflow-Systemmodell gibt es vier Kategorien:

  • Systembenutzer
  • Rollen in einer Transaktion
  • Komponenten einer Transaktion
  • Arbeitsmanagement

Auch hier kann es sinnvoll sein, die Objekte innerhalb einer Kategorie gleichzeitig so zu gestalten, dass sich das Erlebnis konsistent anfühlt.

Es ist auch nützlich, Fälle von Vererbung (Eltern-Kind-Beziehungen) zu betrachten. Sie möchten sicherstellen, dass übergeordnete Funktionen über alle untergeordneten Elemente hinweg einheitlich dargestellt werden.

Identifizieren, was funktional unvollständig sein könnte

Beim Entwerfen neuer Funktionen kann das Objektmodell eine hilfreiche Gegenüberprüfung bieten, ob alle Objekte funktional sind und insbesondere Aktionen nicht übersehen wurden.

Ein Ausgangspunkt ist die Suche nach CRUD-Aktionen (Erstellen, Lesen, Aktualisieren und Löschen). Beispielsweise erlaubt es Twitter bekanntlich nicht, dass ein Tweet aktualisiert wird, sobald er veröffentlicht wurde. Da ich Twitter modelliere und die Vollständigkeit der Objekte überprüfe, würde ich diese Auslassung feststellen. In diesem Fall ist das Fehlen einer Aktualisierungsfunktion beabsichtigt, könnte aber auch übersehen worden sein. Nach meiner Erfahrung übersehene Grundfunktionen sind nicht ungewöhnlich.

Es kann auch hilfreich sein, Objekte anzuschauen, die eine ähnliche Funktion erfüllen, und diese zu vergleichen. In Twitter haben beispielsweise ein Tweet und eine Direktnachricht eine ähnliche Funktion - um mit anderen zu kommunizieren. Sie können einen Tweet als Favorit markieren, eine direkte Nachricht jedoch nicht. Sollten Benutzer eine Direktnachricht auch als Favorit markieren können?

Festlegen kontrollierter Begriffe für das Vokabular

Ein häufiges Problem bei Systemen, die im Laufe der Zeit gewachsen sind (oder Funktionen haben, die von verschiedenen Teams erstellt wurden) ist inkonsistenter Wortschatz. Manchmal sind Inkonsistenzen relativ gering (Edit vs. Update), sie können jedoch auch grundlegend sein (Task vs. Assignment).

Ein Grund, die Aktionen und Attribute für jedes Objektrechteck vollständiger auszufüllen, ist eine gründliche Vokabularprüfung. Das Modell kann letztendlich als Quelle für ein kontrolliertes Systemvokabular dienen.

Neben der Vokabularüberprüfung von Objekten ist es auch nützlich, Begriffe innerhalb eines Objekts zu überprüfen. In Twitter wird das Wort „Tweet“ sowohl als Substantiv als auch als Verb verwendet. Es ist offensichtlich, dass dies für Twitter sinnvoll ist, aber es könnte eine legitime Frage sein.

Eine klare Beziehung zwischen einem Objekt und den zugehörigen Aktionen aufrechterhalten

Während der Entwurfsarbeit auf Bildschirmebene kann das Objektmodell als Referenz dienen, um sicherzustellen, dass eine eindeutige Zuordnung zwischen einem Objekt und den zugehörigen Aktionen besteht. Auch wenn sich das nach einem Ratschlag für die Behebung anhören mag, war ich bei manchen Systemen mit unlogisch verstreuten Aktionen konfrontiert. Normalerweise geschieht dies im Laufe der Zeit, wenn neue Funktionen dort platziert werden, wo Bildschirmflächen zur Verfügung stehen und nicht, wo sie logischerweise in das Erlebnis passen würden.

Einpacken

In diesem Artikel habe ich versucht, den Fall für die Objektmodellierung darzulegen. Ich betrachte die Objektmodellierung einer Fertigkeit in meinem UX-Werkzeuggürtel sowie die Durchführung von Recherchen, die Erleichterung von Workshops, das Kartieren von Reisen, die Entwicklung von Persona und dergleichen. Dies sind alles Inputs, die je nach den Erfordernissen des Projekts zu den erfolgreichen Designergebnissen beitragen.

Für zusätzliche Perspektiven zur Objektmodellierung für das Design lade ich Sie ein, diese anderen Ressourcen zu erkunden:

  • OOUX: Eine Grundlage für Interaktionsdesign von Sophia Voychehovski Prater
  • Design für Einfachheit: Objektorientierte UX von Jessica Romeo
  • Objektorientiertes vs. aufgabenorientiertes Design von Everyl Yankee

Happy Object Modellierung!