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