1. Stop the Madness A modest proposal for sane software design. Andrew Hinton & Patrick Quattlebaum IIBA Denver / April 2011Tuesday, May 10, 2011 1
2. MS Word Jack of all trades, master of none iA Writer Nearly perfect #uxba for a particular contextTuesday, May 10, 2011 2Word has so many features, they often get in the way of one another. When the fact is, thevast majority of users need only the most basic capabilities it offers.It’s an example of how a list of requirements can be literally translated into a UI, without realDesign happening. Word is not a “beloved” application. People use it because they have to.iA Writer, however, is a different application with a very speciﬁc audience: people with iPadswho want to be able to write on them without the distraction of unnecessary functions & userinterface widgets. It’s enormously successful -- selling at a fraction of the price of MS Word,but making tons of money for its creators (a small team) with a rabid fan-base.It was designed to be something you *want* to use -- that makes you happy about sittingdown to write.Why can’t we make software like this all the time? There are many reasons that we can’t getinto today but one to focus on has to do with the relationship between technical & businessanalysis and design.
3. WHY CAN’T WE MAKE STUFF PEOPLE LOVE TO USE? #uxbaTuesday, May 10, 2011 3
4. A Meeting Between People Who are Part of an Organization This is This is Hawkeye Sal - Chief Surgeon - Recently given the cook for charge of mess hall M*A*S*H unit 4077 - Has a favorite family recipe for french toast #uxbaTuesday, May 10, 2011 4
5. #uxbaTuesday, May 10, 2011 5
6. The “Outsourced Design” Model Production Edge use cases often outnumber SMEs & Business the most common Stakeholders Analysts use cases. Develop, Review, Test Task, Process Design isnt Requirements Detailed & Point-of-pain actually ﬁnished & Process Models Speciﬁcation descriptions but process pretends Design, in a bubble, it is. misses out on the inputs it needs most. Task & Process often miss deeper context (cognition) & interaction (behavior) issues. Deliverables UI Description missing tacit (wireframes + visual design) knowledge Design behind the Team design Content #uxbaTuesday, May 10, 2011 6A typical process. (Explain each part - then click through the risk points)What is missing?
7. Long tail of edge-case requirements Everything ﬂattened into one Most important use cases for long list of equally-weighted highest percentage of users requirements. (Also, loses context) #uxbaTuesday, May 10, 2011 7
8. CONTEXT #uxbaTuesday, May 10, 2011 8This is a big deal. We may think we’re getting the full story when we interview SMEs and stakeholders (and even end-users), but often we aren’t.
9. Task Task Need Task Situation Task Need Need Task Task Task Task “Scenario” #uxbaTuesday, May 10, 2011 9In addition to the inherent behavioral characteristics of the person,>> there is the Situation the person is in, which is often the main reason why they are usingwhat we make to begin with. The situation could be International Travel, Getting Married,Going to School. And, frankly, it could be all three of those at once!>> A situation gives rise to needs -- problems the person needs to solve. These are practical,concrete outcomes of the general situation. I’m traveling: I need to book plane fare and hotel,and decide what to pack; Wedding: I need to plan the ceremony, get a ring, sendannouncements, plan a honeymoon.>> So those needs then give rise to tasks that must be completed in order to solve theproblems. The tasks require tools, knowledge, and some kind of interactive activity.Increasingly, the tools we use to solve these problems are *digital* ... ﬁfteen years ago,Travel, Marriage and Going to School had very little to do with *software*!>> This nest of contextual facets is what we try to describe with a Scenario. And like thepersona, the goal is *understanding* -- no matter what format, documentation style ormethod you choose.
10. THINKING cognitive assumptions, education, learning ability Cognitive DOING Physical physical activity & ability, habits, preferences, sensory Emotional FEELING psychological state, anxiety, conﬁdence, stress, desire “Persona” #uxbaTuesday, May 10, 2011 10First, we have to consider the context of the User -- who is, after all, not only a “user” of ourproduct, but a whole person with a whole life of behaviors, where many things are much moreimportant to them than our precious design! Here are several dimensions that exist for theperson, whether we acknowledge them or not:>> Doing (physical activity and ability, habits, preferences, and their sensory experience)>> Thinking (cognitive assumptions, education, learning ability)>> Feeling (psychological state, anxiety, conﬁdence, stress, even desire)These facets change from one person to the next, and can even change from one day to thenext for the same person, depending on other factors we will look at next.>> This is in essence what we are wanting to understand when we use a “persona” for userexperience design. How you document the persona doesn’t matter as long as it helps yougain an *honest* understanding of the person.
11. Task Task Need Cognitive Task Situation Physical Task Need Need Emotional Task Task Task Task Time #uxbaTuesday, May 10, 2011 11When you overlay these, diagrams, you have what I call the Situation/Behavior Complex. It’shelped me to map out the human situations people are in, their likely behavioral patterns andassumptions, and better understand how my design can help them complete their tasks. Thiskeeps me from thinking of the user as someone who is doing nothing but using my softwareor website.>> Another important factor to consider is that people change over time, sometimes in amatter of days or hours.>> So it’s important to know where your users are in a given narrative. Because evensomething as simple as their interaction with your system can cause changes that require thesystem to interact with them differently later on.
12. Scenario-based Design #uxbaTuesday, May 10, 2011 12Designing with persona & scenario approach is different from use-cases.
13. !!! #uxbaTuesday, May 10, 2011 13Org I worked with early in my career had a mess of a site.
14. A typical “site map” architecture Organizes information, but shapes nothing else. #uxbaTuesday, May 10, 2011 14Tried doing basic IA content organization, but it wasn’t enough -- I organized theirinformation without considering the larger issues they were facing (because I wasn’t listeningfor them). Once I showed a normal “sitemap” (this is just a stand-in, not the real one) theystarted talking more about the soft-tissue issues in their org -- how while this mightorganize things OK for content’s sake,there would be tensions with
15. A contextual blueprint #uxbaTuesday, May 10, 2011 15This diagram describes something more like rooms or neighborhoods -- it’s a description ofcontext, not (necessarily) literal links & hierarchies. It helped establish the conceptualstructure of the shared information environment.This was more successful, and ended up driving the vision for the site.
16. SKETCHING #uxbaTuesday, May 10, 2011 16This is a big deal. We may think we’re getting the full story when we interview SMEs and stakeholders (and even end-users), but often we aren’t.
17. Bill Buxton #uxbaTuesday, May 10, 2011 17Explain diagram ...- moves from cheap, easy, low-risk sketching to higher-cost, more-complex, higher-riskprototyping- Ideation = exploring alternatives; prototypes are more for usability & feasibility.- as our investment increases, so should the weight of the design criteria - you don’t manageideation the same way, or with the same rigor, as usability & feasibility.- circular arrows remind us we include users throughout the process, not just for usabilitytesting
18. From Bill Buxton’s “Sketching User Experiences” #uxbaTuesday, May 10, 2011 18
19. Bill Buxton on the shape of design #uxbaTuesday, May 10, 2011 19Bill Buxton talks about how we tend to think design iterates into a tighter and tighter perimeter, until we’ve winnowed and honed to an ultimate,ideal answer.>>But he says that’s not how design really works -- design is about exploring alternatives and requires constant consideration of alternativepossibilities, lateral ideation.You come up with variety, then winnow down, then expand again, until you explore your way to a solution.But that’s not a very efficient activity, in the eyes of what is still mainstream management thinking by which I mean the thinking style of mostpeople with management roles. So we have to create a permission space within the linear activity of a project.
20. Exploration of Alternatives Inﬂection point: the broad outlines & design rationale are mostly settled #uxbaTuesday, May 10, 2011 20
21. Business Analysts SMEs & Stakeholders Design Team #uxbaTuesday, May 10, 2011 21This is a collaborative, conversational process -- not an assembly line.
22. Project Process Design Space #uxbaTuesday, May 10, 2011 22There has to be room for that sort of playful, exploratory thinking to happen.Now, that certainly makes a lot of managers nervous. But I would argue that giving this room for design is non-negotiable.If giving designers this room doesn’t result in great work -- don’t take away the room. Get new designers.It’s our responsibility to be sure that, given the room to do the work, we make the most of it.That means the responsibility is on us to be ever-vigilant of our own biases & cognitive ﬂaws.
23. An Integrated Model Collaboration throughout lifecycle Business Analysts SMEs & Stakeholders Design Team Informed by Context Exploration & divergence before reﬁnement & ﬁnal design. #uxbaTuesday, May 10, 2011 23
24. THANKS! Patrick Quattlebaum firstname.lastname@example.org @ptquattlebaum Andrew Hinton email@example.com @inkblurt #uxbaTuesday, May 10, 2011 24