Monday June 8, 2009

The UXD Stack: How We Look At Projects

by Mark Kraemer in Article

2 comments

Many people in our profession use different kinds of “briefs” when they get started on a project. A brief is a short paper defining the background and preliminary understanding for a project. Some of these documents are called “Strategic Briefs” or “Creative Briefs”.

We work on a wide variety of projects. Most of our work is application development, but we also develop demonstrations, prototypes, proof of cocept models, and even business presentations both internally and for our clients. Regardless what we’re producing as the final deliverable, there’s a single formula for the up-front brief that we use to get a quick and successful start to the project. We think its the simplest perspective for communication projects.

The UXD Stack

Download a one-page diagram of “The UXD Stack” – our brief for projects
(188KB PDF)

“The UXD Stack” is a universal framework useful for analyzing any kind of communication. Every presentation, screen, button and image we create is geared towards solving a specific business problem. This is the framework we use to identify and solve such problems.

This encompassing approach considers five basic attributes of communication: purpose, audience, content, context, and media.

Purpose

Why are we doing this project?

Before we start designing, its critical to understand the business goal we’re pursuing. Understanding how the tactic delivered by our work fits into our clients’ larger strategy ensures that we’re designing the appropriate solution. This understanding should be firm at all levels of the project. We should understand how the client competes in their market all the way down to understanding the business need for the specific project. Without this understanding, we risk delivering a solution that doesn’t help the client achieve their larger goals.

Audience

Who are we communicating with?

Who will be using the application or site? Who will be viewing your presentation? What characteristics does the audience share amongst themselves? What makes them different from each other, or different from the people who aren’t included? Understanding these differences helps create segments of audiences that the final designs may be tailored to suit. Its OK to have multiple groups. List as many as needed and clearly explain what differentiates each.

Content

What does each audience need to achieve the goal?

The content is a list of understanding of scope for what people want to know and do while using the site or application. Sometimes its easiest to describe what content is not. For a movie, the content is represented as a script, not the actors or sets or posters or action figures. For a novel, the content would be the manuscript, not the book cover or page layout. For a public facing site, content might be represented as required functionality. If you’re designing a site using Web Standards, content is what’s contained in the mark-up.

Context

What style, navigation, and other formatting will help the audience?

Context is both style and organization of the content. It’s the non-verbal communication that helps the audience navigate and relate the content to their own experience and background. Context is a major contributor to the experience people have with the site or communication. Context is usually what people are referring to when they describe “look & feel.”

Navigation is certainly context – how is the content/message organized so that I can find what I’m looking for?

Visual style is also context – how is the company brand reflected in the site/interface?

A great example of context is comparing two different interfaces that handle the same data. How does the experience of using the calendar application differ on a Palm V versus an iPhone? They both use the same kinds of data for managing your schedule. But the visual style, navigation, and even interaction behavior differs greatly between the two. That’s context.

Media

What physical means will deliver the prescribed content to the defined audiences using the appropriate context?

The top four layers are technology agnostic. They describe the communication problem & solution from a functional and personal perspective. Only after the other layers are understood, do we then use the technology layer to describe the technical (or other media) means for delivering the solution.

For Best Results, Work Top-Down

We called it a “stack” because each layer supports the layer above it. Ideally, design decisions shouldn’t be made on each layer until the layer above it is completely understood. For best effect, consider each layer in order from top to bottom.

We’ve illustrated each layer with ideas from websites or applications, but the model applies to all manners of communication. This approach is equally effective for planning a billboard, a radio ad, writing a term paper, or even calling to order a pizza. Every method of communication requires a purpose, has an audience, contains content, uses specific context, and is transmitted via some kind of media. this approach can be used to plan any kind of communication endeavor.

“The UXD Stack” is simple enough to apply to all of our wide-range of projects, yet thorough enough to cover all the bases. It can be as detailed or simple as needed at all levels of a project. We haven’t come across a challenge on a project yet that didn’t fit into one or more layers for understanding.

Try it yourself

The 60-Second Self-Assessment

Applying this framework to your own current site or future project is a good way to consider how it could be improved to better serve your customers and your business.

Try answering these questions for your current project and see if it doesn’t reveal an opportunity for improvement or spur some creative solution for existing challenges.

Purpose – How does your current site/application help achieve your business goals?

Audience – Does it reach out uniquely and appropriately to each specific audience you need to address and serve?

Content – Does it provide all the content and functionality each specific audience needs?

Context – Do users find it easy (perhaps even consider it a pleasure) to use your site/application? If not, what keeps them from doing so?

Media – Does your site work well on portable devices? Does it face other technical challenges?

If you work on a diverse range of projects, you might benefit from the simplicity and flexibility of this format as well.

Does “The UXD Stack” make sense to you? Do you have other means for briefing your project starts? Tell us what you think in the comments.

Comments on “The UXD Stack: How We Look At Projects”

1. Aaron Hursman said:

   Mark, excellent work here. Everything, top to bottom, is user-centric. Also, I love the simplicity. Question though, it seems like it would be hard to describe the Context w/o dipping your toe into Media. Do you ever find it difficult to remain pure as you navigate these “swimlanes”?

2. Kraemer said:

   Good point, Aaron. Just about every deliverable we create spans more than one level, but it still helps to think of each layer in the process.

   Example: a use case starts with an actor (audience) then describes the actions (content) they take in order to complete a task (purpose).

   Example: wireframes show how features (content) are organized (context) on a page. They may even be specific to a particular audience.

   I really try to ignore media as long as possible to remain “task-focused” and not get caught up in “how” to use the technology before I discover “why” we need to use it.

   But sometimes there are constraints in the media that force design decisions on the context or even context. Say you’re using a specific charting/graphics library to generate data visualizations. The selection of visualization types and the configurable attributes will become constraints on what contexts you can provide.

   On the other hand, the media might free you from constraints. Microsoft Surface, as an example, requires “out of the box” thinking for people used to designing for standard screens. Because people gather around the Surface table, we have to loose the (typically assumed) context of up, down, left, and right. On the Surface, one must consider how objects behave when spun around for people sitting/standing at different angles on the table. I’m planning a future post on Microsoft Surface as described by the stack.

   The stack is useful even for applications that don’t have users! Think of ETL (extract, transform, load) for moving data between systems. The purpose is to get data from a transactional system into a data warehouse or other reporting kind of environment. The audience includes each specific system involved. The content is whatever data is required, along with all the attributes (type, length, etc.) for the data. The context is the message format (XML scheme, CSV, fixed length). The media is whatever tool is used for the transport. Cool, eh? It really is universal!

   But, its also not meant to be super rigid. It’s just a way to help separate the components of a design so that each decision can be treated with the proper attention and consideration it deserves.

   It also scales to every level of a design, not unlike Christopher Alexander describes when he writes about pattern languages. The stack can be applied to the entire suite of applications, a single application, a single screen, or even a single control on a page.

   So, a long winded answer to your sensible question – no need to stay pure when documenting, but I try to consider all the layers when making design decisions.