UX Success

Matt is working at the story wall. He is looking at stories that equate to task chunks. IxD sketches of components that support the user in doing various tasks are pinned to the wall next to the stories

I am grateful to be working with Matt Hixson on some really neat tools that will help people realize the power of social media for their business.  I won’t say a lot about that — but  do check out Matt’s blog here:  http://www.thestudyofsocial.com/.

He and his scientists are working on some crazy maths that surface some data that will be visualized.  He’s spent a bunch of time thinking about what those visualizations could be.

As we are working on building an enterprise application,  am concerned with designing a framework that supports intuitive workflow for the people who need to administrate the tool.  If I learned one thing working on enterprise applications, making mundane tasks easy and intuitive goes a long way towards driving more use of a tool.  To that end,  I am thinking about how I can help Matt think about supporting tasks in the various contexts different users will have for meeting their goals.

I know we can get to a scalable solution — a component approach to design.    Our approach to this is to take the context scenarios we wrote a few months ago and break them apart into  types of work the user is doing along the way to meeting goals.    As we break the scenarios into stories, we have a conversation about the type of task the user is engaged in.   Is the user adding/editing?  Is the user combining elements to make something?  Is the user Is the user opening a layer of detail?  Is the user sorting results? Is the user culling a list?   Is the user focusing on a specific data point?  Is the user pivoting a view?   Is the user looking at the big picture?   Once we have a list of tasks we need to support throughout the application, we can design a set of interaction patterns that will support them.

In parallel we have to be thinking about the   framework of the application.  How do all these components hook together to support the context scenario we wrote in the first place.    When we start organizing the little tasks we are supporting building them back up into domain stacks, we start to get something that looks like a mental model.

This is a model of a huge enterprise task -- broken into stacks and mapped to types of work done by various project specific personas.

This is when Matt and I back up from the  detail of the task , look at the whole wall and ask….  Where  is the navigation that supports users in finding things?  How do users get to tools?  Do they go get a tool….or does it appear as they need it as part of the general flow?

Once we get this nailed down,  we can go wild with data visualization.

The therapy tent at #occupyPDX looks like a good place for stakeholder interviews....

Pressed to explain that context scenarios don’t just come out of thin air — I put together a list of questions we need to have answered before we can write some narratives about users solving their problems….

So pull up a chair with your favorite stakeholder and start digging in…..

Product Manager Interview Outline – User Experience Requirements Gathering
(the goal for this interview is to elicit enough information to derive a set of context scenarios to begin elaborating)

Product (or Project) Name:
Who is being interviewed?
Who is doing the interviewing?

Business Objectives:

• What is  THE  primary business objectives (for our company) for the product — ( the number one reason why  it did or should be funded?) :
  Other business objectives for the product?:
• Please identify the main business problem for our primary buyer you hope to solve by offering this product.
• Please identify the main business problem for our primary user you hope to solve by offering this product.
• How do you plan to measure the business success of this product?
• Known Business requirements?
• Known Technical requirements?
• Key differentiators that will make us successful?

User Goals:

List all the different types of users you think will interact directly (configure, view data, generate reports) with this feature / function / product.
1.
2.
3.

List all the different types of users you think will interact indirectly (get reports, tell people to do something with…) with this feature / function / product.
1.
2.
3.
For each direct (and indirect)  user, do as many of these as necessary:

From your perspective, describe user type ____________ interaction:

1. What is this user’s primary goal?
2. Is this a critical goal for them?  For us?
3. What does success look like for them (when they are finished using this feature/function/product what have they accomplished?)
4. What feature(s) are they using to accomplish what they set out to accomplish ?
5. How long do they spend meeting their goal?
6. How much time elapses before they use this feature, function again?
7. How frequently are they using this feature/function to accomplish this goal?
8. Is this something they are currently doing?
9. How are they doing it now?
10. How you think they would like to be able to do it?

Repeat questions 2-10 for another goal…….