Use Cases Are Working

Just in the nick of time, as my boss and I are putting finishing touches on our PowerPoint slides for our presentation for the STC Summit "Moving Documentation Upstream with Use Cases." The theory was that if we used use cases as our Information Development user analysis methodology, we could get involved earlier in the development process and even be able to influence design decisions.

We've had some intermediate successes but it has been hard to insert ourselves at the point in the process where we think the use cases can be the most effective. We recently tried with a project that probably comes as close to the perfect scenario: right team, right changes on the UI, good timing, etc. We had one design meeting last week where we collaborated among product developers, UI developers, information architects, information developers, and QA to understand why a user would view system statistics from the home page of one of our security appliances. The discussion last week was productive and helped form a better team vision of what the user would be doing and why (shifting the team from their normal approach of "What data do we have and how do we want to display it?").

This week the information architect ran a collaborative session where he did a sticky notes on the wall kind of card-sorting exercise that started matching "kinds of data we have" to "things the use wants to do with data" (essentially the use case titles we arrived at in last week's meeting). In a word, it was exciting!

The best part was at the end of the meeting where I asked the developers to accommodate room next to the graphs and tables for embedded user assistance to set the context for the user, based on the insights that had come out of the workshop. The developers agreed that at a minimum we could have fly-over text, pointing out that graph sizes would make real estate hard to come by.

I know this might sound trivial, but to be having discussions about what embedded assistance the designers and developers would accommodate this early in the project was HUGE! The fact that we got a concession of any type was MAJOR!

I hope those of you who are coming to the Summit will come hear our presentation and watch our demo:

Moving Documentation Upstream with Use Cases

Date: Monday, May 04, 2009

Time: 3:00 PM to 4:30 PM EST

Location: Hanover AB

Description

How to apply case methodology and structured writing to get information developers involved earlier in the design process and to produce testable information products earlier in the development cycle.

LEARNER OUTCOMES:

• Create UML use case diagrams and write use case descriptions
• Describe a systematic process for going quickly from use case diagrams to user documentation
• Describe the benefits of involving information developers early in the design process

UAX

I was recently contacted at work to be a member of the "Next Generation User Assistance Experience Council." The person setting up the group was somewhat apologetic over its long title, but I loved it. I thought it told a compelling story. In setting up a folder to start collecting files and such, I named it "Next Gen UAX."

UAX, I like that! UAX carves out a special niche for us in the UX world. I also think it sets up some interesting discussions about what would constitute UAX as a discipline or practice that would be different from just talking about user assistance.

First, I think there are two dimensions along which to view UAX, each with its own set of implications and requirements.

• UAX encompasses how the content of the user assistance supports the user experience with the product the UA supports. Along this dimension we would discuss the usefulness of the UA.
• UAX also encompasses the user experience manipulating the UA delivery channels with things such as navigation, linking, interactions, affordances, pliancy, etc. Along this dimension we discuss the usability of the UA.

So the mantra of a UAX approach is to provide information that is useful in a way that is usable. Ingrained in this approach is a user-centric task analysis that identifies task- or goal-oriented information requirements and the design of a delivery mechanism that optimizes access to that information on an as-needed basis. It also requires an evaluation methodology that looks at how useful the information was to the user and how easily was the user able to access it.

I know this is not a big departure for most of us, but I do think that linking user, assistance, and experience into one semantic unit does shift the perspective in a significant way. It moves us further from being merely writers and more to being developers of information delivery applications. It moves us from looking at Help as a codified body of knowledge about the product as a whole and more as a collection of interventions targeted at specific moments of opportunities and points of pain. We will worry less about "Is this presentation consistent with one the user might have seen elsewhere in the Help" and more about "Does it meet the likely need of someone in this task on this screen?" We will worry less about "Is this complete" and more about "Is this sufficient?"

So, as of right now, I start relearning my craft under the new classification of User Assistance Experience (UAX) with the driving question of "What's next?"