ºÝºÝߣ

Editor's Notes

• #4: - Stories about people.- Fictional but grounded in reality.- Usually task / goal orientated i.e. doing something.- Usually outline the ¡®to be¡¯ but could equally outline how things currently happen
• #5: - Famous ¡®vision of the future video¡¯ Created by Sun MicrosystemsIn 1992 (now part of Oracle).- Attempted to predict and guide the future of computing ¨C set in 2004!.- Drew together the talents of more than 100 engineers, designers, futurists, and filmakers
• #6: - Maps out steps a user (e.g. persona) would take to complete a task or goal in the context of a scenario.- Might map out end to end user journey, or part of the user journey.- Captures steps together with comments, questions and ideas
• #7: - Nothing new.People have been breaking down complex tasks for hundreds of years.- From Fredrick Taylor¡¯s time and motion studies at the turn of the 19th century. - To more modern Ergonomics derived task analysis. - Scenario mapping just a different spin
• #8: - 1st encountered scenario mapping at Nielsen Norman seminar by Tamara Adlin and John Pruitt. - Referred to as both scenario and design mapping in the book (scenario for ¡®as is¡¯, design for ¡®to be¡¯)
• #10: - Need a decent amount of wall or table space. - Good idea to stick up some brown paper so that you can easily take down the scenarios afterwards.- Can also take a photo afterwards
• #11: - Ideally want 4 different colours. - Super sticky post-its can be useful (if you can find them) as they are more likely to stay stuck
• #12: - Ideally want designers, developers and domain experts. - Can be done individually but works best with a small group (e.g. 2 ¨C 5). - Too big a group makes agreeing a scenario more difficult.- Make sure that people are prepared for the session e.g. know the personas and the scenarios that will be worked through
• #13: - Focus on primary scenarios ¨C what are the key goals and tasks?.- What absolutely has to work well for the product to succeed? E.g. Finding & booking a holiday on the Thomson website. - Focus on sunny day scenarios first ¨C i.e. when things go right.- Danger is that otherwise easy to get tied up in knots
• #14: Try to focus on the ¡®what¡¯ not the ¡®how¡¯ and keep it reasonably high level.For each step note down- What the user does - remember to focus on what happens, not necessarily how it happen- Any comments or information that you feel is important at this step- Any questions or assumptions that arise are this step that you'll want to resolve- Any ideas or good suggestions that people have
• #15: - Don¡¯t worry about capturing too much detail ¨C that¡¯s not what scenario maps are for- Will also want to provide the context for the scenario e.g. What? Who? Where? Why? When? How often?
• #16: - Quick, simple & fun way to build scenarios- Aids collaboration & encourages discussion-Stops you getting lost in the detail- Forces you to consider the context in which a design is likely to be used
• #17: - During the research phase to analyse a current process e.g. a customer enquiry in a shop- Can be a useful way to capture observed tasks and to walk through a task with domain experts- Remember that what people say they do is often very different from what they actually do!
• #18: - Early in the design phase to establish the user interaction- You can start defining, discussing and evaluating the user journey without expending too much design effort- Likely to be iterative in nature ¨C can revisit scenario maps and map out parts of a map in more detail
• #19: - Key is to capture enough to move on with the design ¨C the aim is not to capture everything- Generally looking to map out the key usage scenarios i.e. 80 / 20 rule- Focus on sunny day scenarios ¨C although a good idea to cover problems if they could be quite common- Don¡¯t need to map out every conceivable scenario