State Mapping Redux


Published on

This is the second, slightly shorter version of my presentation on State Mapping, as delivered at RedUXDC 5/9/2009.

Published in: Technology, Education
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

State Mapping Redux

  1. 1. In the nascent days of the “interweb”, the metaphor of the “site” was appropriate because all you really did was go from one place to another. The journey was the experience, and the site map did a good job of describing it.
  2. 2. [ auto-scrolling on mouse position [ dynamic compare panel [ AJAX-driven detail panel! [ auto-position quick links Now, the experience is a whirl of features and functions…
  3. 3. …that demand a better understand of the user of the system, and his needs and values. So we started to create personas.
  4. 4. Then, we needed scenarios to help us describe the actions of our personas over time. It soon became evident that not everyone does things in the same order, or for the same reasons.
  5. 5. Even though these representations of structure, person, and activity are accurate, they each fail to fully describe a dynamic, multi-modal interaction.
  6. 6. One possible alternative is the State Map. Let’s look at some ways this method can add flexibility and value to our interaction design toolkit. 1. Defining a concept
  7. 7. Simple objects, whether a doghouse or a website with static content, can still be defined by their structure.
  8. 8. Complex, interactive systems can’t. The structure of a site like facebook barely scratches the surface of its value proposition. Even understanding what all these pages mean and doesn’t adequately describe the interaction and engagement.
  9. 9. We know what each kind of car can do, but don’t immediately see the many ways they can be used by specific people in specific situations.
  10. 10. The real problem is that when you are here… …you really are HERE. Nearly every page, and more importantly every feature and function, is within a single click.
  11. 11. The whole must be greater than the sum of its parts. To really define the concept, you need the specificity of the use case with the engagement and temporal context of the scenario. You need a state map.
  12. 12. Mapping a single journey. This diagram describes one of many possible journeys. It’s a state map, but not a very interesting one.
  13. 13. A single line of interaction for a single targeted user shows how the activities align with the structure of the site.
  14. 14. Mapping multiple journeys concurrently. As we layer in the primary interactions of many targeted users along a relative timeline, we begin to see the relationships that define a unified solution.
  15. 15. Multiple lines of interaction shows how activities relate to specific personas or segments. Plotting the activities on a relative timeline demonstrates how the same interaction may take place in a different context for a different segment.
  16. 16. Mapping the total ecosystem of interaction. Now we see not only the specific journeys that each individual takes, but also all of the inbound paths that influence them and all of the possible resultant ancillary actions .
  17. 17. The finished state map, displaying a plurality of targeted personas, related interactions, and key business metrics and outcomes. The points of intersection describe not only a potential change in segment, but also a different state in which the same activity is performed.
  18. 18. Of course, once you’ve defined your concept, someone might just ask you to execute it. 2. Specifying a Design
  19. 19. Unlike the early days of interactive development, you can’t “just do it”. You have to design the details and lace them into a cohesive system or solution. One way you can use the state map is to specify a design, either for developers to build or for the QA team to test.
  20. 20. a flowchart a wireframe a prototype duh
  21. 21. Wireframes are too static. They only show a single view of the system at a time. In complex interactive systems, each wireframe is like a single frame in an action movie. What led me to this point? What will happen next? What the @#$* is going on here?
  22. 22. Flowcharts are too abstract. They describe all of the possible pathways through a system, but with inappropriate detail. They focus on what the system can do, not what the user is doing. The symbolic language of flowcharts is very arcane. And most are much more complicated than this one.
  23. 23. Prototypes have problems, too. They only show a single instance of a single interaction at a time. They don’t demonstrate all the things that can happen, only what actually does happen. They tend to be expensive to build, either in resources or time. Most prototypes end up like this one. Or should.
  24. 24. An example State Map showing how points are accrued for each activity on a social interaction website for breast cancer patients. * This diagram alone was the Business Requirements Document for points accrual in this system.
  25. 25. The State Map is also useful when comparing systems or solutions that do the same thing, but in different ways. 3. Evaluating Solutions
  26. 26. “Is everyone enjoying these silly images?” Sometimes, you don’t have the answer. Hard to believe, painful to admit…but true.
  27. 27. You know the players, even the plays…but what is the plan? Whether for due diligence or inspiration, your next step is to look at various existing offerings and evaluate them against your research and instincts.
  28. 28.  The first step is to identify the needs and values of each targeted persona and assign either a representative task or a solution.  Then we apply affinity mapping and annotation to identify solution modules or nodes.  Looking at each interaction in a scenario, you can plot the behaviors, capabilities, and limitations of each potential solution.  Use grouping and bounding where features are similar but not the same, and be sure to identify which key audiences are well served by each attribute.
  29. 29.  Iterate for each scenario and soon all the modalities are accounted for.  As each solution layers in, gaps become evident and a favorite begins to emerge.  Additional layers of information can be added if desired.
  30. 30. No lemon zester!?! Of course, every tool has limitations, and the state map is not the answer to every problem. But it is a new way of managing the complexity of interactive applications and systems. I hope you will find it useful.