User-Centered Design Artifacts

Understanding the Design Problem and the Proposed Solution

Clarifying the question, Mike and Rick answer, “This is actually two questions:

1. What artifacts do you need to create to help your team understand a design problem?
2. What artifacts do you need to create to enable your team to understand the proposed design solution?

“To understand a design problem, you need to provide a summary of what you learned during discovery. You might also include personas, but ultimately, you need a list of user needs or requirements.

“To deliver a design solution, you must document each layer of the user interface, including its

• information architecture—which you might represent as a site map
• page layouts—perhaps by creating wireframes, which include the navigation system
• page interactions and controls—for which you could create an interactive prototype
• visual design—by depicting compositions comprising graphic elements
• textual and pictorial content—for which you may need to create a content inventory

“Although you could create a specific artifact for each layer, in many cases, you can omit specific artifacts or combine them. For example:

• If a site or application is simple or small in scope, the global navigation that appears in the wireframes or prototype may be sufficient to document its structure.
• If you create a prototype, wireframes are often unnecessary.
• If you’re redesigning a site or application, you may be able to incorporate the existing visual design into either wireframes or a prototype.
• If a site or application is relatively small or highly transactional, you may be able to document the content you need to include in the wireframes or prototype.”

Visualize Design Solutions, Coupling Them with Business Goals

“Pictures, of any level of fidelity, are key,” asserts Baruch. “However, you need to couple these with the business goals to gain a better understanding of what you’re trying to accomplish. You need to annotate the design visuals and continually tie them to business goals. Otherwise, the artifacts become fodder for people just arguing about designs based on their individual opinions.”

The Right Artifacts Depend on the Team

“I don’t think there is any one right set of artifacts,” advises Amanda. “It depends on a team’s structure and maturity, the development environment, and whether you’re working on an internal project or serving external clients. For instance, if you’re working on a cross-functional, internal team that has been together for several months, and the whole team was able to watch some research sessions, you can get away with creating much less documentation than if you’re in the first phase of a new project for a client.

“That said, there are a few categories of artifacts that I’ve found help every team work more effectively together:

• personas
• artifacts that define context
• sketches, mockups, and prototypes
• research findings”

Personas

Defining personas or user profiles provides a shared understanding of who you’re serving. These don’t have to be fancy documents—even a best-guess proto-persona that isn’t based on research is better than not having anything at all. A shared understanding of the primary target persona can help you to prioritize features and make design decisions based on what you know about who you’re trying to serve.

Artifacts That Define Context

Artifacts that are very helpful in understanding and solving design problems put context around the personas. These artifacts help you to understand the context in which users interact with your product, what issues or challenges they might have, their motivations, and how what you’re building would fit into their existing life or work. Such artifacts include user stories, use cases, scenarios, user journeys, touchpoint blueprints, experience maps, or whatever else you might need. Again, these don’t need to be polished documents. They just need to enable your team to gain a shared understanding of users’ challenges, motivations, and context, so you can craft solutions most effectively.

Sketches, Mockups, and Prototypes

Representing your design ideas visually helps to ensure that everyone is on the same page, you can get feedback from users and your team, and you can resolve inconsistencies or areas of confusion. You might begin with a sketch on a notepad or whiteboard or a site map, then create a pixel-perfect comp or an interactive prototype. While the level of fidelity that is necessary depends on your organization and the audience to which you’re communicating your design ideas, you’ll always need visual ways of communicating your ideas, so you can represent them tangibly.

Research Findings

You need to document and share the findings from your research. Typically, the best way to get the whole team invested in research is to include as many team members as you can in the research process. But realistically, your whole team isn’t always going to be able to observe every interview or watch every usability test. I find the next best thing is to hold a debrief meeting with everyone, immediately following your research, so everyone can share whatever they’ve observed, and you can discuss the most important takeaways and their impact on the project.

You can then document both the takeaways and impacts—whether on a whiteboard, on a wiki, or in an email message. While research findings might not actually take the form of a stand-alone artifact, the discussions and recaps of the findings are what I’ve found to be most effective in creating a true shared understanding of the importance of key takeaways from the research.”