Seeing the Forest for the Trees: Visual Problem Solving as a Design and Usability Tool

Editor's Notes

• #3: So I can get a feel for my audience, how many of you have read this book?
• #4: How many of you have read this book?
• #5: How many of you have heard of this person? How many heard of Ithaka? JSTOR? OK…a little background about me. I’ve worked for JSTOR for 4 and a half years. JSTOR and Ithaka have always been “affiliates”, but recently merged. Ithaka is a NFP organization that creates products and services that help the scholarly community find and use information that will be used in the knowledge creation process. JSTOR is a NFP digital archive that digitizes print content and makes it available online. We have content back to the 1600’s! I work in the Ann Arbor office. Before this I worked at a busy metropolitan hospital in Windsor, Ontario. I did research and created an information portal for busy clinicians. Before that I worked at Wayne State University in Detroit, MI. And I’ve done consulting work for the last two years. Why am I telling you all this? Because my presentation is empirically tested. Methodologies and tactics were used during real world, on-the-job experiences. What I’m presenting to you are the few success stories that I have to offer amongst my many failures. If wisdom comes from failure, I am truly wise indeed. We learn wisdom from failure much more than from success. We often discover what will do, by finding out what will not do; and probably he who never made a mistake never made a discovery. (Samuel Smiles)
• #6: What do you get when you combine all three? Today’s presentation. Dan Roam’s book was inspirational for me: it made the tumbler click and unlocked my thoughts about how effectively I was using the deliverables I created in my work. However, Dan’s book was more focused on the creation of visuals, while I was more interested in using visuals during problem solving processes. Luke’s book was more confirmational for me: he solidified a lot of ideas I had milling about in my head, but I didn’t really get a “new approach” or “new tactics” out of his book. I’ve had a lot of other inspirations, too. For example, Chauncey Wilson gave an excellent presentation on brainstorming at UPA 2008 that inspired me to get back to basics. I’ll mention some of them and some of them are listed on the handout I have for you today. But more than anything else, “Back of the Napkin” was a catalyst that helped me bring together many techniques I had been trying in a more formalized way. I will be referring to this book a couple of times during this presentation. My Ideology use “problem” and “project” interchangeably – every project is essentially a problem statement, is it not? I want to create a good user experience for my clients. Clients are users of my skills and I should give them a good experience AS WELL AS a good outcome (what ever I have been commissioned to produce, such as a design or recommendations). I believe that user experience professionals are not just responsible for creating a good outcome – we are responsible for creating a good experience surrounding our skills. Something Jared Spool spoke about in his opening plenary really resonated with me. He gave the story of the “Stone Soup”. A wandering traveller can’t get villagers to feed him so he asks for a pot and tells them he has a magic stone that makes soup. Soon curious villagers are gathered and asking questions. Through their curiosity, he gets them to contribute individual ingredients and soon has a pot of soup fit to feed the entire village. I strive to be like that guy with the stone who teaches people how to contribute and collaborate.
• #7: Visual problem solving is a way to more quickly look at problems, more intuitively understand them, and more rapidly convey to others what we’ve discovered. Visual problem solving is also a way of using our strengths as designers and “design interpreters” to help people “see” all the data surrounding a project/problem. As a methodology, VPS involves the identification, creation, and amassing of visual data and then employing tactics that use that visual data to communicate to and elicit information from other people. We all know how to “see”. While we all see differently, we can learn to take in data more effectively during problem solving activities and encounters with clients. While people may have different learning or communication styles, visual input can be a commonality. This presentation is not about cognitive science and visual thinking in that context, although cognitive science provides foundations for why VPS works. This presentation is also not about visual learning: as a learning style, visual learning has little to do with the tactics I’ll present. Any learning style and personality type should be able to work with the tactics to some degree. This presentation does not focus on all the different deliverables our profession produces. Look to Edward Tufte, Nathan Curtis, Peter Morville and others more skilled than I for that. There is no need to reinvent the “wall of deliverables” in this presentation. What I want to talk about is a way to put the professional skills and methodologies that we are already familiar with, to work for us in new ways. So my presentation is about repackaging what we might already know and maybe expanding our toolkit. The goal of my presentation is to inspire new ways of thinking about and using our “visualization” skills to solve problems that are caused by or encountered with what I will refer to as “client groups”. Outline: Work out some definitions as a group Outline a general methodology or approach Discuss four specific tactics to use with general methodology I will break for questions after each section.
• #8: I want to frame our discussion about problem solving by talking about who we encounter during our typical work, who causes problems, who helps solve problems, who blocks solutions, and who we likely have to communicate with on a regular basis. The premise of the VPS methodology is presenting visuals that demonstrate aspects of a problem and allowing other people to define the relationships between those visual data points. Allowing the people you work with to make meaningful connections themselves makes it more likely that they will invest in the solution, if not your vision. My categories are gross generalizations intentionally: I want this to be somewhat applicable to individual situations. I call them “client groups” because they are all clients/recipients of our work. What I want to do, as a group, is create a working definition for each of these three client groups. What we’re going to do next is some quick brainstorming. 30 seconds or so for each client group. Tell me who they are: roles, titles, stereotypes, whatever comes to mind.
• #9: Who can stakeholders be?
• #10: Who are technologists? Who have you worked with or read about?
• #11: When you hear the term “end user”, who do you think about? Think about who you’ve encountered in your various jobs: professionals, students, novices, experts, etc. Good. I think we have a picture of who might be the group or team I’ll be referring to during the rest of the presentation. Any questions?
• #13: Step one of the general approach is to identify all the questions surrounding your problem. Listed are Dan Roam’s six basic problem clumps. You might recognize them as the questions a good reporter or journalist asks. This is a simple way to approach an issue from many angles to ensure comprehensiveness of coverage. This is how I prepare for every meeting, even if I can only spend 5 minutes doing it. It helps me get a real grip on the problem statement by breaking it down into manageable chunks.
• #14: Step 2 is to identify visuals that might help address the questions identified. Dan Roam creates “showing frameworks” and a “visual thinking codex”. For each of the question clumps, he has created a guideline for the types of visuals you should create. Let’s do some quick brainstorming. Now thinking about these types of visuals, lets see if we can come up with some ideas of our own. What type of deliverables do you create or work with that could be categorized as a “portrait”? [go through all six] Now I am no expert on deliverables. I know how to do a handful of things really well, but my experience is not comprehensive. If you want guidance about what type of deliverables you should be creating, think Edward Tufte, Nathan Curtis, Peter Morville, etc. for all the different deliverables our profession produces. I’m not going to go over the visuals that can be produced – no need to recreate the “wall of deliverables”... [CLICK] But here were some of the ideas I came up with…
• #15: As part of identifying potential visuals, I also think about which visuals might speak to my audience. In trying to understand my audience, I might create a matrix about them…
• #16: The third step is to gather the visuals that we’ve determined can help address the problem. Any questions? Now that I’ve outlined the general methodology, we can get into the tactics. I’m going to show you four specific ways to put your visuals to work for you. Different tactics work with different people. You know your situation best. I’m just going to walk through four approaches that generally work for me.
• #17: Case study: I needed to get design direction approval out of a group of stakeholders and developers in two hours. I didn’t have time to get everyone on the same page and then get a decision, so I bombarded them with visualizations of the project and let them gravitate toward the visuals that “spoke” to them, that were engaging or interesting to them. They were given time to wander around the room, talk to each other, and think about things. No one was allowed to write things down or to leave the room. After, I engaged them in a directed discussion to get the answers and approval I needed. Types of deliverables in this case: - usage graphs Affinity diagrams from previous info gathering sessions printouts of bugs Summary of user complaints with graphs representing the % of user problems and mapped these to known system bugs when I could. usability test results Wireframes Feature usage grid A lot of times I visualize the same data in different ways and put it up in different areas so that it can be seen next to different things. I have also used this as a prelude to a cognitive walkthrough, to get people up to speed quickly on an unfamiliar design/product. If you can leave this up after the meeting or in a public place, you’ll be surprised at the connections people make and the feedback you can get. Don’t forget to provide a feedback mechanism.
• #18: This is just another form of affinity diagramming, but everyone is on the same level – moderator sitting at table with team. Everyone has same vantage point. Sometimes I like to make a dramatic case out of it, throwing a folder of stuff on the table and letting it slide. Mostly, I take the subtle approach and have the table set up for when participants arrive. Case study: For a consulting gig, I was brought in under the premise that I’d be working with a team whose goal it was to ultimately increase usage of the personal account feature on their website. I was brought in later in the game and told that the team had already determined development priorities and that I would just need to help them flesh out the design. When I got up to speed with the team, I realized that they couldn’t frame the problem: they had become fixated on their Google ranking and driving traffic to the site. They hade fcreated elaborate plans on how to increase site traffic, which might indirectly help increase the personal account usage, but would not solve the problem. They did not directly address the issue of personal account use because they couldn’t get a grop on what was wrong, so they fixated on something they cold define. Has anyone heard of the yellow bike shed story? It is a famous story originating from a management book that was published by …. In 1964. [more] So as the designer, do I just do what they want, create a great design based on their misguided direction? No. It was my responsibility to produce a good output and experience. I created visuals that addressed all aspects: site usage, personal account usage, feature usage. I had graphs, stats, clickstream analysis, customer calls/emails that I created personas for, competitive landscape with screenshots from competitors, summary of the current state of the feature, etc. Their first attempt at sorting produced two piles: “existing problems” and “ideas” Their second attempt produced three piles: “Data”, “Current”, and “Future”. This was good enough for me. By this time, they had handles the data/deliverables so much, they had a much better grasp on the issue and came up with development directions that were focused to the problem.
• #19: Case study: I work with a brilliant developer. Like most brilliant people, he is overloaded with work and his attention is spread thinly across many projects. I needed some infrastructure decisions to be made by him so that I could determine the design direction in a project with an extremely tight timeline. This developer never has time to prep for meetings and comes in “cold” every time. I did not have time spoon feed information in the hopes that something would spark in the hour we had together. I went into that meeting with a flow chart of the current product infrastructure, where I purposely left out an element that was problematic for the new product. He fixated on that missing element, corrected me, and then went on to discuss why that element was an issue for our new product. Within 45 minutes we had a new data flow diagram roughed out and I had my design direction.
• #20: Case study: I was working with a team that had been long in development of a new feature for a website. They had undergone several iterations of development and design and I was called in to do the usability testing of the feature after major iterations. Each time I would come back to the team with usability recommendations and someone (either a stakeholder or technologist) would say “I knew that we shouldn’t have put <that> so close to <this>” or “We’ve had similar complaints in the past with <this other related feature>”. So why didn’t the designer hear about this before? In this case, she had undergone multiple attempts to gather information at the outset of the project. When asked why issues weren’t raised sooner, the excuse presented most often was “I didn’t think about it then.” The truth of the matter was that the designer held several team meetings to elicit feedback, conducted group brainstorming, and sent direct emails. These methodologies elicited tenuous and feeble feedback. After hearing this story, I asked her to try the “Where’s Waldo” technique. She posted wireframes and ballot boxes in certain areas in the office: the developer’s kitchen, the hallway where all the User Support offices were, near the photocopier in the Production area, etc. She collected A LOT of feedback, and although she had to sort through it, she was able to detect weak points in the design where multiple comments were made.
• #21: The problems and case studies I mentioned are just one way to use these tactics. My hope is that you can put them to interesting and innovative uses. In our role in creating and managing the user experience, we have to go beyond what client groups want to determine what they really need. Hopefully these tactics can help you do that. Any questions?
• #22: Sorry, it’s not on the conference disc