ux and business analysts - stop the madness
DESCRIPTION
My half of a presentation to the IIBA chapter in Denver, Colorado in April 2011TRANSCRIPT
Stop the MadnessA modest proposal for sane software design.
Andrew Hinton & Patrick QuattlebaumIIBA Denver / April 2011
1Tuesday, May 10, 2011
#uxba
MS WordJack of all trades, master of none
iA WriterNearly perfect
for a particular context2Tuesday, May 10, 2011
Word has so many features, they often get in the way of one another. When the fact is, the vast 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 real Design happening. Word is not a “beloved” application. People use it because they have to. iA Writer, however, is a different application with a very specific audience: people with iPads who want to be able to write on them without the distraction of unnecessary functions & user interface 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 sitting down to write. Why can’t we make software like this all the time? There are many reasons that we can’t get into today but one to focus on has to do with the relationship between technical & business analysis and design.
#uxba
WHY CAN’T WE MAKE STUFF
PEOPLE LOVE TO USE?
3Tuesday, May 10, 2011
#uxba
This isSal
the cook for M*A*S*H unit 4077
This isHawkeye- Chief Surgeon- Recently given
charge of mess hall- Has a favorite family recipe for french toast
A MeetingBetween People
Who are Part of an Organization
4Tuesday, May 10, 2011
#uxba
5Tuesday, May 10, 2011
#uxba
Production
Develop, Review, Test
SMEs &Stakeholders
BusinessAnalysts
DesignTeam
Content
UI Description(wireframes + visual design)
DetailedSpecification
Requirements& Process Models
Task, Process & Point-of-pain
descriptions
Design isn't actually finished
but process pretendsit is.
Deliverablesmissing tacit knowledgebehind the
design
Design, in a bubble, misses out
on the inputs it needs most.
Task & Processoften miss deepercontext (cognition)
& interaction (behavior)issues.
The “Outsourced Design” Model
Edge use casesoften outnumberthe most common
use cases.
6Tuesday, May 10, 2011
A typical process. (Explain each part - then click through the risk points)What is missing?
#uxba
Most important use cases for highest percentage of users
Long tail of edge-case requirements
Everything flattened into one long list of equally-weighted
requirements. (Also, loses context)
7Tuesday, May 10, 2011
#uxba
CONTEXT
8Tuesday, May 10, 2011
This is a big deal. We may think we’re getting the full story when we interview SMEs and stake holders (and even end-users), but often we aren’t.
#uxba
Situation
Need
Need
Need
TaskTask
Task
Task Task
Task
Task
Task
“Scenario”
9Tuesday, May 10, 2011
In 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 using what 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, send announcements, plan a honeymoon.
>> So those needs then give rise to tasks that must be completed in order to solve the problems. The tasks require tools, knowledge, and some kind of interactive activity. Increasingly, the tools we use to solve these problems are *digital* ... fifteen 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 the persona, the goal is *understanding* -- no matter what format, documentation style or method you choose.
#uxba
PhysicalDOINGphysical activity & ability,
habits, preferences, sensory
Cognitive
THINKINGcognitive assumptions, education,
learning ability
Emotional
FEELINGpsychological state, anxiety, confidence, stress, desire
“Persona”
10Tuesday, May 10, 2011
First, we have to consider the context of the User -- who is, after all, not only a “user” of our product, but a whole person with a whole life of behaviors, where many things are much more important to them than our precious design! Here are several dimensions that exist for the person, 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, confidence, stress, even desire)
These facets change from one person to the next, and can even change from one day to the next 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 user experience design. How you document the persona doesn’t matter as long as it helps you gain an *honest* understanding of the person.
#uxba
Emotional
Cognitive
Physical
Situation
Need
Need
Need
TaskTask
Task
Task Task
Task
Task
Task
Time
11Tuesday, May 10, 2011
When you overlay these, diagrams, you have what I call the Situation/Behavior Complex. It’s helped me to map out the human situations people are in, their likely behavioral patterns and assumptions, and better understand how my design can help them complete their tasks. This keeps me from thinking of the user as someone who is doing nothing but using my software or website. >> Another important factor to consider is that people change over time, sometimes in a matter of days or hours. >> So it’s important to know where your users are in a given narrative. Because even something as simple as their interaction with your system can cause changes that require the system to interact with them differently later on.
#uxba
Scenario-based Design
12Tuesday, May 10, 2011
Designing with persona & scenario approach is different from use-cases.
#uxba
!!!
13Tuesday, May 10, 2011
Org I worked with early in my career had a mess of a site.
#uxba
A typical “site map” architecture
Organizes information, but shapes nothing else.
14Tuesday, May 10, 2011
Tried doing basic IA content organization, but it wasn’t enough -- I organized their information without considering the larger issues they were facing (because I wasn’t listening for them). Once I showed a normal “sitemap” (this is just a stand-in, not the real one) they started talking more about the soft-tissue issues in their org -- how while this might organize things OK for content’s sake,there would be tensions with
#uxba
A contextual blueprint
15Tuesday, May 10, 2011
This diagram describes something more like rooms or neighborhoods -- it’s a description of context, not (necessarily) literal links & hierarchies. It helped establish the conceptual structure of the shared information environment. This was more successful, and ended up driving the vision for the site.
#uxba
SKETCHING
16Tuesday, May 10, 2011
This is a big deal. We may think we’re getting the full story when we interview SMEs and stake holders (and even end-users), but often we aren’t.
#uxba
Bill Buxton
17Tuesday, May 10, 2011
Explain diagram ... - moves from cheap, easy, low-risk sketching to higher-cost, more-complex, higher-risk prototyping- Ideation = exploring alternatives; prototypes are more for usability & feasibility. - as our investment increases, so should the weight of the design criteria - you don’t manage ideation the same way, or with the same rigor, as usability & feasibility.- circular arrows remind us we include users throughout the process, not just for usability testing
#uxba
From Bill Buxton’s “Sketching User Experiences”
18Tuesday, May 10, 2011
#uxba
Bill Buxton on the shape of design
19Tuesday, May 10, 2011Bill 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 alternative possibilities, 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 most people with management roles. So we have to create a permission space within the linear activity of a project.
#uxba
Exploration of Alternatives
Inflection point: the broad outlines & design rationale are mostly settled
20Tuesday, May 10, 2011
#uxba
SMEs &Stakeholders
BusinessAnalysts
DesignTeam
21Tuesday, May 10, 2011
This is a collaborative, conversational process -- not an assembly line.
#uxba
Design Space
Project Process
22Tuesday, May 10, 2011There 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 flaws.
#uxba
SMEs &Stakeholders
BusinessAnalysts
DesignTeam
An Integrated Model
Informed by Context
Collaborationthroughout
lifecycle
Exploration & divergence before refinement & final
design.
23Tuesday, May 10, 2011
#uxba
THANKS!Patrick [email protected]@ptquattlebaum
Andrew [email protected]@inkblurt
24Tuesday, May 10, 2011
25Tuesday, May 10, 2011