UXD - User eXperience Design

Site Maps -- Still Needed for Web Apps?

In a previous post, I talked about creating a Use Case Diagram as a means to moving the 60,000’ concept to a level of detail that’ll allow us to begin development. Since that diagram identifies the overall functionality, the team can use that to start designing the data model, writing user stories and generally working towards a more detail view of what we’ll eventually need to develop.

The site map is another diagram I’ve found helpful to bring further definition to the concept.

On some projects, usually those that were understaffed, the site map was typically drawn up after the project was in the end stages of development and only because someone in marketing asked for it. Oh, everyone on the team knew what was being built and the relationship between the areas, but it was all verbal -- no one had taken the time to set it down on paper.

At Pathfinder, we sketch out a site map early in the process to give a physical representation to the verbal concepts floating around the team. The ‘we should separate this’, and ‘let the user skip from here to there’ and ‘oh yeah, both these areas relate to each other’ kind of ideas that float around before requirements are actually written.

The very act of documenting work to further define the concepts and gives the team a visual artifact for future decisions. The site map, no matter how rudimentary, begins to identify and categorize the user activities into a relational hierarchy and provide a framework for the application. It helps in project scoping and planning because it begins to further identify the details of a project, which can then open a conversation as to what is needed now and what can be postponed to later. It is a concrete drawing that you can show the client and ask, do you agree? Is this what you want?

As with Use Case Diagrams, a Site Map gives you an overall view of a project -- not necessarily all the details but a high level view of the end goal. Both documents are relevant because both give you a checkpoint to refer back to once you’re in the details of a project to make sure that you’re still on track to meet the project objectives.

Use Case Diagrams

Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.

For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.

The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.

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.