CCT 333: Imagining the Audience in a Wired World

Class 10: Prototypes, Evaluation and Retirement

On to redesign…

• Understand nature of the problem• Do user studies (qualitative/quantitative) to

understand current problems with technology in context

• Build scenarios to determine requirements of what should be done

• Then do it (but only then!)

Prototypes

• Good intermediate step before final design (or in this case, what you’ll be presenting in most cases)

• Basic functionality is represented• Redesign goals are made functional,

accessible

Why prototypes?

• Obtaining feedback on redesign• Ensuring concepts are correct before making

major mistakes• Assessing usability of redesign in practice• Opening avenue for alternative options if

required• Involving users and achieving buy-in

Low-fidelity protoypes

• Easily made, easily changed, easily destroyed• Cheap materials• Focuses on broad details of redesign vs.

specific details (although core details of the redesign are represented)

• Does not leave the user the impression that design is final

Lo-fi considerations

• Robustness – often needs to be overengineered to encourage play

• Scope – don’t sweat the minor or inconsequential details (e.g., aesthetic concerns aren’t a major issue here…)

• Should be usable as intended – if too many instructions are required, that’s no good

• Annotation – users should be able to offer comments on elements

High-fidelity prototypes

• Especially common in electronic products and software, but also possible for other spaces.

• Strong attention to detail, resembling final form

• Can probably be misconstrued as final product

Perennial beta

• Why is everything in social media/Web 2.0 “beta”?

• What is beta? Alpha?

Prototypes in use

• IPS example – PICTIVE method used to develop low-fi software prototypes (paper, string, etc. to represent data flow in hands-on environment)

• Hi-fi prototypes constructed from plans as proof of concept, returned to students for input and approval

IMPACT

• Intention• Metrics• P• A• C• T

Intention

• What you trying to prove in evaluation?• Early prototypes – general proof of concept• Later – more attention to detail, specific

features• Weighting of requirements -

Metrics

• “Never measured, never managed” – managers really enjoy quantitative evidence

• Should be tied to evaluation of redesign, alternative future paths

• Limit data at this point – summary information vs. raw data from research

Effectiveness, Efficiency, Satisfaction

• Effectiveness – task completion, error rates reduced, memorability

• Efficiency – time to task completion, reduction of steps, learning curve

• Satisfaction – general aesthetic impression and emotion feel, voluntary use

Product Lifecycle

• No design is ever “done” – even when released, there’s often teams of people trying to figure out what’s next

• Requirements weighting – sometimes you have to release something and make the rest version 2.0

• Microsoft’s model – prototype as product, eventually getting it right

Retirement

• Plans for end-of-life important as well - some designs EOL better than others.

• Environmental concerns – increasingly companies held accountable for disposal – examples?

• Support for dead technologies – even if no longer sold, consumers expect some support – examples?

Next week(s)

• Next week – perhaps a guest lecture, perhaps something on CSCW

• Week after – presentation of final projects, test review