Upload
laureen-turner
View
222
Download
0
Embed Size (px)
Citation preview
Brugergrænseflader til apparater BRGA
Presentation 6:
The Usability Engineering Lifecycle
2
Outline
• When to apply?
• Choosing the Software Engineering Process
• User Involvement
• Iterative design and prototyping
• Design rationale
• Meta-methods
When to Apply Usability Engineering
4
When to Apply Usability Engineering
• Not a ”one shot affair”
• Throughout entire product lifecycle
• Tied to software engineering /development process • ROPES, RUP, SPU or Agile Methods, XP
• Software engineering • = discipline concerning software design process / life cycle
The Importance of the “right” Software Engineering Process
6
Software Engineering Process
• Why care about development methods?• Most engineering companies use development methods
to construct their products
• All usability work must therefore be situated in these
• Badly employed method endangers product usability
• Beck and Wells: existing methods do not work
• Certainly there seems to be problems:• Products and projects developed for years –> • Only to arrive at the marked with unwanted features and
bad user interfaces
7
Origins: civil engineering
Bridge building
Need to secure delivery
Specify everything!
Does not always work well- In a software development perspective
- Especially so in a usability perspective
- Promotes building the product right – not the right product
“The Waterfall Model”
Requirementsspecification
Requirementsspecification
Architecturaldesign
Architecturaldesign
Detaileddesign
Detaileddesign
Coding andunit testingCoding andunit testing
Integrationand testingIntegrationand testing
Operation andmaintenance
Operation andmaintenance
8
Design Fallbacks- Design fallbacks are one solution
- Problems with interactive systems
- Very expensive with long fallbacks
- Users do not understand Use Cases
or Class Diagrams and similar
lots of feedback!
Requirementsspecification
Requirementsspecification
Architecturaldesign
Architecturaldesign
Detaileddesign
Detaileddesign
Coding andunit testingCoding andunit testing
Integrationand testingIntegrationand testing
Operation andmaintenance
Operation andmaintenance
9
Iterative Rapid Development Proces
Spiralmodel
End target
Start
ROPES
Iterations helps significantly on usability problems (Bohm 1988)But if not verified – then useless
10
XP – an Alternative
• “XP is successful because it emphasizes customer involvement and promotes team work.” - Don Wells
• XP: eXtreme Programming is primarily a software engineering method, but Agile Methods may be used everywhere
• XP is too big of a topic for one lecture• Main points presented, focus on promoting usability
• Its up to you if you wish to use this method
11
The Rules and Practices of Extreme Programming
Planning• User stories are written• Release planning creates the schedule• Make frequent small releases• The Project Velocity is measured• The project is divided into iterations.
Iteration planning starts each iteration• Move people around• A stand-up meeting starts each day.• Fix XP when it breaks
Designing• Simplicity• Choose a system metaphor• Use CRC cards for design sessions.• Create spike solutions to reduce risk.• No functionality is added early• Refactor whenever and wherever possible.
Coding• The customer is always available• Code must be written to agreed standards• Code the unit test first• All production code is pair programmed• Only one pair integrates code at a time• Integrate often• Use collective code ownership• Leave optimization till last• No overtime.
Testing• All code must have unit tests• All code must pass all unit tests before it can be released• When a bug is found tests are created• Acceptance tests are run often
Usability related issues have been highlighted
12
XP Project model
13
XP in Relation to Usability Methods
Cognitive WalkthroughFuture workshopsVideo prototyping
Field studiesUser tests
Prototyping / mock-ups
Heuristic Evaluation
Keystroke Level Analysis
Design Guidelines & Heuristics
14
XP vs. Traditional Methods SPU/OOA-OOD
• There is a reason for making requirement specifications• There is a reason for making legal contracts• Lack of trust between engineering company & customer only one• Need to control ”loose cannon” developers
• Silverbullet & gold plating• Conflict between what the customer thinks he needs – and what
he really needs (next time!)• HCI concludes user involvement is good – but expensive• Use XP and more trust instead of traditional methods
Iterative Design and Prototyping
16
Iterative Design and Prototyping
• Iterative design overcomes inherent problems of incomplete requirements -> but only when used right
• Prototypes is one way• most users have difficulties relating textual requirements to end products• get feedback on design faster• experiment with alternative designs / Nielsen: Parallel Design• fix problems before code is written• constructs the XP System Metaphor, developers & users• usage: simulate or animate some features of intended system
• Management issues• time• planning• non-functional features• contracts
17
Techniques for prototyping
Storyboards / Mock-ups prototypes with low fidelity (= precision)need not be computer-based – paper mock-ups
Limited func simulations = scenariosOne part of functionality provided by designersRAD tools may be used for these (Visual Studio)Most often mock-ups are okWizard of Oz technique
Horisontal / Vertical advanced prototypesDepending on what needs to be testedRAD tools are common for these Throw-away, incremental, evolutionary
Low-fidelity prototyping
19
Fidelity in Prototyping
• Fidelity refers to the level of detail• High fidelity
• prototypes look like the final product
• Low fidelity• artists renditions with many details missing
20
Why Use Low-fi Prototypes?
• Traditional methods take too long• sketches -> prototype -> evaluate -> iterate
• Can simulate the prototype• sketches -> evaluate -> iterate
• sketches act as prototypes• designer “plays computer”• other design team members observe & record
• Kindergarten implementation skills• allows non-programmers to participate
21
Nokia UsesPaper PrototypingExtensively
22
Advantages of Low-fi Prototyping
• Take only a few hours• No expensive equipment needed
• May use users (later) – may use Heuristic Evaluation / Cognitive Walkthrough with designers
• Can test multiple alternatives • fast iterations
• number of iterations are tied to final quality
• Almost all interaction can be faked
23
Wizard of Oz Technique
• Faking the interaction• from the film “The Wizard of OZ”
• “the man behind the curtain”
• Long tradition in computer industry• prototypes made of other equipment
• Much more important for hard to implement features• Speech & handwriting recognition
High-fidelity Prototypes & RAD Tools
25
Problems with Low-fi Prototypes?
• Doesn’t map well to what will actual fit on the screen• Realism low - cognitive load high (hard to draw)• Couldn’t hold in your hand - different ergonomics from
intended device (PDA, speech)• Timing in real-time hard to do • Some things can not be simulated (dragging/highlight)• Lack of interactive feedback (affordances)• Solution: Build more advanced prototypes
26
RAD Development
• Use RAD tools for Rapid Application Development Prototyping• PowerPoint, Word, HyperCard, Director, HTML-tools• JBuilder, Visual Studio (widgets) (for evolutionary)
• Produces: • Horizontal / Vertical High-fidelity prototypes
• Incremental & Evolutionary• Danger of ”it’s good enough” effect• User may sit next to the developer• Dangerous
27
Director Cast Flash / Shockwave
•Basic objects used in interface•Mainly multimedia in nature
•images, audio, video, etc.•synchronize with cue points
•Can take screenshots and provide both simpel and advanced navigational transitions (”change something” when button is clicked)
28
Visual Studio – Pocket PC
29
Director or Visual Studio?
• Prototyping tools • Director, Hypercard, PowerPoint, Frontpage• prototyping tools produce slow programs• May evolve to a certain degree – then throw away
• IDE tools with UI Builders • Visual Studio, Delphi• Uses the standard Widgets available• May eventually evolve to full product (warning!)• May take a longer time to get started with• Better for developers – not good for designers
30
Widgets
May not be available with embedded platform IDE’s
Design Rationale
32
Design Rationale
Design rationale: information explaining why a user interface is the way it is.
AKA – Styleguide or Designguide
Benefits of design rationale
• communication throughout lifecycle
• reuse of design knowledge across products
• enforces design discipline
• presents arguments for design trade-offs
• organizes potentially large design space
• capturing contextual information
• “one can always read the design rationale and understand why a certain path was chosen”
Meta-methods
34
Meta-methods
• Decide on which methods to employ for your project
• Make an illustrated plan of the usage (with some text)
• Write down how you would like to use the methods. How many users, which user, how often
• Get it reviewed
35
Læringsmåls alignment
• Når kurset er færdigt forventes den studerende at kunne:• Definere og beskrive forskellige typer af
brugergrænseflader til apparater og computere
• Definere og beskrive gængse teorier, metoder og retningslinier indenfor menneske-maskin-interaktion og anvende disse til at lave en brugervenlig brugergrænseflade til et givet apparat
• Designe og konstruere brugergrænsefladesoftware til udvalgte typer af brugergrænseflader
Vi har fået en Forståelse af Hvordan Usability passer indI hele processen.Vi har fået Prototyping Værktøjer