Human Computer Interaction · Der Design-Prozess ist kreativ und nicht vorhersagbar Gestalter...

1

07.11.08 W. Müller, PH Weingarten Folie 1

Human Computer InteractionGestaltung und Implementierung effizienter

Benutzungsschnittstellen

Design-Methodiken

Prof. Dr. Wolfgang MüllerPH Weingarten


Übersicht

Rückblick

Design-Methodiken– Grundlagen– LUCID– IBM Ease of Use Development Methodology– Ethnographische Studien– Participatory Design– Szenario-basiertes Design

2


Organisationsstrukturen und Usability

Der Design-Prozess ist kreativ und nicht vorhersagbar

Gestalter interaktiver Systeme benötigen– Wissen über die technische Machbarkeit wie auch– ein ästhetisches Talent um zu wissen, was Anwender anzieht

Aspekte des Design-Prozesses (nach Carroll, Rosson, 1985) – Design ist ein Prozess, kein statischer Zustand– Der Design-Prozess ist nicht-hierarchisch – Der Design-Prozess führt zu radikalen Transformationen– Design beinhaltet die Entdeckung neuer Ziele


Die drei Säulen des Designs (I)

Akademische Forschung

Theorienund Modelle

Algorithmenund Prototypen

KontrollierteExperimente

Erfolgreiche Benutzungsschnittstellen

Richtlinienund

Prozesse

UISoftware

Tools

Experten-Reviews

undUsabilityTesting

nach Shneiderman, Plaisant 2006

3


Die drei Säulen des Designs: Richtlinien und Prozesse

Richtlinien und Prozesse– Jedes Projekt hat unterschiedliche Anforderungen– Dennoch sollten Richtlinien für bestimmte Punkte aufgestellt

werden

Beispiele– Texte, Icons und Graphiken – Terminologie (Objekte und Relationen), Abkürzungen,

Groß/-Kleinschreibung – Zeichensatz, Fonts, Fontgrößen, Schriftformen (fett, kursiv,

unterstrichen) – Icons, Grafiken, Linienbreite, sowie – Verwendung von Farbe, Hintergründe, Highlighting und Blinken


Die drei Säulen des Designs (II)

Screen-Layout Aspekte– Menüauswahl, Formulare und Dialogboxen– Wording von Eingabeaufforderungen, Feedback,

Fehlermeldungen – Einrückungen, Leerzeichen, Seitenränder – Formen und Darstellung von Dateneinträgen für Elemente und

Listen– Verwendung und Inhalte von Kopf- und Fußzeile

Ein- und Ausgabegeräte – Tastatur, Monitor, Cursor-Steuerung, Pointing Devices – Audiosignale, Voice Feedback, Touch Input, sowie andere

spezielle Geräte– Antwortzeiten für verschiedene Aufgaben

4


Die drei Säulen des Designs (III)

Aktionssequenzen – Direct-Manipulation Clicking, Drag & Drop, Gesten – Befehlssyntax, Semantik, Sequenzen– Programmierbare Funktionstasten – Fehlerbehandlung und Recovery-Prozeduren

Training – Online-Hilfe und Tutorials – Training und Referenzmaterialien


Die drei Säulen des Designs (IV)

Aspekte von Richtlinien im Gestaltungsprozess– Aufstellung ist wichtiger sozialer Prozess für Entwickler– Protokollieren Entscheidungen– Fördern Konsistenz und Vollständigkeit– Ermöglichen die Automatisierung von Design– Ermöglichen die Unterscheidung verschiedener Ebenen

• Feste Standards• Akzeptierte Praktiken• Flexible Richtlinien

– Legen Politik fest für:• Ausbildung: wie wird sie gewährleistet?• Enforcement: Wer ist zuständig für das Review?• Ausnahmen: Wer entscheidet?• Enhancement: Wie oft?

5


Die drei Säulen des Designs (V)

User-Interface Software Tools– Entwicklung adäquater Prototypen

schon in frühen Projektphasen zur Vermittlung von Design-Entscheidung und deren Konsequenzen

– Fördern die Einhaltung von Richtlinien

Experten-Reviews und Usability Testing– Wertvoll zur Evaluierung von Design-Entscheidungen und zur

Qualitätssicherung– Umfang abhängig von Zielen, der Anzahl der erwarteten Anwender, der

Gefahr von Fehlern und dem Grad des Investments


Theorienund Modelle




Richtlinienund

Prozesse

UISoftware

Tools

Experten-Reviews

undUsabilityTesting


Theorienund Modelle




Richtlinienund

Prozesse

UISoftware

Tools

Experten-Reviews

undUsabilityTesting

Beide Aspekte werden noch intensiver behandelt

07.11.08 W. Müller Folie 10

Das Wasserfall-Modell

Initialisierung

Analyse

Entwurf

Realisierung

Einführung

NutzungNicht-iteratives Vorgehensmodell (in der Softwareentwicklung)Entwicklungsprozess unterteilt in PhasenErweiterung: Wasserfallmodell mit Rücksprung– Erlaubt Probleme in einer Phase auf einer höheren Ebene zu lösen

6

07.11.08 Folie 11

Methodiken zur Medien- und User-Interface-Entwicklung (I)

Viele Software- und Multimedia-Projekte verfehlen ihre Ziele– Schätzungen: 60%

Häufiger Grund– Mangelhafte

Kommunikation zwischen Entwicklern und Kunden sowie zwischen Entwicklern und Anwendern

Analyse

Design

Implement.

Test

Installationund Wartung

07.11.08 Folie 12

Prozesse

Beschreibung in der Anforderungsanalyse

Vorschlag des Kunden Design des Senior Analysten

Implementierung der Entwickler

Installation beim Kunden

Was der User wollte ...

Fred Tep

fer, Univ. of O

regon

7

07.11.08 Folie 13

Design interaktiver Systeme als„Ill-structured and Wicked Problem“

Unvollständige ProblembeschreibungUngenaue und häufig widersprüchliche ZielsetzungenFehlen eindeutiger Kriterien, was eine Lösung ausmachtKein eindeutiger LösungswegVerschiedene Lösungen

07.11.08 Folie 14

User-Centered System Design

Benutzerzentriertes Design– Prozess der Systementwicklung und

weiter im Lebenszyklus des Produktes mit absolutem Fokus auf Usability

– Enge Zusammenarbeit zwischen Anwendern, Designern und Technikern

– Wünsche, Bedürfnisse und Restriktionen und zur Entwicklung entsprechender Lösungen

– Genaue Beachtung von Anforderungen und Feedback von Anwendern bereits in frühen ProjektphasenGulliksen und Göransson 2005

8

07.11.08 Folie 15

Schlüsselelemente desUser-Centered System Design

Fokus auf den AnwenderAktive Einbeziehung von AnwendernEvolutionärer Prozess der Systementwicklung (interaktiv, inkrementell)Einfache Design-DarstellungenFrühes und kontinuierliches PrototypingEvaluierung der Anwendung im KontextExplizite und bewusste Design-EntscheidungenProfessionelle Entwicklung in multidisziplinären TeamsFrühe und kontinuierliche Einbeziehung von Usability-ExpertenHolistisches Design unter Einbeziehung aller AnwendungsaspekteAnpassung des Design-Prozesses an spezifische AnforderungenBenutzerzentrierte Attitude als Grundlage im Team

Gulliksen und Göransson 2003

07.11.08 Folie 16

Fokus auf den Anwender:Context of Use


9

07.11.08 Folie 17Gulliksen und Göransson 2005

Einbeziehung von Anwendern

07.11.08 Folie 18

Einfache Design-Darstellungen


10

07.11.08 Folie 19Gulliksen und Göransson 2005

Prototyping

07.11.08 Folie 20

Prototyping

<


11


Design-Methodiken

Erfahrungen aus der Software-Entwicklung– Konsequente Verfolgung etablierter Entwicklungs-Methodiken

kann bei der Einhaltung von Zeitplänen und Budgets helfen

Folgerung: Design-Methodiken

07.11.08 Folie 22

Methodiken des User-Centered Designs

Usability engineering (Nielsen, Mayhew)Design for usability (IBM & Gould et al.)Human-centered design (ISO 13407)Scenario-based design (Carroll et al.)Goal-directed design (Cooper)Usage-centered design (Constantine & Lockwood)Contextual design – Customer-centered design (Beyer & Holtzblatt 1988)Cooperative design (Scandinavian School) (Greenbaum & Kyng)Participatory design (Muller, Haslwanter & Dayton)Logical User-centered Interaction Design (LUCID, Kreitzberg 1996)IBM Ease of Use Development MethodologyGUIDE

12


LUCID (I)

The Logical User-Centered Interactive Design Methodology (LUCID) (Kreitzberg 1996)– Stufe 1: Envision– Stufe 2: Discovery– Stufe 3: Design Foundation– Stufe 4: Design Detail– Stufe 5: Build– Stufe 6: Release


LUCID (II)

Stufe 1: Envision– Abgleich der Zielsetzungen der Stakeholders – Festlegung technischer Constraints– Entwicklung einer klaren, gemeinsamen Vision der Stakeholder an das

geplante Produkt – Feststellung und – Beginn des Design-Prozesses auf Ebene von Konzepten und Sketches

Stufe 2: Discovery– Entwicklung eines klaren Verständnisses über die Charakteristika

einzelner Benutzergruppen– Verständnis der Aufgabenstellungen der Anwender, der benötigten

Informationen, der verwendeten Terminologien, der Prioritäten und Mentalen Modelle

– Analyse der gesammelten Daten und Entwicklung der Anwenderanforderungen an das Produkt

13


LUCID (III)

Stufe 3: Design Foundations– Entwicklung und Validierung des grundlegenden konzeptuellen Designs

für das Produkt– Entwicklung des Visual Look– Präsentation des vollständigen Designs in Form eines Screen Prototypes

Stufe 4: Design Detail– Entwicklung eines Style Guides für Screen-Design und UI-Verhalten– Übersetzung von High-Level Designs in komplette Spezifikationen– Durchführung von Usability-Studien für spezifische Screens oder

Workflows– Entwicklung detaillierter Spezifikationen für alle Screens und

Bildschirmelemente


LUCID (IV)

Stufe 5: Build– Unterstützung der Entwickler bei der Implementierung, ggf.

Redesign von UI-Komponenten– Durchführung von Usability-Studien kritischer Screens– Unterstützung des Entwicklungsprozesses durch Reviews und

Last-Stage Change Management

Stufe 6: Release– Entwicklung eines Roll-out-Plans– Usability-Evaluierung des Out-of-the-Box-Eindrucks oder der

Installationsroutinen– Feststellung der Anwenderzufriedenheit

14


LUCID (V)

Aspekte von LUCID– Explizites Committment zum User-centered Design– Rolle des Usability Engineering explizit– Key-Screen Prototype bereits in früher Projektphase

• Verwendet für Evaluierung und Usability Testing– Rapid Prototyping– Nutzung von User Interface Software Tools


LUCID (VI)

Die 12 Gebiete der LUCID Management Strategy– Produktdefinition – Business Case – Ressourcen – Physikalische Umgebung – Technische Umgebung – Users – Funktionalität – Prototyp – Usability – Design Guidelines – Inhaltliche Materialen – Dokumentation, Training und Hilfen

15


IBM Ease of Use Development Methodology

Initial DesignRole/Phase Business Opportunity

Understanding Users Development Deployment Life Cycle

User Experience Leadership

User Experience Plan – Initial

User Experience Plan – Final

Evaluation of the User

Engieneering Plan

Satisfaction of established

metrics

Project Assessment

Satisfaction Survey

Market Planning

Business and Market

Requirements

Appropriate User Requirements

Draft Marketing Collateral

Detail Marketing Collateral

Final Marketing Collateral

User Research User Requirements

Appropriate Design

User Experience

DesignDesign Direction Conceptual

Design

Detail Design, High-Fidelity Prototypes

Design-Issue Resolution

Visual and Industrial Design

Appearance Direction

Appearance Guidelines

Appearance Specification

User Experience Evaluation

Competetive Evaluation

Conceptual Design

Evaluation

Detail Design Evaluations

User Feedback and Benchmark

Usage Isuue Report

Role-by-Phase Matrix: IBM Ease of Use Development Methodology


Ethnographische Studien (I)

Beobachtungen von Anwendern wichtige Komponente der frühen Phasen verschiedener UI-Entwicklungs-Methodiken– Liefern Einsichten in individuelles Verhalten und

organisatorischen Kontext– Fokus: User Interface– Anders als bei allgemeinen ethnographischen Beobachtungen,

Beobachtung nur im Zeitraum von Tagen oder Stunden gegenüber Wochen und Monaten

– Risiken: • Misinterpretation von Aussagen und Daten• Störung der normalen Arbeitsvorgänge• Übersehen wichtiger Aspekte

16


Ethnographische Studien (II)

Vorbereitung– Verständnis der Organisationstrukturen, (Firmen-) Politik und

Arbeitskultur– Kennenlernen des Systems und dessen Geschichte – Formulierung initialer Ziele und Vorbereitung von Fragen– Zugang und Erlaubnis zur Befragung

Feldstudie– Schnittstellen mit Management und Anwendern – Beobachtung/Interview von Anwendern an ihren Arbeitsplätzen

zur Sammlung subjektiver und objektiver Daten (qualitativ und quantitativ)

– Verfolgung aller Spuren, die sich bei dem Besuch ergeben


Ethnographische Studien (III)

Analyse– Zusammenstellung der gesammelten Daten aus den

verschiedenen Datenbanken– Quantifizierung von Daten und Erstellung von Statistiken– Reduzierung und Interpretation der Daten– Verfeinerung von Zielen und Prozessen

Reporting– Berücksichtigung verschiedener Zielgruppen und Ziele– Erstellung des Reports und Präsentation der Erkenntnisse

17


Participatory Design (I)

Ansatz im Design, bei dem Anwender aktiv in den Entwurfsprozess mit eingebunden werden

Ziele– Produkt befriedigt die wirklichen

Bedürfnisse der Anwender– Produkt ist benutzbar (usable)


Participatory Design (II)

Ansatz wird kontrovers bewertet

Positive Aspekte der größeren Einbindung der Nutzer– Genauere Informationen über die Aufgaben, die die Anwender zu

bewältigen haben – Mehr Möglichkeiten für die Anwender, Design-Entscheidungen zu

beeinflussen – Ein Gefühl der Einbindung in die Entwicklungsprozesse

• Positiver Effekt für das Ego!– Potentiell eine höhere Nutzerakzeptanz des finalen Systems

18


Participatory Design (III)

Risiken und negative Aspekte – Höherer Kostenaufwand– Höherer Zeitaufwand – Kann zur Ablehnung von solchen Personen führen, die nicht in

den Gestaltungsprozess einbezogen oder deren Vorschläge abgelehnt wurden

– Kann Designer dazu zwingen, Kompromisse im Design aufgrund von Wünschen inkompetenter Teilnehmer einzugehen

– Kann Widerstand gegen die Implementierung aufbauen – Verstärkung persönlicher Konflikte zwischen Mitgliedern des

Design-Teams und Anwendern– Kann belegen, dass Firmenpolitik und individuelle Vorlieben und

Ziele einzelner Entscheidungsträger wichtiger sind als technische Fragestellungen


Participatory Design (IV)

Ebenen der Partizipation nach Druin, 2002 (angwendet bei Kindern)– Tester: werden bei der

Benutzung eines neuen Designs beobachtet

– Informant: Kommentierung des Designs durch Interviews und Focus Groups

– Design Partner: aktiver Partner im Design Team

19

07.11.08 Folie 39

Szenario-basiertes Design

Iterativer Ansatz zur Analyse und zum Design interaktiver SystemeVergleichbar zu anderen Usability-Engineering-Ansätzen – Anforderungsanalyse,– Design – Prototyping– Evaluation – Dokumentation

Hauptunterschied – User Interaction Scenarios in Form von Geschichten als

kontinuierliche Quelle für Einsichten und Schlussfolgerungen in Bezug auf die Anforderungen und Erfahrungen von Anwendern

07.11.08 Folie 40

Ziele des Szenario-basierten Designs

Beschreibung des Problems und seines Umfelds mit seiner gesamten Komplexität

Gestaltung nicht lediglich des Informationssystems, sondern des gesamten Nutzungskontexts

Einbeziehung von Nutzern, die keine Expertise in der Computernutzung oder dem Systemdesign aufweisen

20

07.11.08 Folie 41

Nutzen von Szenario-Beschreibungen

Explizit machen der Nutzung und damit allgemeinere Betrachtung der Anwendung

Fokussieren auf Benutzer, ihre Aktivitäten und ihre Anforderungen

Erfassung insbesondere auch von Erfahrungswissen aus dem Anwendungskontext

Möglichkeit zur Beschreibungen, wie Technologien die Aktivitäten verändern kann

Möglichkeit der Entwicklung vor der Realisierung des eigentlichen Systems und damit Sichtbarmachung der Auswirkungen im Vorfeld

07.11.08 Folie 42

Elemente desSzenario-basierten Design

Komponenten– Szenarios: Stories im

Anwendungskontext– Ansprüche (Claims)– HCI Methoden und Konzepte

Aspekte– Szenarios werden analysiert

unter spezieller Berücksich-tigung der jeweiligen Anforde-rungen (Claims) sowie allge-meiner HCI Grundlagen-kenntnisse

– 3-stufiger, iterativer Prozess aus Analyse, Design und Evaluation

21

07.11.08 Folie 43

Grundelemente von Szenarios

Setting– Ausgangspunkt für die in der Story beschriebenen Episode

Akteure, Agenten– Handelnde Personen

Ziele der Akteure– Mindestens ein Ziel– Genau ein grundlegendes Ziel (Defining Goal)

• Antwort auf die Frage „Warum ist diese Geschichte passiert?“

Handlung– Aktionen und Ereignisse

07.11.08 Folie 45

Einsatzmöglichkeiten von Szenarios (I)

Problembeschreibung (Problem-Szenarios)– Aktuelle Praktiken und Problematiken

System-Vision (Activity Scenarios)– Festlegung der Grundkonzepte

Design-Entscheidungen– Analyse der Systemvision, Abwägung von Konsequenzen

Festlegung von Usability-Faktoren– Identifizierung und Beschreibung spezifischer Ziele (z.B.

Performance, Nutzerzufriedenheit)

Funktionale Spezifikation– Identifikation von Anforderungen an Systemfunktionen

22

07.11.08 Folie 46

Einsatzmöglichkeiten von Szenarios (II)

Prototypen– Grundlage für Definition und Entwicklung

Objektmodell– Grundlage für Definition und Entwicklung

Formative und summative Evaluation– Design-Ziele auf Grundlage der Szenarios

Dokumentation, Schulung und Hilfefunktionen– Kontextspezifische Beschreibungen und Hilfe – Identifizierung von Situationen, in denen Unterstützung benötigt

wird

07.11.08 Folie 48

Claims

Claims als Beschreibung der Vor- und Nachteile eines Szenarios– Systematische Erhebung und Dokumentation für alternative

Szenarios– Grundlage für Diskussionen und die Entwicklung gemeinsamer

Lösungen– Dokumentation der Lösung in Form eines neuen Szenarios

Zielsetzung– Reduktion der Nachteile– Betonung der Vorteile

23

07.11.08 Folie 52

Szenario-Entwicklung

Day-in-the-life Szenarien– Beschreiben was passiert, wenn Anwender eine typische

Aufgabe bearbeiten– Erstellung auf Grundlage eines Walkthoughs– Grundlage weiterer, detaillierterr Analysen

• z.B. Videoaufnahmen spezieller Bearbeitungssequenzen

Nützliche Werkzeuge – Tabelle mit Nutzergruppen (z.B. Spalten) und Aufgaben (z.B.

Zeilen) – Tabelle der Augabensequenzen – Flussdiagramm oder Transition Diagram

07.11.08 Folie 55

Beispiel: Web-DesignSzenario 1

Szenario– Student der Stanford University im Studiengang Learning Design

and Technology (LDT)

Actor– Jane hat sich im Juni für den Studiengang LDT eingeschrieben.

Zuvor hat sie für mehrere Jahre im Erziehungsbereich gearbeitet. Sie interessiert sich sehr für das Themengebiet der Entwicklung von Technologien für Lehr- und Lernzwecke. Sie weiß noch nicht genau, wo sie nach ihrem Abschluss arbeiten möchte, aber sie hofft auf eine Stelle in einem Softwareunternehmen, das Lernsoftware entwickelt, bei der Kreativität gefragt ist. Zur Zeit sucht sie nach einem interessanten Thema für ihre Master-Arbeit.

nach: Miller 2001

24

07.11.08 Folie 56

Beispiel: Web-DesignSzenario 1

Background– Bachelor-Abschluss, gute Kenntnisse der Computernutzung,

Microsoft Office Software, mittlere Kenntnisse von Web Publishing Werkzeugen (z.B. Macromedia Dreamweaver™) und Graphiksoftware (z.B. Adobe Photoshop™).

Problem-Szenario– Jane muss einen Themenvorschlag für ihre Master-Arbeit

einreichen und sucht nach Ideen. Sie surft im Netz und hofft dort Inspirationen zu bekommen. Sie forscht für Stunden im Web, aber sie ist nicht besonders produktiv, da die für sie relevanten Informationen verteilt auf vielen verschiedenen Web-Seiten zu finden sind. Für sie wäre eine einzelne Seite, die einen Überblick über das Themengebiet „Gestaltung und Lernsoftware“ geben würde, sehr hilfreich.

nach: Miller 2001

07.11.08 Folie 62

Claims Analysis für dasWeb-Design Problem-Szenario

Ansatz– Web als Quelle für Ideen für das Redesign

Claims+ Web als gute Quelle für Untersuchungen und Forschung+ Bequeme Form, um Nachvorschungen durchzuführen - Riesige Datenmengen- Zeitaufwendig, Informationen zu analysieren und relevanten

Informationen zu finden- Spezielle Fähigkeiten notwendig, das Web effektiv nach

relevanten Informationen zu durchsuchen- Finden von Informationen über Design-Ansätze äußerst

unwahrscheinlich, da solche Informationen in der Regel nicht publiziert werden

25

07.11.08 Folie 63

Claims Analysis für dasWeb-Design Problem-Szenario

Ansatz:– Datenbank, die Beschreibungen verschiedener Design-Ansätze

enthält

Claims+ Einfacher, schneller Zugriff+ Schneller, prägnanter Überblick über Konzepte+ Vergleich einzelner Ansätze einfach möglich+ Einfach referenzierbar - Sammlung der notwendigen Informationen und Erstellung der

entsprechenden Übersichten äußerst aufwendig

07.11.08 Folie 66

Activity-Szenario

Grundlage– Als relevant befundene Problem-Szenarios– Claims der entsprechenden Szenarios

Aspekte– Darstellung erster Ideen über neue Funktionalitäten– Neue Sichtweisen über die Bedürfnisse der Nutzer

26

07.11.08 Folie 67

Beispiel: Web-DesignActivity-Szenario 1

Activity Szenario– Im Studiengang LDT versteht man die Probleme von Jane und

man möchte ein Informationssystem aufbauen, mit dem sich Studenten im Rahmen von Master-Projekten über Ideen und Gestaltungsentwürfe für Lehr- und Lernmedien informieren können. Entsprechende Materialien sollen dabei in den folgenden Jahren jeweils im Rahmen von Seminaren und Projekten von Studententeams des Studiengangs gesammelt werden (z.B. in Form von Interviews von Experten), aufbereitet und in das Informationssystem integriert werden.

nach: Miller 2001

07.11.08 Folie 68

Beispiel: Web-DesignActivity-Szenario

Activity Szenario (Forts.)– Bilder sollen dabei in dem System zur einfacheren Erkennung im

Index der verschiedenen Informationen verwendet werden. Zudem soll der entsprechende Designer - falls er einer speziellen Design-Schule angehört – auch in der Nähe des Namens der jeweiligen Schule angeordnet werden. Während für Studenten gegenseitige Einflüsse zwischen Gestaltern nicht relevant sind, sind entsprechende Informationen für Professoren sehr wichtig. Daher soll diese Information entweder über einen Link oder eine spezielle Suche verfügbar gemacht werden. Diese Informationen sollen dabei während der Interviews speziell erfragt werden. Um den Nutzen verfügbarer bibliographischer Links und Materialien von Designern zu maximieren, sollen Web-Seiten verwendet werden.

nach: Miller 2001

27

07.11.08 Folie 75

Zusammenfassung

Design-Methodiken zur – Umfassende Design-Methodiken

• LUCID• IBM Ease of Use Development Methodology

– Techniken, die spezielle Aspekte betonen• Ethnographische Studien• Participatory Design• Szenario-basiertes Design


Aufgabe

Lesen Sie folgendes Paper:‣ Cognetics Corporation: The LUCID Design Framework, 1998‣ http://ei.cs.vt.edu/~cs3724/notes/lucid-overview.pdf

28


ENDE

Human Computer Interaction · Der Design-Prozess ist kreativ und nicht vorhersagbar Gestalter...

Documents

Transcript of Human Computer Interaction · Der Design-Prozess ist kreativ und nicht vorhersagbar Gestalter...