UX is Process: How to Intake a New Project

Creating consistent and repeatable intake process for your team

In This Series:

1. How to Intake a New Project (you are here)
2. Actionable User Insight
3. Design from a Creative Brief
4. The Design Sprint that works for you (forthcoming)

Article updated on January 14, 2018 to include two different assumption worksheet formats.

Introduction

Stop me if this sounds familiar. There’s a wall a lot of aspiring and establishing designers hit. You want to practice UX the way it was taught in school and on the blogs but neither source taught you how to deal with multiple up-line authorities that don’t fully agree with one another.

The misalignment leads to waste, rework, and frustration. Eventually someone pulls the plug and either a businessperson or engineering team decides on a design, leaving you (the designer) to push pixels in Sketch or Photoshop. You know you’re polishing a turd but you’re doing it under orders from the person who pays your bills.

It’s not what you leaned in class, and it’s not how things are supposed to be — but what to do?

This article series is written primarily for the benefit of a community of designers who got into UX to make the world a better place but don’t know how to structure a project for success. It’s also written for students who are, with good reason, terrified about their first/next steps. For the veteran readers, it’s a nice review of techniques I’ve accumulated over the years. Perhaps you’ll find some process notes that are worthy of emulation.

Alright then. Let’s get started.

First: the most important thing you can understand right now is that UX isn’t a job, it’s a process that contains a series of jobs. You may be in one or more of those roles as the UX lead on your team (UX Researcher + Interaction Designer is a classic hybrid) yet as the saying goes “You can do anything but you can’t do everything.” (yes, I’m looking at you… unicorns)

UX Design is not just about software. Service and event design are huge upcoming fields and product design (better known as industrial design) predates software and the web by decades.

UX Design is, in a lot of ways, about creative and strategic process more than it is deliverables. The biggest procedural challenge faced by growing professionals usually starts with learning how to intake a new project, articulate a design challenge, align a group of stakeholders, then decide what a team is going to build. The rest, as they say, is just details.

The first step in this process may look familiar to anyone who has ever worked in a startup because, in a lot of ways, a UX Design challenge mirrors a startup design challenge. In both cases, we need to know several things before we can start to ideate or evaluate design concepts:

1. What is the high-level opportunity?
2. What assumptions are the design and business teams making?
3. How can we validate those assumptions, aligning knowledge and expectations with real data, to form a strong partnership for ideation?

Why this stuff matters

As a kid, did you ever play a version of a game called telephone?

It’s a game with a simple premise, and it’s often presented as a way to understand how rumors and misunderstandings get started when a group doesn’t communicate directly.

1. Put a bunch of people in a circle, the more the better (within reason).
2. Hand a piece of paper with a statement written on it to the first person in the chain and have them read it silently to themselves.
3. That person whispers what they read in the ear of the next person in the circle, who whispers what they were told to the next on down the line.

By the time the statement reaches the other end, hilarity ensues. It’s often nearly unrecognizable. You then jump to a few spots back along the line to see how it changed over time.

This happens all the time with the collective vision for product design, where the results are decidedly less hilarious. If you’re not 100% sure you agree, try an experiment. Go ask a few different people at your business the same question about your product or service. Make it something simple like “what our product does for people” or “who is this product is for?” 99 out of 100 times, you’re going to get some pretty divergent answers.

Now apply that trend to the vision for a new product, one that doesn’t exist yet. Viewpoints abound and all of them have some measure of value. Not all of the value statements are exactly the same though, which creates some real headaches when a designer tries to get their work approved for production.

In the end the highest ranking leader dictates design based on their gut, and the result is exactly what you would expect.

Spoiler warning: it’s not the decision maker who gets the blame when the product goes sideways after launch. In the Silicon Valley, this produces what we call a “resume generating event”.

Our journey begins with a single step: the clear articulation of an opportunity.

Identify Your Opportunity Statement

Every innovation starts in the same place but sometimes it takes a lot of heartache and tears to find it. There isn’t time for heartache or tears before the end of this article, so we’ll skip that part and just articulate the high-level opportunity we’re trying to solve for.

It’s pretty easy to spot a team that hasn’t done this. You’ll see a lot of emotion around the issue but a weak and muddled expression of what should be a fantastic product or service. If it feels like your company’s product is trying to be different things to everyone, while pleasing no one, you’ll probably find conflicted opportunity statements at its root.

Don’t be shy about backing up to this step just because you’ve got Series B funding in place and investors think they’re close to a breakthrough. Clarity of purpose begets clarity of design.

More often than not, when I ask for an opportunity statement, I’ll get a very technical answer back.

Me: What high level opportunity are we trying to solve for?

Stakeholders: immediately tell me what they want to design, and a bit about how it’s supposed to operate.

Unfortunately, that isn’t an opportunity statement, it’s an execution. I’ll add a bit of context and ask again.

Me: What OPPORTUNITY are we trying to capture? As in what problem does the execution I’ve just had described to me attempt to fix?

Stakeholders : “We want to use compelling content to position product X as a leader in the mid-market space, where our competitors have made inroads since the merger.”

That’s good! That’s less executional and it tells me the actual goal that will accomplish an opportunity statement. What we’re trying to get at, however, is one level of inception further up.

The goals that stakeholders are intimately familiar with exist in pursuit of the high-level opportunity. With that final bit of context in place I will ask the question a third time and hear something like:

“Mid-Market represents an undercapitalized segment in the storage space, and small gains at scale translate to huge ROI increases. We need to re-establish a dominant message in that space.”

Yes, this. This is the opportunity.

When you find your opportunity statement it’ll feel like a very tightly focused value proposition from a mini-business plan. This is not an accident. As we established earlier, a UX Design project is… just that. Those of you familiar with my work know that the sprit of UX is essentially entrepreneurial.

This opportunity statement will be the founding component of a creative brief, which you’ll read all about in the third article of this series.

The Assumptions Worksheet

Credit for the assumptions worksheet goes to Jeff Gothelf, although I’ve seen a dozen versions of it since he first published the activity in Lean UX, which should be required reading for any aspiring or professional UX Designer.

Invalid assumptions lead to broken designs

This activity expands on the idea that before we start designing a solution we should make sure everyone agrees on what we are trying to build, for whom, and why.

There are a lot of important questions that come up in this context. Jeff’s work centers around business and user assumptions but other teams have come up with versions that anchor questions to the lenses of human-centered design: Desirability, Feasibility, and Viability (or the four-lens approach: people, design, business, and technology).

Do people want it? Can we build it? Should we build it? (IDEO)

The 4-Lens Version of Human Centered Design that I Use on Studio Projects at Dell EMC

I’ll provide two different versions of the assumptions worksheet here.

A Jeff Gothelf Style Assumptions Worksheet

Business Assumptions

• We believe our customers have a need to…
• Those needs can be solved with…
• My customers are (or will be)…
• The primary value a customer seeks is…
• Other things that create value for the customer are…
• We will acquire the majority of our customers through…
• We will make money by…
• Our primary competition on the market is (or will be)…
• We will beat them due to…
• Our biggest product/service risk is…
• We will mitigate or solve this by…
• We will define our success by the following customer behaviors…
• What other assumptions do we have that will cause us to fail if they aren’t true?

User Assumptions

• Who is the user?
• Where does the product/service fit into their work or life?
• What problems does our product/service solve?
• When and how is our product/service used?
• What features are important?
• How should our product look and/or feel?

Ian Armstrong’s Assumptions Worksheet

Important Note: If you don’t have enough information to answer a question, skip it. Not every stakeholder group is expected to have a well-defined position on other group’s concerns.

Business Assumptions

• What opportunity are we going to target?

• What is preventing us from doing that now?

• Who is our primary competition in this space?

• What is our advantage over them?

• What is our biggest service risk

• How can that risk be mitigated?

• What user-behaviors will define our success?

Technical Assumptions

• What is our biggest technical/engineering challenge?

• Do we have any regulatory risks?

• Will any internal policies get in the way of an ideal solution?

• What financial constraints are we under?

• Have we established a research and testing budget?

• What delivery deadlines are we facing?

Design Assumptions

• What branding guidelines are we using?

• What platforms are we going to support? o Browser (HTML, web app, isomorphic JS, AEM, Jive, Hybris, etc.)

— Native App (android, iOS, Alexa, etc.)
— Video (webinar, live event, streaming, downloadable, etc.)
— Audio (podcast, download, transcription services, etc.)

• Is this a new design, redesign, iterative update, content revision, or clone?

• Are we missing any critical information required to design a solution?

• Will this require a design sprint or can it be handled by a single team?

• Do we think the design team will need to hire additional contractors?

User Assumptions

• Who is / will our users be?

• What problem do they want to solve?

• How are they solving this problem today?

• Why are they unhappy with the current solution?

• What features do they think are important?

• What is the primary value they seek?

How to use the completed worksheets

Like the primary objective, you’ll find there are often enormous divisions between what stakeholder groups and the design team believe about the incoming project. As you can imagine, a misalignment on something as fundamental as who the customer is, what they have a need to do, things that create value for them, or how we measure success within the user experience will make it nearly impossible to produce high quality work. All of your best ideas will die in committee.

As we’re fond of saying in the design business: a stakeholder is anyone who can derail the train, and there are many stakeholders.

Getting Into Alignment

For each of the questions you’ll want to review answers. I like to fill out my own worksheet based on my understanding if the business request. I’ll then run through each one and call out the thing being assumed:

An example of my assumption callouts

I’ll then go through our existing research and see how many of the assumptions can be validated. This almost always requires checking in with the team that filled out the worksheet and, more often than you’d think, they’ll have an interesting bit of research to back up their claims. After I’ve got that information I end up with three three categories of assumptions:

1. Valid assumptions, with the source documented
2. Valid assumptions that are in partial or full conflict with one another
3. Invalid assumptions, that need to be risk-assessed

Conflicting assumptions between teams are unbelievably common and can often be reconciled with research, or by getting additional context. If an assumption is unverified and there isn’t a trustworthy source available, it will look like one of these:

0. If invalid, this will cause the project to fail
1. If invalid, this may cause the project to fail
2. If invalid, this may impact the efficiency of our user journey
3. If invalid, this is unlikely to have any measurable impact

Any Category 0 or 1 invalid assumption needs to be researched before beginning the design phase.

Category 2 is the sort of assumption that is nice to validate but it isn’t essential, especially if doing so would cause significant delays to verify. Stakeholders find being forced to wait for things... distasteful.

Category 3 is a black hole where things to go die; we don’t assumptions in this list because they are irrelevant.

Once you have performed the research necessary to eliminate all stop-level invalid assumptions you’ll have completed an aligned statement of beliefs, which becomes part of your strategic documentation. It’s basically a merged version of the answers, which all stakeholder groups formally approve.

Next Steps

Your opportunity statement and aligned statement of beliefs will be joined to a series of user personas (article 2), which together form the backbone of a creative brief (article 3).

Continue to the next article in this series

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Leave a note when connecting on LinkedIn, especially if you have a weird title.