0
Blending  User Experience   &  Business Analysis  thinking in the Agile Customer Role Jeff Patton Thought Works jpatton@ac...
© Alistair Cockburn 2005-6  Slide  3 PEOPLE Learn Skills in a 3-stage Progression: Follow / Break Away / Achieve Fluency L...
Today I’ll cover 3 areas 1. What is user experience design? 2. Design & analysis practices useful for Agile customers 3. I...
By “Design” I mean the  decisions  we make regarding the software solution we choose to build. <ul><li>“ The hardest singl...
Garrett’s Elements of User Experience Model describes a series of dependent decisions.
Software user experience is built  from dependent layers <ul><li>Jesse James Garrett’s  Elements of User Experience:  http...
The surface layer describes finished visual design aspects Surface Skeleton Structure Scope Strategy
The skeleton describes screen layout  and functional compartments in the screen Surface Skeleton Structure Scope Strategy
Structure defines navigation from  place to place in the user interface task panes modal dialogs modal wizards Surface Ske...
The “places” in the user interface  are built to support user-task-centric scope <ul><li>user tasks: </li></ul><ul><li>ent...
Business goals drive user constituencies choices  and contexts supported to form strategy <ul><li>business goals: </li></u...
Garret’s Elements of UX stack can apply to the user experience of other complex products <ul><li>These layers of concern a...
Let’s look at the strategy for a product we all use:  the place we live <ul><li>goals: </li></ul><ul><li>live comfortably ...
What might I, and my other user constituencies, do to reach our goals? <ul><li>user tasks: </li></ul><ul><li>store food </...
Arranging tasks by affinity allows me to  think about contexts that best support tasks.  Contexts in a home have common na...
When designing a particular interaction context such as a “kitchen,” I optimize layout  and tool choices to support tasks ...
“ I’m going to spend a lot of time here, I want my  experience to be as pleasant as possible…” Surface Skeleton Structure ...
Underneath Garrett’s model is a simple 3 layer model
Norman’s simple model for a human  in pursuit of a goal  problem or goal  How I’d like to feel, or what I’d like to achiev...
Distilling this down to goals, tasks, and tools  goal task tool problem or goal  How I’d like to feel, or what I’d like to...
Software contains features that support a number of tasks and a number of goals software goals tasks tools features
When we think about quality of use experience, we need to re-think what we mean by quality.
Don Norman explains that beauty, at least for products, isn’t skin deep <ul><li>“ Attractive things make people feel good,...
Norman explains three characteristics of design to observe: Visceral, Behavioral, & Reflective <ul><li>Visceral </li></ul>...
Noriaki Kano asks us to consider quality as being composed of objective and subjective elements <ul><li>“ Discussions of q...
Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters  <ul><li>Mu...
When we include user experience design into a holistic design process, another model of  problem analysis and solution def...
Design alternates between analyzing the problem context and exploring possible solutions <ul><li>Often, design starts with...
Design alternates between analyzing the problem context and exploring possible solutions <ul><li>Often, design starts with...
Now let’s look at  practices  that a customer or product owner team users to move from problem analysis through to solutio...
Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li...
Collaborative centers around model building  <ul><li>[a model is] a description or analogy used to help visualize somethin...
Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
Representing our ideas as models allows us to detect inconsistencies in our understanding
Through discussion and iterative model building we arrive at a stronger shared understanding
Using that common understanding we can  work together toward shared objectives
Low fidelity card models are used to facilitate discussions and build common understanding <ul><li>Common model forms incl...
Collaborative modeling looks like this
Collaborative modeling sessions follow a simple, repeatable structure <ul><li>Use Collaborative Modeling Sessions to: </li...
Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li...
Business objectives describes why we’d choose to buy or build the software
Look for benefit to the buyer or builder of the software <ul><li>For software built for internal use: </li></ul><ul><ul><l...
When asking for business goals look for expressions of business problems or desired outcomes <ul><li>Express goals as busi...
Use a Goal Question Metric approach to identify appropriate goal metrics <ul><li>Leverage a simple approach from the GQM m...
Good business objectives help validate prospective solutions <ul><li>A good set of business objectives help us validate th...
Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li...
Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often ...
Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often ...
Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often ...
Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often ...
Software products support a variety of users and their goals.  software tasks features goals
In organizations where users are paid to use the software, user goals are driven by business goals  software tasks feature...
Design imperatives describe good characteristics the software should have based on the user type <ul><li>Inside your user ...
A good user model helps us identify functional scope and necessary characteristics of the software  <ul><li>A good user mo...
Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li...
Use simplified workflow models to organize user tasks and represent workflow – this is a  Story Map <ul><li>Draw a left to...
A good User Story as used in Scrum and other Agile approaches describes the use of the system <ul><li>The user story form ...
In practice user stories may be written to describe user tasks or the tools that support them  user story More task-centri...
Building a workflow model helps facilitate discussion – but requires a bit of space
Workflow or a reasonable sized system can fill a room
Discussions in front of workflow models are more productive
Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li...
Build paper prototypes from repositionable components
Test paper prototypes to determine if they’re usable
Finished prototypes are pieced together from moveable and removable paper components
Build navigation maps and storyboards to communicate UI design
Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li...
Prioritize task details by necessity to help visualize layers of functionality across the business process Draw a vertical...
Identify releases in spans of coherent functionality <ul><li>Choose coherent groups of features that consider the span of ...
Distill your release plan into a roadmap <ul><li>A roadmap serves to clearly communicate release level objectives to stake...
“ Bucketing” groups of major functionality or areas of task support is sometimes easier than feature by feature prioritiza...
Where to do all those practices fit in a typical Agile lifecycle?
The simple Scrum snowman process model
But, it’s commonly understood the snowman is missing a couple balls… Or, that it takes a taller snowman to model product c...
Agile development’s  nested planning cycles Iteration Plan Release Plan Product/Project Charter <ul><li>User Story or Prod...
planning & design increase in detail over time Feature Development detail course grain fine grain time Feature Design Deci...
feature testing and product evaluation each cycle affords course correction Feature Development detail course grain fine g...
Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another <ul><li>Customer/Product ...
Design and Coded Features Pass Back and Forth Between Tracks implement iteration 1 features <ul><li>gather user input for ...
The customer/product owner team steers development <ul><li>The customer/product owner team must: </li></ul><ul><ul><li>Und...
Blending  User Experience   &  Business Analysis  thinking in the Agile Customer Role Jeff Patton Thought Works jpatton@ac...
Upcoming SlideShare
Loading in...5
×

Blending User Experience and Analysis in the Agile Customer Role.

1,269

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,269
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
75
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • 5 (40)
  • Transcript of "Blending User Experience and Analysis in the Agile Customer Role."

    1. 1. Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton Thought Works jpatton@acm.org AgileProductDesign.com
    2. 2. © Alistair Cockburn 2005-6 Slide 3 PEOPLE Learn Skills in a 3-stage Progression: Follow / Break Away / Achieve Fluency Level 1: following ( shu ) Learn “a technique that works” (Success = following the technique) Level 2: breaking away ( ha ) Learn limits of the technique Learn to shift between techniques Level 3: fluent ( ri ) Shift techniques at any moment Possibly unable to describe the shifts We will use this progression throughout the course.
    3. 3. Today I’ll cover 3 areas 1. What is user experience design? 2. Design & analysis practices useful for Agile customers 3. Incorporating design and analysis practices into an Agile lifecycle
    4. 4. By “Design” I mean the decisions we make regarding the software solution we choose to build. <ul><li>“ The hardest single part of building a software system is deciding precisely what to build.” </li></ul><ul><li>-- Fred Brooks In his 1987 essay “No Silver Bullet” </li></ul><ul><li>&quot;A requirement is a relationship to a decision: If you get to make or change the decision, it's design to you; if you don't get to make or change that decision, it's a requirement to you.&quot; </li></ul><ul><li>-- Alistair Cockburn </li></ul>
    5. 5. Garrett’s Elements of User Experience Model describes a series of dependent decisions.
    6. 6. Software user experience is built from dependent layers <ul><li>Jesse James Garrett’s Elements of User Experience: http://www.jjg.net/elements/ </li></ul>
    7. 7. The surface layer describes finished visual design aspects Surface Skeleton Structure Scope Strategy
    8. 8. The skeleton describes screen layout and functional compartments in the screen Surface Skeleton Structure Scope Strategy
    9. 9. Structure defines navigation from place to place in the user interface task panes modal dialogs modal wizards Surface Skeleton Structure Scope Strategy
    10. 10. The “places” in the user interface are built to support user-task-centric scope <ul><li>user tasks: </li></ul><ul><li>enter numbers </li></ul><ul><li>enter text </li></ul><ul><li>enter formulas </li></ul><ul><li>format cells </li></ul><ul><li>sort information </li></ul><ul><li>filter information </li></ul><ul><li>aggregate information </li></ul><ul><li>graph data </li></ul><ul><li>save data </li></ul><ul><li>import data </li></ul><ul><li>export data </li></ul><ul><li>print </li></ul><ul><li>….. </li></ul>Surface Skeleton Structure Scope Strategy
    11. 11. Business goals drive user constituencies choices and contexts supported to form strategy <ul><li>business goals: </li></ul><ul><li>displace competitive products </li></ul><ul><li>motivate sale of other integrated products </li></ul><ul><li>establish file format as default information sharing format </li></ul><ul><li>… </li></ul><ul><li>user constituencies: </li></ul><ul><li>accountant </li></ul><ul><li>business planner </li></ul><ul><li>housewife </li></ul><ul><li>… </li></ul><ul><li>usage contexts: </li></ul><ul><li>office desktop </li></ul><ul><li>laptop on airplane </li></ul><ul><li>pda in car </li></ul><ul><li>… </li></ul>Surface Skeleton Structure Scope Strategy
    12. 12. Garret’s Elements of UX stack can apply to the user experience of other complex products <ul><li>These layers of concern apply not only to software but a variety of products. </li></ul><ul><li>In particular, products that support a wide variety of user tasks benefit from this kind of thinking. </li></ul>
    13. 13. Let’s look at the strategy for a product we all use: the place we live <ul><li>goals: </li></ul><ul><li>live comfortably </li></ul><ul><li>eat well </li></ul><ul><li>stay clean </li></ul><ul><li>be healthy </li></ul><ul><li>keep up with Jones’s </li></ul><ul><li>… </li></ul><ul><li>user constituencies: </li></ul><ul><li>me </li></ul><ul><li>spouse </li></ul><ul><li>child </li></ul><ul><li>… </li></ul><ul><li>usage contexts: </li></ul><ul><li>suburban neighborhood </li></ul><ul><li>near good schools </li></ul><ul><li>near shopping </li></ul><ul><li>… </li></ul>Surface Skeleton Structure Scope Strategy
    14. 14. What might I, and my other user constituencies, do to reach our goals? <ul><li>user tasks: </li></ul><ul><li>store food </li></ul><ul><li>prepare food </li></ul><ul><li>eat food </li></ul><ul><li>sleep </li></ul><ul><li>bathe </li></ul><ul><li>store changes of clothing </li></ul><ul><li>stay out of rain </li></ul><ul><li>entertain guests </li></ul><ul><li>entertain self </li></ul><ul><li>… </li></ul>Surface Skeleton Structure Scope Strategy
    15. 15. Arranging tasks by affinity allows me to think about contexts that best support tasks. Contexts in a home have common names we all know. Surface Skeleton Structure Scope Strategy
    16. 16. When designing a particular interaction context such as a “kitchen,” I optimize layout and tool choices to support tasks I’ll do there Surface Skeleton Structure Scope Strategy
    17. 17. “ I’m going to spend a lot of time here, I want my experience to be as pleasant as possible…” Surface Skeleton Structure Scope Strategy
    18. 18. Underneath Garrett’s model is a simple 3 layer model
    19. 19. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action action evaluation did that action deliver that results I expected? goal evaluation is my goal met or problem resolved? the world information and tools
    20. 20. Distilling this down to goals, tasks, and tools goal task tool problem or goal How I’d like to feel, or what I’d like to achieve the world information and tools take some action action evaluation did that action deliver that results I expected? goal evaluation is my goal met or problem resolved?
    21. 21. Software contains features that support a number of tasks and a number of goals software goals tasks tools features
    22. 22. When we think about quality of use experience, we need to re-think what we mean by quality.
    23. 23. Don Norman explains that beauty, at least for products, isn’t skin deep <ul><li>“ Attractive things make people feel good, which in turn makes them think more creatively…. making it easier for people to find solutions to the problems they encounter.” </li></ul><ul><li>-- Don Norman </li></ul>
    24. 24. Norman explains three characteristics of design to observe: Visceral, Behavioral, & Reflective <ul><li>Visceral </li></ul><ul><li>What is the products initial impact or appearance? </li></ul><ul><li>Behavioral </li></ul><ul><li>How does the object feel to use? </li></ul><ul><li>Reflective </li></ul><ul><li>What does the object make you think about? What does it say about it’s owner? </li></ul>
    25. 25. Noriaki Kano asks us to consider quality as being composed of objective and subjective elements <ul><li>“ Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. </li></ul><ul><li>Embedded in this objective-subjective split is the idea that objective quality pertains to the ‘conformance to requirements’ while subjective quality pertains to the ‘satisfaction of users.’” </li></ul><ul><li>--Noriaki Kano </li></ul>
    26. 26. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters <ul><li>Must-haves </li></ul><ul><li>The products must have this features for me to be happy </li></ul><ul><li>One dimensionals </li></ul><ul><li>The more of this I get, the better </li></ul><ul><li>Delighters </li></ul><ul><li>I love this element of the product! </li></ul>“ This car has many flaws. Buy it anyway. It’s so much fun to drive” -- from a NY Times review of the Mini Cooper
    27. 27. When we include user experience design into a holistic design process, another model of problem analysis and solution definition becomes useful
    28. 28. Design alternates between analyzing the problem context and exploring possible solutions <ul><li>Often, design starts with a candidate solution in mind. </li></ul><ul><li>Exploring the problem helps validate the solution. </li></ul><ul><li>As time passes, problem analysis activities are replaced by solution definition activities. </li></ul>problem analysis solution definition time business problems & goals analysis user research user modeling task analysis (how do users achieve goals today?) task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing
    29. 29. Design alternates between analyzing the problem context and exploring possible solutions <ul><li>Often, design starts with a candidate solution in mind. </li></ul><ul><li>Exploring the problem helps validate the solution. </li></ul><ul><li>As time passes, problem analysis activities are replaced by solution definition activities. </li></ul>problem analysis solution definition time business problems & goals analysis user research user modeling task analysis (how do users achieve goals today?) task design (how might users better reach goals?) user scenario writing Incremental release planning user interface design user story writing
    30. 30. Now let’s look at practices that a customer or product owner team users to move from problem analysis through to solution definition
    31. 31. Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li>Modeling business objectives </li></ul><ul><li>Modeling Users </li></ul><ul><li>Modeling workflow as user stories: User Story Mapping </li></ul><ul><li>Paper prototyping and usability testing </li></ul><ul><li>Planning & road-mapping </li></ul>
    32. 32. Collaborative centers around model building <ul><li>[a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed </li></ul><ul><ul><li>- Merriam-Webster on-line </li></ul></ul><ul><li>A goal of a model isn’t completeness or accuracy, but communication </li></ul><ul><li>For our purposes: </li></ul><ul><ul><li>a model is any visual representation of our current understanding of a concept </li></ul></ul><ul><li>We’ll build models to understand our problem context, and explore solutions </li></ul>
    33. 33. Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding
    34. 34. Representing our ideas as models allows us to detect inconsistencies in our understanding
    35. 35. Through discussion and iterative model building we arrive at a stronger shared understanding
    36. 36. Using that common understanding we can work together toward shared objectives
    37. 37. Low fidelity card models are used to facilitate discussions and build common understanding <ul><li>Common model forms include: </li></ul><ul><ul><li>Affinity diagrams </li></ul></ul><ul><ul><li>Chronological models </li></ul></ul><ul><ul><li>Decompositions </li></ul></ul><ul><ul><li>Ad hoc charts </li></ul></ul><ul><li>Mix and match as you see fit </li></ul>
    38. 38. Collaborative modeling looks like this
    39. 39. Collaborative modeling sessions follow a simple, repeatable structure <ul><li>Use Collaborative Modeling Sessions to: </li></ul><ul><ul><li>Build up tacit shared knowledge within the team </li></ul></ul><ul><ul><li>Build communication and collaboration skills within the team </li></ul></ul><ul><ul><li>Help the team to gel as an affective workgroup </li></ul></ul><ul><li>Prepare </li></ul><ul><ul><li>Write a short statement to set goals and scope for the session </li></ul></ul><ul><ul><li>Identify participants – 4-8 is ideal </li></ul></ul><ul><ul><li>Fill These Roles: </li></ul></ul><ul><ul><ul><li>Information Suppliers </li></ul></ul></ul><ul><ul><ul><li>Information Acquirers </li></ul></ul></ul><ul><ul><ul><li>Information Modelers </li></ul></ul></ul><ul><ul><ul><li>Facilitator </li></ul></ul></ul><ul><ul><ul><li>Documenter </li></ul></ul></ul><ul><ul><li>Schedule & set up work session facility </li></ul></ul><ul><li>Perform </li></ul><ul><ul><li>Kickoff with goals and scope </li></ul></ul><ul><ul><li>Get information figuratively and literally on the table using brainstorming or discussion </li></ul></ul><ul><ul><li>Model the information to clarify, add details, distill details, and understand relationships </li></ul></ul><ul><ul><li>Close by summarizing the results, on camera if possible </li></ul></ul><ul><li>Document & Communicate </li></ul><ul><ul><li>Capture model with photo and/or movie </li></ul></ul><ul><ul><li>Document as necessary </li></ul></ul><ul><ul><li>Post in publicly accessible place </li></ul></ul><ul><ul><li>Display as a poster </li></ul></ul>1 2 3
    40. 40. Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li>Modeling business objectives </li></ul><ul><li>Modeling Users </li></ul><ul><li>Modeling workflow as user stories: User Story Mapping </li></ul><ul><li>Paper prototyping and usability testing </li></ul><ul><li>Planning & road-mapping </li></ul>
    41. 41. Business objectives describes why we’d choose to buy or build the software
    42. 42. Look for benefit to the buyer or builder of the software <ul><li>For software built for internal use: </li></ul><ul><ul><li>Save money </li></ul></ul><ul><ul><li>Increase efficiency </li></ul></ul><ul><ul><li>Solve problems that are costing money or decreasing efficiency </li></ul></ul><ul><ul><li>Improve customer satisfaction </li></ul></ul><ul><ul><li>Generate revenue by supporting or improving service offerings </li></ul></ul><ul><li>For software built for commercial sale: </li></ul><ul><ul><li>Generate revenue through sale </li></ul></ul><ul><ul><li>Improve/expand market share </li></ul></ul><ul><ul><li>Open new markets </li></ul></ul><ul><li>The IRACIS* mnemonic helps us remember to look for business benefit that will </li></ul><ul><ul><li>Increase Revenue </li></ul></ul><ul><ul><li>Avoid Cost </li></ul></ul><ul><ul><li>Increase Service </li></ul></ul><ul><ul><li>* Gane & Sarson’s IRACIS model, 1977 </li></ul></ul>
    43. 43. When asking for business goals look for expressions of business problems or desired outcomes <ul><li>Express goals as business problems or business outcomes </li></ul><ul><li>It’s tempting for business stakeholders or users to describe their proposed solution as a goal </li></ul><ul><ul><li>Solution-centric goal: “I’d like a cost effective ski parka” </li></ul></ul><ul><ul><li>Problem-centric goal: “I’d like to stay warm and dry while skiing” </li></ul></ul><ul><li>Use root cause analysis to get behind solutions to goals and problems </li></ul><ul><ul><li>Toyota’s “5 whys” describes root cause analysis </li></ul></ul><ul><ul><li>Poking it with “the why stick” is often what my colleagues say </li></ul></ul>
    44. 44. Use a Goal Question Metric approach to identify appropriate goal metrics <ul><li>Leverage a simple approach from the GQM methodology </li></ul><ul><li>Identify and prioritize goals </li></ul><ul><li>Question each goal: </li></ul><ul><ul><li>If we were making progress toward this goal, how would we know? </li></ul></ul><ul><ul><li>What would change in the business as a result of reaching this goal? </li></ul></ul><ul><li>Use answers to these questions to identify metrics for goals </li></ul><ul><ul><li>Metrics help quantify ROI </li></ul></ul><ul><ul><li>Metrics helps justify ongoing development expense </li></ul></ul><ul><ul><li>The desire to track metrics often generate important product features </li></ul></ul>
    45. 45. Good business objectives help validate prospective solutions <ul><li>A good set of business objectives help us validate the solutions we choose to construct </li></ul><ul><li>A good set of business objectives are: </li></ul><ul><ul><li>short: a single page or slide </li></ul></ul><ul><ul><li>prioritized </li></ul></ul><ul><ul><li>measurable </li></ul></ul>
    46. 46. Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li>Modeling business objectives </li></ul><ul><li>Modeling Users </li></ul><ul><li>Modeling workflow as user stories: User Story Mapping </li></ul><ul><li>Paper prototyping and usability testing </li></ul><ul><li>Planning & road-mapping </li></ul>
    47. 47. Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often a job title or the common name for the type of user in a system </li></ul></ul><ul><li>User Role </li></ul><ul><ul><li>Short name describing a user in pursuit of a goal – users change roles as their goals change </li></ul></ul><ul><li>User Profile </li></ul><ul><ul><li>Adding summary information about the types of users who fill a role or perform as an actor begins a process of “profiling” </li></ul></ul><ul><li>Persona </li></ul><ul><ul><li>Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target </li></ul></ul>On-line Shopper: browse and purchase merchandise on line Customer Support Rep: aid customers over the phone and on line with issues
    48. 48. Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often a job title or the common name for the type of user in a system </li></ul></ul><ul><li>User Role </li></ul><ul><ul><li>Short name describing a user in pursuit of a goal – users change roles as their goals change </li></ul></ul><ul><li>User Profile </li></ul><ul><ul><li>Adding summary information about the types of users who fill a role or perform as an actor begins a process of “profiling” </li></ul></ul><ul><li>Persona </li></ul><ul><ul><li>Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target </li></ul></ul>Casual Browser: pass time by browsing products online Comparison Shopper: compare price and features for items I wish to buy Gift Shopper: find a gift for someone that likes the types of products this website sells Impatient Buyer: find what I need and get through the checkout process quickly
    49. 49. Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often a job title or the common name for the type of user in a system </li></ul></ul><ul><li>User Role </li></ul><ul><ul><li>Short name describing a user in pursuit of a goal – users change roles as their goals change </li></ul></ul><ul><li>User Profile </li></ul><ul><ul><li>Adding summary information about the types of users who fill a role or perform as an actor begins a process of “profiling” </li></ul></ul><ul><li>Persona </li></ul><ul><ul><li>Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target </li></ul></ul>Web Shoppers Users: 50,000 customer visit this sporting goods website monthly Activities: browsing, price comparing, gift shopping, handling returns Computer Skills: vary wildly from first time users to expert – although moderate computer skills are typical Domain expertise: typical customers are avid outdoor enthusiasts…
    50. 50. Common models such as actors, roles, profiles, & personas describe users <ul><li>Actor & Goal </li></ul><ul><ul><li>Often a job title or the common name for the type of user in a system </li></ul></ul><ul><li>User Role </li></ul><ul><ul><li>Short name describing a user in pursuit of a goal – users change roles as their goals change </li></ul></ul><ul><li>User Profile </li></ul><ul><ul><li>Adding summary information about the types of users who fill a role or perform as an actor begins a process of “profiling” </li></ul></ul><ul><li>Persona </li></ul><ul><ul><li>Choosing specific characteristics of a person and compiling those into a archetypal description of that person creates a strong design target </li></ul></ul>Steve races mountain bikes competitively. He shops the web on a regular basis to keep abreast of new equipment releases on the market, and to make sure he has the best equipment he can afford. He’s used computers for years and considers himself an expert user. He maintains his own website and blogs about his races and upcoming schedule. Steve relies on reviews from his peers to judge the quality of equipment. He often writes reviews of his own for stuff he’s tried out. Steve Powell competitive mountain biker “ I’m looking for stuff that’ll help me stay ahead of the pack”
    51. 51. Software products support a variety of users and their goals. software tasks features goals
    52. 52. In organizations where users are paid to use the software, user goals are driven by business goals software tasks features goals All these goals mean lots of tasks, and lots of potential features in our software
    53. 53. Design imperatives describe good characteristics the software should have based on the user type <ul><li>Inside your user model are clues about the type of user interface and user interface characteristics needed by your user. </li></ul><ul><li>Document these as design imperatives. </li></ul><ul><li>Think about: </li></ul><ul><ul><li>ease of learning </li></ul></ul><ul><ul><li>retention of learning </li></ul></ul><ul><ul><li>efficiency of interaction </li></ul></ul><ul><ul><li>reliability of interaction </li></ul></ul><ul><ul><li>user satisfaction </li></ul></ul><ul><ul><li>user convenience </li></ul></ul><ul><ul><li>necessity for proficiency </li></ul></ul><ul><ul><li>importance of accuracy </li></ul></ul>
    54. 54. A good user model helps us identify functional scope and necessary characteristics of the software <ul><li>A good user model helps: </li></ul><ul><ul><li>identify functional scope </li></ul></ul><ul><ul><li>identify necessary characteristics of the software </li></ul></ul><ul><ul><li>stakeholders understand and empathize with target users </li></ul></ul><ul><ul><li>validate proposed software solutions </li></ul></ul><ul><li>An effective user model is prioritized to help rule out unnecessary functional scope and design imperatives </li></ul>
    55. 55. Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li>Modeling business objectives </li></ul><ul><li>Modeling Users </li></ul><ul><li>Modeling workflow as user stories: User Story Mapping </li></ul><ul><li>Paper prototyping and usability testing </li></ul><ul><li>Planning & road-mapping </li></ul>
    56. 56. Use simplified workflow models to organize user tasks and represent workflow – this is a Story Map <ul><li>Draw a left to right axis representing time </li></ul>Identify high level activities performed by users of the system and place them above the time axis in the order that seams reasonable <ul><li>Within each activity, organize tasks in the order they’re most likely completed. There’s likely variation in how they’re completed – so arrange them in a typical order. </li></ul><ul><ul><ul><ul><ul><li>If you had to explain the process to someone, arrange them in the order you’d tell the story. </li></ul></ul></ul></ul></ul><ul><li>Fill in task details such as business rules or possible features that satisfy the tasks below each task. </li></ul>Task 1 Task 2 Task 3 Task 4 Task 5 Activity 1 Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) time
    57. 57. A good User Story as used in Scrum and other Agile approaches describes the use of the system <ul><li>The user story form considered “best practice” in Scrum references your user model and user goals. </li></ul>[achieve some goal ] so that I can [perform some task ] I want to [type of user ] As a purchase it quickly, leave, and continue with my day. so that I can locate a CD in the store I want to harried shopper As a
    58. 58. In practice user stories may be written to describe user tasks or the tools that support them user story More task-centric : More tool-centric : start with task-centric user stories early in product discussion and modeling fill in feature-centric stories till later software tasks features goals locate a specific CD in the store I want to harried shopper As a enter a CD title into the search box and initiate a product search I want to harried shopper As a
    59. 59. Building a workflow model helps facilitate discussion – but requires a bit of space
    60. 60. Workflow or a reasonable sized system can fill a room
    61. 61. Discussions in front of workflow models are more productive
    62. 62. Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li>Modeling business objectives </li></ul><ul><li>Modeling Users </li></ul><ul><li>Modeling workflow as user stories: User Story Mapping </li></ul><ul><li>Paper prototyping and usability testing </li></ul><ul><li>Planning & road-mapping </li></ul>
    63. 63. Build paper prototypes from repositionable components
    64. 64. Test paper prototypes to determine if they’re usable
    65. 65. Finished prototypes are pieced together from moveable and removable paper components
    66. 66. Build navigation maps and storyboards to communicate UI design
    67. 67. Let’s look at a few of many possible product owner team practices <ul><li>Facilitated collaborative work </li></ul><ul><li>Modeling business objectives </li></ul><ul><li>Modeling Users </li></ul><ul><li>Modeling workflow as user stories: User Story Mapping </li></ul><ul><li>Paper prototyping and usability testing </li></ul><ul><li>Planning & road-mapping </li></ul>
    68. 68. Prioritize task details by necessity to help visualize layers of functionality across the business process Draw a vertical axis to represent necessity Task 1 Task 2 Task 3 Task 4 Task 5 Activity 1 Task Detail (Story) Task Detail (Story) Task Detail (Story) Task Detail (Story) time Task Detail (Story) Task Detail (Story) necessity
    69. 69. Identify releases in spans of coherent functionality <ul><li>Choose coherent groups of features that consider the span of business functionality and user activities. </li></ul><ul><li>Support all necessary activities with the first release </li></ul><ul><li>Improve activity support with subsequent releases </li></ul>time optionality necessary less optional more optional activity 1 activity 2 activity 3 activity 4 first release second release third release
    70. 70. Distill your release plan into a roadmap <ul><li>A roadmap serves to clearly communicate release level objectives to stakeholders </li></ul><ul><li>For each incremental release: </li></ul><ul><ul><li>Give the release a name or simple statement describing it’s purpose </li></ul></ul><ul><ul><li>Write a short sentence or two describing what value the business gets from the release </li></ul></ul><ul><ul><li>Write a short sentence or two describing what value the users get from the release </li></ul></ul>EasyPOS Point of Sale Software Release 1: Replace the cash register Business: replaces gets rid of old manual cash registers and gets accurate up the minute sales information across locations Users: Cashiers get an easier to use cash register that helps them make less mistakes, correct them when they do, and save time balancing cash drawers every night.
    71. 71. “ Bucketing” groups of major functionality or areas of task support is sometimes easier than feature by feature prioritization
    72. 72. Where to do all those practices fit in a typical Agile lifecycle?
    73. 73. The simple Scrum snowman process model
    74. 74. But, it’s commonly understood the snowman is missing a couple balls… Or, that it takes a taller snowman to model product concerns
    75. 75. Agile development’s nested planning cycles Iteration Plan Release Plan Product/Project Charter <ul><li>User Story or Product Feature </li></ul><ul><li>Expressed from business or user perspective </li></ul><ul><li>Business value </li></ul><ul><li>Estimable </li></ul><ul><li>Feature List: prioritized features </li></ul><ul><li>(AKA Product Backlog) </li></ul><ul><li>Iteration </li></ul><ul><li>1-4 week timebox </li></ul><ul><li>Incremental Release </li></ul><ul><li>1-6 Iterations </li></ul><ul><li>Released internally or externally to end users </li></ul><ul><li>Product or Project </li></ul><ul><li>Perpetually released </li></ul>Product/Project Incremental Release Evaluate Iteration User Story Design Develop Evaluate Test Evaluate Plan Plan Plan
    76. 76. planning & design increase in detail over time Feature Development detail course grain fine grain time Feature Design Decide how the feature looks and behaves Iteration Plan Determine the features in the iteration and how they coherently hang together Release Plan Determine appropriate product features and the specific features in this release Project Charter Determine how the software will earn money, and the user constituents will be served
    77. 77. feature testing and product evaluation each cycle affords course correction Feature Development detail course grain fine grain Feature Design Test that the features look and perform as expected Iteration Plan Evaluate how features work together. Add, remove, or change features in the release Release Plan Evaluate the finished release. Will it be useful for its target audience? Will it earn the revenue expected?. Project Charter Evaluate the product direction as a whole. How can the product earn more revenue? Feature Test Iteration Evaluation Release Evaluation Product Evaluation time time
    78. 78. Parallel Track Development Separates Design and Evaluation Into One Track, Building Into Another <ul><li>Customer/Product Owner Team </li></ul><ul><li>Composition </li></ul><ul><li>Business Analysts </li></ul><ul><li>Interaction Designers </li></ul><ul><li>Prototypers </li></ul><ul><li>Responsibilities </li></ul><ul><li>Gather customer input for features to be implemented in later iterations </li></ul><ul><li>Design next iteration features </li></ul><ul><li>Be available to answer questions on current iteration development </li></ul><ul><li>Test features implemented in the previous iteration </li></ul><ul><li>Development team </li></ul><ul><li>Composition </li></ul><ul><li>Smaller number of seasoned developers </li></ul><ul><li>UI development skills & analysis skills </li></ul><ul><li>Responsibilities </li></ul><ul><li>Implement features for current iteration </li></ul><ul><li>Collaborate with Product Owner team to acquire details to construct software </li></ul>design & plan evaluate build
    79. 79. Design and Coded Features Pass Back and Forth Between Tracks implement iteration 1 features <ul><li>gather user input for iteration 3 features </li></ul><ul><li>design iteration 2 features </li></ul><ul><li>support iteration 1 development </li></ul>implement iteration 2 features fix iteration 1 bugs if any <ul><li>gather user input for iteration 4 features </li></ul><ul><li>design iteration 3 features </li></ul><ul><li>support iteration 2 development </li></ul><ul><li>validate iteration 1 features </li></ul>implement iteration 3 features fix iteration 2 bugs if any <ul><li>gather user input for iteration 5 features </li></ul><ul><li>design iteration 4 features </li></ul><ul><li>support iteration 3 development </li></ul><ul><li>validate iteration 2 features </li></ul><ul><li>planning </li></ul><ul><li>data gathering </li></ul><ul><li>design for iteration 1 features – high technical requirements, low user requirements </li></ul><ul><li>development environment setup </li></ul><ul><li>architectural “spikes” </li></ul>Iteration 0 Iteration 1 Iteration 2 Iteration 3 feature design coded features feature design + bugs found in usability testing current features Product Owner Team Development Team time
    80. 80. The customer/product owner team steers development <ul><li>The customer/product owner team must: </li></ul><ul><ul><li>Understand layers of dependent decisions that lead to stories in a backlog </li></ul></ul><ul><ul><li>Identify stories to meet release level business objectives </li></ul></ul><ul><ul><li>Defer decomposing and detailing stories until necessary </li></ul></ul><ul><ul><li>Re-prioritize and create new stories to allow business objectives to be met within time and budget constraints </li></ul></ul><ul><ul><li>Business objectives and user objectives are targets – user stories are the tools that help you reach them </li></ul></ul>
    81. 81. Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton Thought Works jpatton@acm.org AgileProductDesign.com
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×