Category Archives: process

The UXD Stack

Almost a year ago I wrote a short piece on 404UXD about “The UXD Stack,” the format we use for project briefs at EMC Consulting. I’m reposting the article in its entirety here as I embark on posting a sample of the uxd stack in action each week.

Enjoy, and poke me if you don’t see something once a week.

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

My methodology for approaching projects

“The UXD Stack” is a universal framework useful for analyzing any kind of communication. Every presentation, screen, button and image our team creates 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.


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.


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.


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.


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.


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

I 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.

I’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 a 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 me what you think in the comments.

Leave a comment

Posted by on April 19, 2010 in process, uxd stack


The UXD Stack

I just posted a short description of “The UXD Stack” over on

The UXD StackMany people in User Experience Design use different kinds of “briefs” when they get started on a project. Most of our work at EMCC UXD 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 “The UXD Stack�? is the simplest yet most effective perspective for all kinds of communication projects.

Read the details and download a single-page PDF description at

Leave a comment

Posted by on June 8, 2009 in design, process


960 Grid System layout tools and code sure to save design & development time

960 Grid SystemNathan Smith has launched, a very promising framework and design toolset for layout using CSS. Besides a great foundation of code for implementing a flexible grid system, he’s created accompanying templates for sketching preliminary designs on paper and wireframing detailed designs in Visio, OmniGraffle, Fireworks, and/or Photoshop. As with any Nathan Smith endeavor, this kit is very well thought-out and executed. He’s considered many details and implemented them thoroughly.

If you’re looking to cut down development time while sketching, wireframing, or coding hi-fi prototypes in HTML, Nathan’s work in the is sure to be a great starting point.

Read more about the whys and hows in Nathan’s explanatory post on, and download the framework (only 180KB for all the tools, only 4KB of actual code code compressed) at,

Leave a comment

Posted by on March 26, 2008 in code, process, prototyping


Garrett’s Content is the Design

Garrett's articles

My friend and co-worker Garrett Dimon recently relaunched his eponymous blog. The results are fantastic. Garrett cites the work of Edward Tufte as his inspiration to provide visually compelling examples when writing about web design, technology, and other usability topics. The new layout is completely clutter-free, focusing completely on the topic at hand. His simple grid layout provides a variety of interesting ways to incorporate illustrations and examples that are both meaningful and pleasing to look at.

I’m looking forward to reading Garrett’s future posts. If you’re into user experience and visual design, you will likely look forward to them as well. Add his feed to your reader if you haven’t already.

Leave a comment

Posted by on February 19, 2007 in design, process, prototyping


Links from the High-Fidelity Prototype Presentation


Here are the links I referred to in the presentation this evening.

I’ll try to have the deck posted by this Sunday. As promised, here’s the PDF of the deck of last Thursday’s presentation.


Posted by on September 14, 2006 in process, prototyping



Workflow is dead! Long-live workflow!

James Robertson and my co-worker Jeff Potts have a great discussion running on the problems with workflow in content management applications.

Workflows can be infinitely flexible when they are modeled the way work is really done. What’s needed is a model that more accurately reflects how people naturally work.

I think linear workflows are inherently flawed by design. Even in the most extreme example of linear work, a manufacturing assembly line, workers typically have the ability to stop the line and reject an item outright or request rework. But often the rework is something more complex than simply passing the item back to have it worked again.

When these kinds of exceptions occur in most workflow systems today, users create workarounds to the system to get their work done.

About 8 years ago I used a different kind of workflow engine at KMPG when Kevin Parker and I were helping creating an HR outsourcing center. We used a product called Action Workflow to handle all of the transactional items in and out of the center. Action is based on the ActionWorks Business Interaction Model which more realistically models how work is really done. Take a look at the model to see how different it is than the standard linear approach.

The Action model treats work the way it really lives, organically in a cycle of negotiations and performance. New cycles can organically recur in the parents. It’s a completely different (more effective and realistic) way to look at workflow.

I know James and Jeff were trying to keep this product-agnostic. But Action is the only example I know that’s using the cycle-approach. Everything else I know of is linear.

We need ways to systematically track the work that we do. The more accurately they model the way we do work, the less people will use workarounds, and the happier everyone will be.

1 Comment

Posted by on March 24, 2006 in process


SVN as a Web Site Maintenence Tool

Alex King has (whom I was previously familiar for his collection of WordPress themes) posted a very interesting idea about using SVN as a web site maintenance tool. Aaron and Jeff introduced me to SVN earlier this year and we use it to manage version control on our projects at Navigator clients. But our work is almost always web applications. He describes the big idea near the end of the article thusly:

Branching and tagging are very basic and common practices in software development, but much less common in web site development. It’s hard to stress enough the benefit of having your web site under source control and being able to take advantage of all these capabilities.

I’ll have to ponder this more and discuss with the guys at work. Maybe I’ll be installing SVN on the iMac at home sometime soon.

Leave a comment

Posted by on January 20, 2006 in process