Identifying Requirements: Difficult part of design process. Understanding domain area. Understand the users and stakeholders. Determine what your human interface and interaction will be. Techniques to SSNif out whatʼs needed and determine usage scenarios. Imagine the Future.
“The best way to predict the future is to invent it.”
Using stories as a design tool: Stories are scenarios. Scenarios are use cases. Use cases can be analyze using task analysis. Task analysis looks at how effectively and efficiently users reach their goals.
You can see that the story is complete when you can observe the different story components lead to a conclusion. Try to incorporate this level of definition and detail in the usage scenarios you create for your designs.
Anatomy of a Scenario: User – This is the central POV from which the user experience unfolds. Stakeholders – A person, group, organization, or system that affects or can be affected by the existence of the user experience. Goal – The planned intent to achieve or bring about a specific result. It is the anticipated result, which guides the actions of the user. Context – The environment or surroundings where the userʼs actions take place. Outcome – The userʼs ability to perform actions after the experience. User Scenarios&hellp;
SSNifs & Requirements: Philip Haine, User Experience Interaction Designer: Situation, Stakeholder, Need, Feature (SSNifs). Stakeholder - User or customer, in some situation. Situation - Context, setting or environment. Need - A condition or situation in which something is required or wanted. “SSNifing”
“SSNiF out the domain to make sense of it”
Big SSNifs: Why the product is needed. Little SNNifs: Working out the details. Design Pyramid: Understanding: Research and analysis about customers and their needs. Vision: Sift through the all the Big SSNiFs and sculpt a product vision. Requirements: Play out the Big SSNiFs into lots of little SSNiFs → requirements. Design: Create a solution with the scenarios by walking through the SSNiF scenarios & testing the design.
Use Cases: Originally developed by Ivar Jacobsen to help software developers analyze the way users typically interact with a system. Actors: Any one or thing that interacts with your system. Users, databases, companies, other systems, etc. Use case diagram: Shows how the tasks and actors relate to each other. Use case scenario: Details steps and actors involved for a specific task. Additional use case(s) needed (e.g., extensions). Details steps and actors involved for a specific task.
Task Analysis:: Procedural analysis: Procedures = Steps in a particular task. Job analysis: Job = All tasks part of overall goal or job. Workflow analysis: Workflow = Flow of information and control needed to complete a process. May include multiple people and tasks. Error analysis: Errors = Mistakes that can occur in any of above.
Levels of task analysis for web application. Big picture: Who are the user groups that will use the web application? How (if at all) will they interact with other users? What are they trying to do? Individual page view: What display/view/pages will the user use to accomplish their goal? Procedures in page view: What steps will the user go through on each page view?
Making improvements to tasks:: Consistency: If appropriate, make similar tasks work and look the same. Brevity & clarity: Try to make your tasks shorter if you can do so without sacrificing important functionality. Combined functionality: Reduce redundancy. Are there ways to group tasks? Are there tasks the user does more than once that can be remembered?
Homework & Reading: In your group: Update your Requirements Analysis Reports to include SNNifs. Create a Use Case/Task Analysis report that describes how your application will work. Feature/Functionality specification. Create use cases for all main tasks. Perform task analysis on use case steps. Due start of class, next week. Read chapter 5 in textbook.
Buttons and t-shirts
Robots are everywhere. Enough to build an army. I must record them all.
