UCD Vorgehensmodelle 2
User-zentriertes Vorgehen - Design Phase
User-zentriertes Vorgehen - Design Phase
-
- 1 / 29
-
Cartes-fiches
Tätigkeiten in der Design-Phase im UCD
- Konzeption und Design
- Modellieren, Entwickeln von Prototypen
- Evaluation der Prototypen, Modellen
- Fertigstellen der Lieferergebnisse. Wenn OK: Ausliefern an Entwicklung. Wenn NOK: Iteration Schritt 1
Konzeption und Design:
Allgemein & Tätigkeiten (7)
Die Ergebnisse aus der Analysephase in ein User Interface zu transformieren.
- Work Reengineering
- Interaction Design
- Informations Architecture
- User Interface Design
- Visual Design
- Technical Writing
Work Reengineering
Befasst sich mit der Neugestaltung der Arbeitsabläufe.
Arbeitsabläufe auf die neue Situation u. Technik abstimmen.
Wird kein WR gemacht: Redundante Dateneingabe Potential der neuen Lösung wird nicht ausgeschöpft.
Interaction Design
Aus den Anforderungen Struktur und Verhalten ableiten.
Informations Architektur
Strukturierung der Informationen.
UI Design
- Anordnung der Bedienelemente
- Abstimmung mit Styleguides der Plattformen
Visual Design
- Präsentation des UI
- Branding / CI / CD Umsetzung
- Persönlichkeit
Internationalisierung
Internationalisierung ist die Anpassung eines Produkts, damit es theoretisch überall eingesetzt werden kann.
Lokalisierung
Prozess des Anpassens
- Währung
- Anpassung an Gesetzgebung
- Datumsformat
Alternative od. andere Unterteilung von Design
- konzeptionelles Design
- Struktur, Verhalten, Modell
- konkretes Design
- Präsentation, Platzierung von Elementen
Vom Modell zum klickbaren Prototypen
Eigenschaft von Modellen?
Bilden nur immer einen speziellen Teil eines Systems/Ganzen ab.
- Können grafisch od. textlich sein.
- soll die Komplexität reduzieren
Evaluation
- Überprüfen ob das Design den Anforderungen entspricht
- Usability Goals!
- funktional, technisch, Geschäftsprozesse
Information Design
Unterdisziplin von Visual Design. Informationen in grafischer Form aufbereiten.
Technical Writing
- Manuals
- Text design - Texter
- Fehlermeldungen
Wann braucht es Modelle?
- Beim komplexen Sachverhalten
- um einen speziellen Teil zu analysieren
- zur Strukturierung (Sitepmap)
- Evaluation durch Experten
- Lieferobjekt für Entwicklung
Wann braucht es Prototypen?
- Hypothese Prüfen
- Testen mit Benutzer
- Präsentation
- Interaktionen zu zeigen, testen
- Intern, um gemeinsames Verständnis zu schaffen
Summative Evaluation?
- Prüfen ob die Usability Goals erreicht sind
- strukturiert
- eher später im Projekt
- Messen: Zeit, Fehlerrate
Formative Evaluation
- Einsichten für das Design gewinnen.
- Explorativ / offen
- früh im Projekt
- zB. mit Papier Prototyp
Lieferergebnisse für Entwicklung
- Stileguide
- Interaction-Design-Pattern
- Modelle
- Prototypen
- Spezifikationen
Wieso nicht nur Prototypen und ID-Patterns?
- Können nicht alles abdecken
- Konsistenz
- Weiterentwicklung
Konsistenz
Trägt wesentlich zur Qualität eines Produktes bei.
- Usability
- Lernverhalten
- Effizienz
- Stabilität
Empirisches Design
Design ableiten aus Erkenntnis der Analyse-Phase.
-> So können alle Vorschläge immer mit Fakten aus der Analyse-Phase begründet werden.
Fragen am Anfang des Design Prozesses?
- Wie soll mit dem System interagiert werden?
- Was soll das System sein?
Grundschichten mit Unterschichten
- Struktur
- Conceptual Model (Tabelle, Bilder, Mix)
- Task-flow (Wie viele Schritte)
- Organisation Model (Alle mit allen verhängt, Untergruppen)
- Verhalten
- Viewing and Nav. (Thrill-Down, Shortlinks, Browse)
- Editing (Feld mit direktem E, oder allgemein)
- Assistance (Alt-Tag, Info-Layer)
- Präsentation
- Layout (Pattern / Ausrichtung)
- Style (Button, Farbe)
- Text (Text-Form)
Welche Typen von Persona gibt es?
- Primär
- nur eine pro UI
- Das Design wir auf diese Persona ausgerichtet
- Sekundär
- kann meherere pro UI geben. Für sie wird das UI so weit optimiert, dass es für die primär P. keine Einbussen gibt.
- Komplementär
- UI wird nicht weiter optmiert. Benutzung kann für diese Persona etwas umständlich sein.
- Anti
- Persona für die das UI NICHT gemacht ist.
Modelle zum Kontext (Problem Domain)
BENUTZER
- Persona
- User Role
AUFGABE
- Szenario
- Use Cases
- Task Cases
- Storyboard
SYSTEM
- Manual
- Modelle der Informatik
UMFELD
Cultural Model
Szenario
Physical Model
Storyboard
Modelle zum UI des Sytems (Solution Domain) + Erklärung
OBJEKT MODELL
- Objekte aus Sicht des Users. Nur die die für den Benutzer relevant sind. Orientieren sich am Mental Model des Benutzer. Die die im UI abgebildet werden.
STORYBOARD / ABLAUF DIAGRAMM
Zeigt einen Ablauf: zB. mehrere Screens oder Aufgbaben. Fokus: Unterteilung der Screens. Stellt einen od. mehrere Use Cases dar.
STRUKTUR
Use Case Map. Sitemap der Benutzer und Funktionen
5-Dimensionen eines Prototypen
- Interaktivität
- Visuelle Ausarbeitung
- Funktionale Tiefe
- Funktionale Breite
- Datenbestand
Prototypen Einteilung nach Zweck
ROLE
Funktionale Anforderungen an das System
Welche Rolle nimmt das System ein. Was will der Benutzer mit dem System machen.
LOOK + FEEL
Interaktion, visuelle, Mental Model Aspekte prüfen.
Gestaltung der Benutzeroberfläche
IMPLEMENTATION
Technische Elemente Testen. zB. Umsetzung in JS oder CSS3
Anbindung an DB
INTEGRATION
Zusammenspiel von 1,2,3 drei. Auf Zielsystem.
- Spezifikation
