Lecture+10

// CCT333 – Lecture 10 // // March 16, 2009 // 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 Prototype? -  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 Prototypes: -  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 with the impressions that the design is final Lo-fi Considerations: -  Robustness – often needs to be over engineered to encourage play -  Scope – don’t sweat the minor or inconsequential details (ex. 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”? -  Beta – just right before prime time, still in the developing stage -  Alpha – becoming something that is increasingly real 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 Intention: -  What are you trying to prove in evaluation? -  Early prototypes – general proof of concept? -  Later – more attention to detail -  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 rate reduced, memorability -  Efficiency – time to task completion, reduction of steps, learning curve -  Satisfaction – general aesthetic impression and emotional 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 -  Support for dead technologies – even if no longer sold, consumers expect some support .
 * Prototypes, Evaluation and Retirement **