CCT 333: Imagining the Audience in a Wired World

1. CCT 333: Imagining the Audience in a Wired World Class 10: Prototypes, Evaluation and Retirement

2. 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!)

3. 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

4. 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

5. 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

6. 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

7. 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

8. Perennial beta • Why is everything in social media/Web 2.0 “beta”? • What is beta? Alpha?

9. 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

10. IMPACT • Intention • Metrics • P • A • C • T

11. Intention • What you trying to prove in evaluation? • Early prototypes – general proof of concept • Later – more attention to detail, specific features • Weighting of requirements -

12. 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

13. 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

14. 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

15. 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?

16. Next week(s) • Next week – perhaps a guest lecture, perhaps something on CSCW • Week after – presentation of final projects, test review