Ein Team sitzt am Tisch zusammen und diskutiert. Ein Kollege ist remote dazugeschaltet und im Bildschirm im Hintergrund sichtbar. Einige offene Laptops stehen auf dem Tisch.
Kerstin | 07.02.2023

UX Design in 5 Ebenen: 2. Scope

Allgemein > UX Design in 5 Ebenen: 2. Scope

Wie finde ich die notwendigen Features für mein Produkt?

Aus der Reihe: UX Design in 5 Ebenen

Mit Design Thinking kann man nutzerzentriert Nutzerbedürfnisse und Produktanforderungen analysieren und iterativ verbessern. Mithilfe mehrerer Abteilungen können viele Nutzungskontexte einbezogen werden und der gemeinsame Wissenspool kann langfristig hilfreich sein. Mithilfe der 5 Elemente des UX Designs kann man sich den Maximen des Design Thinkings annähern. Dabei handelt es sich um ein konzeptionelles Framework, das den Designprozess in fünf Elemente aufteilt. Man analysiert das Problem in abstrakter Weise, um dann immer konkreter in den Fragestellungen und Lösungsideen zu werden. Die Erarbeitung der Ebenen sollte nacheinander ablaufen und Entscheidungen können dafür sorgen, dass die vorige Ebene erneut angegangen und ergänzt oder korrigiert wird. Das kann zum Beispiel beim Wechsel einer Priorität passieren.


Die 5 Elemente des UX Designs ist ein Prozess, der in der abstrakten Ebene "Strategy" startet (Was sind unsere Produktziele und die Nutzerziele?). Weiter geht es mit dem Scope (Welche Funktionen und welcher Content muss bereitgestellt werden?), der Structure Ebene (Wie soll der Inhalt strukturiert werden und wie kann mit dem Produkt interagiert werden?), dem Skeleton (Wo werden die Navigation, die Inhalte und Interaktionselemente positioniert?) und der Ebene mit dem konkretesten Fragestellungen "Surface" (Wie werden Inhalte gesetzt, um den Fokus korrekt zu setzen und ein schnelles Verständnis zu ermöglichen?).


Im vorigen Artikel wurde bereits über die Strategie gesprochen: Die erste und abstrakteste Ebene erarbeitet die Produktziele und Nutzungsbedürfnisse. In der folgenden Ebene geht es um den Umfang:

Welche Funktionen und welche Inhalte folgen daraus?

Was muss vom Produkt bereitgestellt werden, um die Produktziele umzusetzen und die Nutzungsbedürfnisse zu stillen?


Diese Anforderungen sollten konkret formuliert werden. Es gibt verschiedene Wege, um ein Ziel zu erreichen. An diese Stelle entscheidet man sich also für einen Weg, wodurch sich Möglichkeiten für das Design in der folgenden Ebene ergeben. Erkennt man bei der Gestaltung in der Folgeebene, dass die Möglichkeiten nicht zu einem zufriedenstellenden Entwurf führen, kann man die Scope Ebene erneut bearbeiten und die Entscheidung für den Weg ändern. Demnach ist es sinnvoll, eine Ebene erst abzuschließen, wenn man den Eindruck hat, dass man die aktuelle Ebene schon fast fertig gestellt hat.

Im Scope wird also möglichst konkret formuliert, was die Features im Produkt werden sollen und welche Inhalte verfügbar sein sollen. So wird sichergestellt, dass alle zum selben Ziel hinarbeiten und Missverständnisse sofort auffallen. Weiterhin fällt in einer Liste eher auf, welche Zuständigkeiten entstehen und ob einige Inhalte gruppiert werden können, um die Bearbeitung in den folgenden Ebenen effizienter umzusetzen. Die Liste erzeugt auch eine Eingrenzung und kann Prioritäten schaffen, sodass einige der Features und Inhalte als Basis für einen späteren Entwicklungszyklus genutzt werden. Ferner dienen die verschriftlichten Anforderungen der Abnahme des Produkts.

Im UX Design kann man die Gestaltung von Anwendungen über zwei Sichtweisen angehen: Die Anwendung als funktionales Mittel und die Anwendung als informatives Mittel. Software kann dazu dienen, eine Aufgabe zu erledigen, sodass Funktionen bereitgestellt werden, um die Aufgabe möglichst effizient erledigen zu können. Der Fokus kann aber auch auf dem Einholen von Informationen liegen. In den meisten Fällen ist es eine Kombination aus beiden, daher sind beide Sichtweisen relevant und umzusetzen. Dabei interdisziplinär zu arbeiten ist sinnvoll, um zu vermeiden, dass zum Beispiel Interaktionen in der Anwendung zu unklaren Rückmeldungen vom System führen, da ein programmiertes Feature nicht von einem Content Editor geprüft wurde.


Wie entscheidet man sich denn nun für die notwendigen Features?

In der Strategie Ebene hat man hoffentlich schon mit Nutzer:innen gesprochen und einige konkrete Ideen für Features sammeln können. Diese Ideen sind teilweise klare und berechtigte Wünsche, manchmal werden aber auch Ideen geteilt, die entweder nur ein Symptom zum eigentlichen analysierten Problem behandeln oder die Idee hat sogar keinen Einfluss auf das Problem. Dass solche scheinbar sinnlosen Ideen dennoch geteilt werden, kann kontextbedingt sein: Ein vorher genutztes (Konkurrenz-)Produkt bietet ein ähnliches Feature an oder in einer konkreten emotionalen Situation hat man ein Feature ein einziges Mal gebraucht und wegen des emotionalen Moments wird dem Feature eine höhere Priorität zugeordnet. Wegen individueller Erfahrungen ist es daher wichtig, bei der Ideenfindung unvoreingenommen zu bleiben und auch Bestehendes oder vermeintlich Selbstverständliches zu hinterfragen. Um das zu unterstützen, kann es sinnvoll sein, Personen in den Prozess einzubinden, die bei vorigen Entwicklungszyklen des Produkts nicht dabei waren. Diese Personen haben dann eine neue und unvoreingenommene Sichtweise. An der Stelle kann dann auch Design Thinking streng umgesetzt werden: Man entwickelt mit mehreren Abteilungen zusammen das Produkt, um verschiedene Erfahrungen und Kontexte zu verbinden.

Letztlich sollten die Features umgesetzt werden, die die wichtigsten erfassten Nutzungsbedürfnisse stillen und dabei die unternehmensinternen Ziele erfüllen. Die richtige Balance zu finden kann schwierig sein und es kann sein, dass aus wirtschaftlichen Gründen hochpriorisierte Ideen entweder komplett gestrichen werden müssen oder im aktuellen Entwicklungszyklus nicht realistisch einplanbar sind. Sollte eine Idee so viel Anklang im Entwicklungsteam finden, die aber eigentlich keinem strategischen Ziel folgt, macht es Sinn, die Ergebnisse der vorigen Ebene zu hinterfragen und gegebenenfalls zu aktualisieren.


Wie konkret sollte das Feature beschrieben sein?

Hat man sich für die funktionalen Anforderungen entschieden, sollten sie so beschrieben sein, dass keine Fragen offen bleiben. Dabei außen vor bleibt die visuelle Umsetzung, die erst über die folgenden Ebenen erarbeitet wird. In den Anforderungen sollten zum Beispiel keine vagen Aussagen sein wie "Die aktiven Mitarbeiter:innen werden priorisiert angezeigt", sondern mit einer genaueren Eingrenzung wie "Aktive Mitarbeiter werden am Anfang der Liste angezeigt und inaktive erst dahinter". Diese Anforderung erleichtert außerdem die Prüfung nach der Implementierung, da sich das Gegenteil beweisen ließe: Sind die aktiven Mitarbeiter:innen alle am Anfang der Liste oder befinden sich einige inaktiven Mitarbeiter:innen auch darunter? Es ist also wichtig, dass die prüfbaren Kriterien nicht subjektiv sind, sondern eindeutig erfassbar. Inhaltliche Anforderungen können über die Textlänge, demnach Zeichenanzahl, Bildgrößen und Dateiformate definiert werden.


Welche Methoden gibt es?

Ressourcenintensiv

In der strategischen Ebene wurden viele Nutzungsdaten und Unternehmensziele erfasst. Im Affinitätsdiagramm können die gesammelten Daten gruppiert und sortiert werden, um eine Übersicht zu erhalten. Definierte Kategorien können dann helfen, sich konkreten Features anzunähern. Sinnvoll ist die Umsetzung durch mehrere UX Expert:innen oder eben erneut einem kleinen Team von fachübergreifenden Personen. Die so entstandenen Featureideen können dann mithilfe des Kano Models priorisiert werden. Beim Kano Model werden die Features in drei Kategorien geteilt:

  • Grundvoraussetzung, weil es ein grundlegendes Feature ist, was bei Konkurrenzprodukten immer vorhanden ist.

  • Performance-Eigenschaften, die einen wettbewerbsfähig machen.

  • Delight-Eigenschaften, die nützlich sind und die nicht der Norm entsprechen, sodass Nutzer:innen sie nicht erwarten.

Ressourcensparend

Ein Product Owner bespricht mit dem hierarchisch höchsten Stakeholder die wichtigsten Unternehmensziele, die mit dem Produkt erreicht werden sollen. Der Product Owner versucht dann die Features und Inhalte zu finden, die die am höchsten priorisierten Ziele vom Unternehmen und Nutzer:innen erreichen. Diese Vorgehensweise entspricht nicht dem Ansatz des Design Thinkings! Innovation findet genau in diesem Ideenfindungsschritt statt. Daher ist es essentiell, in diesem Schritt Ressourcen zu investieren und ein interdisziplinäres Team gemeinsam Ideen entwickeln zu lassen. Daher:

Das empfohlene Minimum

In der Ideenfindungsphase sollte interdisziplinär gearbeitet werden, um wirklich offen und kreativ Lösungen zu erarbeiten. Daher sollten die Features und Inhalte, die zu den erfassten Zielen passen, von einem interdisziplinären Team erarbeitet werden. Um ressourcensparend zu werden, könnte die Einordnung der erfassten Daten in ein Affinitätsdiagramm vom Product Owner vorbereitet werden, bevor auf dem Diagramm basierend in einem Team Anforderungen diskutiert werden. Zur Priorisierung kann dann das Kano Model genutzt werden.




Ein Beispiel:

Ein Personalmanagementtool soll konzipiert und implementiert werden. Das eigene Software Unternehmen ist mit dem bisher genutzten Produkt nicht ausreichend zufrieden, sodass ein eigenes entwickelt werden soll. Da es sich um ein intern zu nutzendes Produkt handelt, handelt es sich bei den Nutzer:innnen um Kolleg:innen und die Stakeholder sind die Geschäftsführung, die Personalabteilung und Projektleitungen.


Welche Methode wird zur Ideensammlung genutzt?

Ein UX-Experte findet sich mit vier weiteren Kolleg:innen aus der Personalabteilung und Projektleiter:innen zusammen, um mithilfe eines Affinitätsdiagrammes die gewonnenen Nutzungsdaten zu gruppieren und zu sortieren. Der UX-Experte hat die Daten teilweise vorgefiltert, um Dopplungen zu vermeiden, beachtet aber verschiedene Wordings, die auf unterschiedliche Bedürfnisse und Kontexte hinweisen können. Physisch beschriftete Karten werden vorbereitet und zum interdisziplinären Meeting mitgenommen. Die Diskussion mit Einordnung der Karten erhält eine Timebox von 1:30h. Darauf folgt eine kurze Pause. Die Ideenfindungsphase wurde während der Sortierung der Karten bereits angestoßen, erhält aber eine weitere Timebox von 1:30h. Am Ende entsteht eine Tabelle mit Features und Inhalten. Die am höchsten priorisierten, die keiner Diskussion bedurften, wurden mit einem Stern markiert.


Was sind die Features und Inhalte mit höchster Priorität?

  • Alle Mitarbeiter werden aufgelistet. Dabei werden die inaktiven Mitarbeiter ans Ende der Liste gesetzt. Jeder Eintrag verlinkt auf die Detailansicht des Mitarbeiters.

  • Eine Mitarbeiteransicht zeigt den gesamten Verlauf der Arbeitszeiten.

  • Bei der Auflistung der Arbeitszeiten ist die aktuellste Arbeitszeit an erster Stelle und entsprechend absteigend die älteren Arbeitszeiten.

  • Eine Mitarbeiteransicht zeigt den gesamten Verlauf der Gehaltsänderungen.

  • Bei der Auflistung der Gehaltsänderungen ist die aktuellste Gehaltsänderung an erster Stelle und entsprechend absteigend die älteren Gehaltsänderungen.


Was sind weitere Features und Inhalte?

  • Bei der Analyse wird der Bedarf eines Massendownloads von bestimmten Dateien erkannt. Konkret besteht also die Anforderung, dass alle Krankschreibungen aus einem angegebenen Zeitraum als Zip-Datei runtergeladen werden können.

Nun wurden also die Anforderungen erfasst und priorisiert. Wie die Inhalte und Features strukturiert werden sollten, um Nutzer:innen optimal durch die Software zu leiten, wird im nächsten Artikel vorgestellt.

Kerstin Paduch
Kerstin (Softwareentwicklerin)

... ist eine leidenschaftliche Frontendentwicklerin in Dortmund. Ihre Hauptwerkzeuge sind TypeScript, Angular, und Figma. Sie baut im Nu zauberhafte Mockups und setzt diese effizient um. Nutzerzentrie... mehr anzeigen

Standort Hannover

newcubator GmbH
Bödekerstraße 22
30161 Hannover

Standort Dortmund

newcubator GmbH
Westenhellweg 85-89
44137 Dortmund