Better UX Processes: The UX Brief

Having worked with dozens of companies in my design career I've gotten to see as many different approaches to project management as there are projects. Some work better than others. (Waterile, anyone? That's some hybrid of agile and waterfall methods, but I digress.) Across the board what I often see is a lack of a structured approach to planning the UX part of the project specifically.

The first step of any UX project is to get a framework for it. I use a template that I call a ‘UX Brief’ before beginning any project. This is similar to a creative brief, which most design agencies have, but I’ve tailored it to fit the UX goals of a project. This is the best place for UX strategy to start but the information can be useful for everyone on the team all the way down the line through development:

• Project Summary

• Business Goals

• User Goals

• Competitors

• Competitive Advantage

• Success Measurements

• Usability Issues

• Technical Constraints

• Scope Outline

• Out of Scope

This list of questions should fit nicely into a 10-slide deck and a 1 or 1-1/2 hour kickoff meeting. It’s a great way to get the team on one page (and find out where some team members might be not on the same page or in fact in different books). You can help create the framework for a successful project by starting with these.

Project Summary
Describe what the project is in one paragraph. At a high-level, what is the project, and why is the project is being done? When it’s expected to be completed. These details were probably (hopefully!) in an original Statement of Work (SOW) so no need for details here. This is the stuff everyone has said 10 or 100 times already, but it’s a good easy way to frame the UX brief.

Business Goals
The ‘why we’re doing this’ question sometimes gets very weak answers, like “we need to redesign the site because its 10 years old.” That doesn’t align to any kind of business strategy. ‘Increasing sales’ is a strategy, and redesigning a site can align to this strategy by decreasing drop-offs or improving lead generation or matching a new Brand Identity. This question helps UX align to business strategy and can help make decisions about functionality or features later in the project.

Primary User Goals
What are the main things the user is trying to achieve by using this tool or site? This can be high-level but should be the user’s goals, not business goals. What does the user want to get out of interacting with this tool or site? These goals should be referred to as much as possible during the design phase to keep the user the focus in design.

Competitors
Who are the primary business competitors? what else is being done similar to this project? Sometimes a client will say ‘We really don’t have any competitors for this project’ which means you have to dig deeper. So you’re saying no one is doing this now? Are people using some other method to complete these tasks? A competitive review should definitely be one of the next steps in the project so getting this info up-front is key.

Competitive Advantage
How does the business want this site or application to be better than what the competitors are offering? There should be some business strategy behind the project – concepts or content that are different than what users can already get. If the business just comes back with “The usability of this tool will be better than the others” that is a red-flag, since unless you have a big budget for both bench-mark and prototype competitive usability testing, it could be very hard to know if your new design will indeed be that much more usable.
Dig deep in your questioning here – people are generally reluctant to change the way they are doing things now, so how is this product going to incentivize changing people’s current behavior?

Success Measurements
This seems so obvious but it is so often not asked, and when asked it is often really hard to get an answer. There are many ways to measure success. Analytics and usability testing are great ways to get some measurement on success, but they’re not always an option. So know this up front and find out from the client what will make this project successful. Some typical answers that are not at all measurable include “we want the CEO to be happy with it” or “it should be more usable [unless you are doing both benchmark and prototype usability testing]” or “I just need a website that looks nice.” Because it turns out those things are NEVER the actual criteria for success at the end of the project. If the business or project owner isn’t concerned about ROI they should be. Are they hoping for more lead generation? More people calling or visiting their location? Fewer calls to support? Longer visits on the website? More online sales? You may have to be creative in your questions to get a real, actionable answer to the question of ‘How are you going to measure success?”

Known Usability Issues
Sometimes this has to be its own meeting, or part of requirements gathering or a heuristic review, but it’s worth asking the team at a high-level at the start of a project what they think, or what they’ve heard, or what they know from usability studies, to be issues of usability. If its an existing product or site there always are some. If its a new product or site, find out what usability issues the team thinks their other products or sites have, or what issues the competitive site or products have. It may be anecdotal at this point but it gives the client the chance to tell you what issues they would like to see addressed.

Technical & Business Constraints
Take some time to find out what existing business rules or technical constraints might rein-in some great concepts that just can’t be developed. This could include lack of technical resources, or maintaining code in an older platform, or aligning to an existing database structure. Or perhaps some business restraints are the need to incorporate 8 existing websites that belong to 8 different product owners (I’ve seen worse!).

Scope Outline
It’s useful to have a high-level bullet-list of the project scope, even if that was outlined in the SOW. It’s helpful to add priority of items here, so you can discuss this as a team.

Out of Scope Items
Specify the things you understand to be out of scope. Again, even if this was in the SOW, it’s worth noting here because in reviewing it with the client, you may find some assumptions on one side or the other that don’t match.

Getting the information from the client
I’ve found the most useful way to actually get this information from the client or product owner is to
1) make each item a slide in a presentation – some slides won’t have any information except a question when you review it with the client/team, because you need them to give you that information ,
2) review it IN PERSON (or virtual meeting) in your project kickoff meeting, and
3) get the information you’re lacking in the meeting from the client/team for the areas you have gaps (sometimes its most of the deck).

If you just email it off as a list of questions and wait for the client to fill it out and return it, that will have a very low response rate and the answers will probably not be very thorough. You may have to prod and pry to get some answers, which is good, because it gets the team thinking.

This is a list of things that seems to work for most projects, you can scale it to fit your project, but I have found it to be a really useful template for getting client or team input at the project kickoff.