UXD - User eXperience Design

It Starts with the User Story

Having recently been asked about the difference between a use case and a user story, I came up with this explanation:

Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.

A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.

For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:

As a [role]
I want [feature]
so that [benefit]

From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.

We Don’t Need No Stinkin’ Requirements

The other day I was reviewing a statement of work for a potential project when the client came to  the line item allocating time for requirements. Oh, the client stated, we don't need to gather requirements. We do Agile development.

*Sigh* This myth of no requirements needed seems to be prevalent lately.

Well I hate to break the myth, but projects still need requirements regardless of the method used for development. The reality is you can’t create something unless you know what it needs to do. In order to know what it needs to do, you need requirements (business, technical and user).

The differences come in with the methods for gathering requirements. Some teams make requirements gathering the central activity, creating documentation detailing everything down to the nth degree before development begins. Other teams put less emphasis on knowing all beforehand and instead start with sketches or three sentence "stories", knowing that details will be filled in and added as the project progresses. Side note: make sure you have some way of documenting those hallway conversations because, yes, those are actually requirements gathering and it's good to keep a record somewhere accessible by the project team.

At the most basic level, the purpose of requirements is to define the problem you're trying to solve. Whether your team waits for a complete definition of the problem before starting development or starts with the basic outline depends on your development method. But you still need requirements. After all, if you don't define the problem, how do you know when you’ve solved it.

Not sure how to write requirements? Check out my colleague's post: Writing Requirements

Unanswered Questions of User Research

Luckily, formal usability testing offers us the opportunity of conducting a near-scientific study of stimulus and response. We're able to cull prospective users from a pool of particpants, and screen them against  a carefully chosen list of attributes, including gender, age, computer literacy, and other specific qualifications--much more discrimination than the "real world" of users and links and happenstance allows.

When it comes to initial requirements gathering, though, we often (in the words of Tennessee Williams), "depend upon the kindness of strangers." There are at least three types of early user researh/requirements gathering whose success often depends upon the enthusiasm or engagement of the client. It follows that this pool of resources must be evaluated through the filter of operative agendas. Here are three examples of user research that can be potentially valuable if all factors are considered.

1.  Subject matter experts - an incredibly valuable asset for building site or application content. Always keep in mind that the SME's time is constrained. Keep your questions open-ended, but focused on the task.

2. Stakeholder interviews - keep in mind that the client probably has an incentive to obtain "buy in" with these interviews. While much independent data can be garnered from these interviews, pay close attention to the client's needs and goals with these interviews.

3. "User" interviews - at an early stage in the project, these people are probably anticipated or target users. Don't lose track of capturing data to build personas and actual user scenarios.

Requirements Visualization, V1

At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.

The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.

Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Comprehension is more important than brevity here - at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations - look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.

In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that's another blog.