A UX brief is usually treated as a well-groomed doc for stakeholders to review, but i have always felt that it could be more than that. Instead, I use it as scaffolding for the entire UCD process itself. Everything that has to happen for the project to happen can live within the doc.

I shared my thoughts on this as a talk. Here are the notes from then.

Hat tip to Chuck Job, who taught me a great deal about writing UX briefs when we were on the same team.

Artifact vs process

Think of a vine on a scaffold. The process is the vine and the brief is the scaffold, the structure that lets the process grow in a useful direction. You use the scaffold to groom the vine, not the other way around.

UX brief, the artifact vs the process: an iceberg with the artifact above the waterline and the process below, a clean dish rack beside a sink full of dirty dishes, and a vine growing on a scaffold

Constants and variables

A brief can hold a long list of ingredients: overview, problem statement, objectives, timeline, target audience, user needs, constraints, scope, context, success metrics, budget, roles, stakeholders, risks. All helpful, but overwhelming if you try to tackle them all at once.

I find it more useful to sort them by how often they change.

  • Constants are the anchors: target audience, user needs, objectives, roles. They rarely change, and if one does, it’s a different project.
  • Variables are the moving parts: budget, timeline, stakeholders and more. They change all the time, someone else usually owns them, and they may shift without prior alignment.

Write the constants down once and spend time getting them right. Over-communicate the variables: what they are today, who owns them, and when they last changed.

Categorization of the ingredients into facts (knowns): target audience, roles and responsibilities, user needs, objectives; and variables (unknowns): budget, stakeholders, project timeline, success metrics

Humans and their incentives

The other half of a brief is people. There are three kinds whose incentives matter:

  1. Users
  2. Project team
  3. Stakeholders

What does each of them want? We tend to think about users first, but thinking about the other two is essential to getting things done in a large organization.

Alignment on product needs makes us effective. Alignment on human needs makes us efficient.

Data redundancy

The brief is a narrative for humans, and it sits next to other documents written for other humans:

  • Review deck for stakeholders
  • PRD as the source of truth for product requirements
  • UX brief as the source of truth for the UX point of view
  • User guide for customers

Add the engineering design, the pitch deck, the Figma file, the content strategy and the research plan, and they all overlap in intent and information. That makes it confusing to know which one to use when, and keeping several overlapping documents up to date is cumbersome. Redundancy helps work around some of Conway’s law in a large organization, but it’s still not efficient.

Project artifact ecosystem: PRD, UG, UX brief, eng design, pitch deck, Figma, content strategy and research plan, with a bar under each showing how much it overlaps with the UX brief

That’s why I think the brief needs to evolve. At first it’s a catch-all that helps the UXer get oriented. Then it’s the source of truth that gets your team aligned. Finally it’s an archive, for posterity and learning.

Flow diagram: all the details leads to alignment, then risk mitigation, then source of truth, with solutioning and stakeholder overviews branching off below

Building intuition for what it should and shouldn’t do helps a lot, and it’s different for everyone’s process. Here’s where I’ve landed.

Good at:

  • Alignment on objectives, business goals, user needs and the problem
  • Cooperation on timelines and roles
  • Efficiency, risk mitigation, and being a source of truth

Not good at:

  • Solutioning
  • Stakeholder overviews
  • Holding every detail

Takeaways

  • Keep it a hub. The brief is a source of truth for the UX point of view that links out to the details.
  • Know the incentives. Understanding what collaborators and stakeholders want is most of what makes us effective.
  • Bring partners in early. The brief is a chance to build a common language with cross-functional partners and involve them sooner. It’s also the best document for every UX role to work on together.
  • Pick your battles. Incentives tell you which ones are worth fighting. Aim for the ideal experience, but keep business needs, your customers’ operational realities and your own team in view. Moving the ideal means holding the operational complexity and the technical constraints in mind at the same time.