This talk presents five specific, actionable tactics to shore up design processes ravaged by the vagaries of your organization. You will gain the tools necessary for managing problematic stakeholders; analyzing your organization’s design tolerance; and defining problems in ways that design can successfully address.

1. TROUBLE
SHOOTING
YER
BUSTEDASS
DESIGN
PROCESS
Dan Willis, Consultant, dan@dswillis.com
My name is Dan Willis. I’m a UX designer and consultant and I’m going to talk about design for awhile this morning.

2. http://www.peterme.com/2013/09/26/the-double-diamond-model-of-product-definition-and-design/
There are plenty of excellent diagrams out there that skillfully explain how design should happen.
This is Peter Merholz’s version of the “double diamond” design process for products. It makes so much sense!

3. Jerry Cao, UXpin, https://designmodo.com/design-process-tips/
Jerry Cao from UXPin offers this Zen-like depiction of the design process.
Each launch leads you back to the start and all things have their place under the sun. It’s the circle of life!

4. https://developers.google.com/design-sprint/
This is how Google describes its approach to design sprints. It’s calming, isn’t it? It’s like watching a lava lamp. Each circle flows into the next … These are all such
wonderful ways of looking at design.
The problem for me is that no matter how much I agree with the content and intent of these diagrams, none of them reflects what it actually feels like to do design at
most of the places I’ve worked.

5. This is a more accurate picture of design at the places I’ve worked.
When the design process feels like this, those wonderful diagrams, and the books and articles that go with them, just make me feel stupid. They make me think I’m doing
something wrong. I go to conferences like this one and if the subject comes up, I stare at my shoes and mumble a bit and hope nobody asks me about my process. I feel
like an imposter.
If this sounds familiar to you and if this sketch is closer to your experience, I don’t think you’re an imposter. In reality, design is a sloppy thing for many of us. We feel
embarrassed by the concessions we’ve made. We try so hard to follow the idealized, user-centric processes we’ve read about in books and heard about in talks, but
moving design solutions through organizations requires negotiation. Sometimes we have to make radical adjustments just to get a thing launched.
I’ve spent a good chunk of my career overhauling bad design processes. It’s hard work and mostly thankless, but more importantly, significant change takes a really long
time. And during that time, you have to work within the system you’re trying to replace.
So if you’re stuck with a busted ass design process there are some things you can do to make things better that don’t require staff re-orgs or even the support of
leadership. I’m going to talk about five tactics. Each of the five are independent of one another.

6. TA C T I C N O . 1 A S S E S S
O R G A N I Z AT I O N A L
C A PA C I T Y F O R D E S I G N
Have you ever started a new job at a place that in the past had brought in a big name consulting company who delivered a bold recommendation for what that
organization needed to do to be successful? I’ve followed Adaptive Path and more recently, Ideo and in both cases, in the long run, those recommendations did more
harm than good.
Don’t get me wrong, Adaptive Path and Ideo did exactly what they were supposed to do. You don’t pay consultants to recommend moderately better solutions. You
expect them to stretch your organization to its limits. But after the engagement ends, the stretching doesn’t continue. Most organizations revert.

7. TA C T I C N O . 1
A S S E S S C A PA C I T Y
F O R D E S I G N
“UI/UX” in job descriptions
Capacity
Every organization has its own capacities:
• Microsoft has a high capacity for engineer-centric solutions. How else can you explain Microsoft Word?
• Amazon has a high capacity for live experimentation. Those maniacs will make anything public in short bursts of time.
• Apple has a low capacity for standardization.
These things were just as true a decade ago as they are now. That’s because generally, organizational capacity doesn’t change. And when capacity does change,
especially if it expands, it happens very slowly.
This first tactic is about cold analysis, not aspirational marketing. It’s about finding indicators of the organization’s true ability to support and launch sophisticated design
solutions.
When I see “UI/UX” in a job description, I can usually assume that either the organization doesn’t know what either of those terms mean or someone with a limited
understanding of design has written the ad. In either case, I’m going to bet that it reflects a place where ambitious, sophisticated design solutions won’t get support. I
can expect a narrow scope and definition for design.

8. Capacity
Designers review user stories
TA C T I C N O . 1
A S S E S S C A PA C I T Y
F O R D E S I G N
The marriage of agile and UX was rocky at the start, but they’re getting along much better these days. They’ve always had important things in common, like their true
love for defining functionality based on the goals of the people who use the things they build: user stories.
User stories can be an indicator for the kind of support you can expect for sophisticated design solutions. You want to look for:
• Well-crafted user stories that talk about a specific need without baking a solution into the description.
• A collaborative approach where developers, product people and designers discuss user stories rather than one where they are just delivered from one group to another.
• A collaborative approach where designers are as likely as anyone else to create user stories.
Any organization that has all three of these things is going to have a pretty decent capacity for design.

9. Capacity
Designers are in senior leadership
TA C T I C N O . 1
A S S E S S C A PA C I T Y
F O R D E S I G N
If design is the primary focus of people above the director level, it usually reflects about as high capacity for design as you’re likely to see anywhere. Think of Jonathan
Ive, Apple’s Chief Design Officer or Richard Dalton, the VP, Head of Design for Commercial Banking at Capital One.
Support for design in these organizations doesn’t necessarily come from those executives. (It frequently turns out that executives spend most of their time and energy
being executives, regardless of their divisions or backgrounds.) But the role of design executive exists at organizations that define design widely and have structures and
processes in place that provide real support for sophisticated design solutions.
Once you’ve got a realistic gauge of design capacity, you can figure out if your design process is based on appropriate expectations. For example:
• If your organization thinks design is making pretty things and the goal of your design process is to deliver experiences that satisfy key business metrics, you’ve got a
pretty serious misalignment.
• Or conversely, if your organization relies on design to satisfy the most important goals of its most important users and the design process is just an excuse for
stakeholders across multiple divisions to argue about what shade of blue to use, you are in for a world of hurt.
To deal with a busted ass design process, first define your organization’s true capacity, then adjust your efforts to align with that capacity.

10. TA C T I C N O . 2
A D J U S T Y O U R
S TA K E H O L D E R S
Let’s talk about stakeholders. To be successful in most organizations, we have to skillfully manage our stakeholders. But that doesn’t mean we have to treat them as a
homogenous team of equals.

11. People with the expertise
or ingenuity to solve
problems relevant to
a particular effort
People with the authority or influence
I can depend on to move
a design solution through
my organization
People who are
neither of these,
but who I have
no choice but
to include
S TA K E H O L D E R S
In my world, stakeholders are the combination of these three groups:
• People with the expertise or ingenuity to solve problems relevant to a particular effort
• People with the authority or influence I can depend on to move a design solution through my organization
• People who are neither of these, but who I have no choice but to include
There are other useful ways to categorize stakeholders.

12. TA C T I C N O . 2
A D J U S T Y O U R
S TA K E H O L D E R S
RACI
Responsible
The poor slobs who
do the work
(That’s probably you)
Accountable
It should be one
person’s ass if things
go badly
Consulted
Most people will
think they belong
here
Informed
This is where most
people actually
belong
We can swipe this tool, a RACI chart, from our project management colleagues. It’s a way to group stakeholders by role so we can assign different responsibilities and set
different expectations:
• Responsible - usually not stakeholders, but the working team
• Accountable - has to be just one, and that can be difficult for people to accept
• Consulted - The fewer the better here
• Informed - This should be most stakeholders
Mixing information from the last screen and this one: You try to put the people who can help you in the Consulted group, you try really hard not to end up with a clunker
as the single accountable stakeholder.
Role assignment has to be a transparent process. For it to stick, the stakeholder has to agree to their role. It’s a good conversation if somebody thinks they should be a
“C” when you think they should be an “I.” Arguments about that can happen right at the beginning of the project when they are most effective and least destructive.

13. Antagonistic
towards design
Supportive
of design
Influential
Not influential
Influence
mapping
TA C T I C N O . 2
A D J U S T Y O U R
S TA K E H O L D E R S
Influence mapping is another way to analyze stakeholders. It’s a four-square with the person’s perspective about design on one axis and their influence within your
organization on the other axis.

14. Antagonistic
towards design
Supportive
of design
Influential
Not influentialTA C T I C N O . 2
A D J U S T Y O U R
S TA K E H O L D E R S
You locate each stakeholder accordingly and four groups emerge. The two quadrants with influence can have the most immediate impact, but it’s worth coming up with
strategies for dealing with each of the four types of stakeholder.

15. Antagonistic
towards design
Supportive
of design
Influential
Not influential
Feed
Promote
Locate
Educate
TA C T I C N O . 2
A D J U S T Y O U R
S TA K E H O L D E R S
There’s a love fest with the folks who are both influential and supportive of design. Obviously, these are the folks who get the holiday baskets and a steady stream of
details throughout the project.
It would be a mistake to ignore the folks in the lower right quadrant. The hardest, slowest effort here is to try to change somebody’s thinking, so take advantage of the
folks who already have a positive opinion of design. Maybe with our help, they will become more influential.
People who have less influence and are antagonistic towards design are usually long-term projects. These are the people we talk to after any major success, but avoid
putting too much effort into converting them.
Finally, we have to stay vigilant with the influential who have decided that more design in the organization would mean less of what they feel is important. We want to put
a half decent amount of time and effort into making sure these people never surprise us. And we have to protect our supporters from them, if we can.
None of this requires changes to the organization’s process or structure, so we don’t have to ask permission to use this tactic to improve how design work happens.

16. TA C T I C N O . 3
P R O T E C T
E X P E RT I S E
The scope of digital design challenges in the 1990s was small, usually having to do with building a single Web site to be viewed on a single device. Today, we have to
consider multiple screens and multiple channels as well as interactions with humans in the physical world, and more and more — there are no screens at all. To be
successful, we need easy access to a wide variety of expertise. The challenge for user experience professionals in the early 21st century is to have everyone participate
in design while still protecting the expertise of all involved.
Every conversation needs to be like riding a seesaw, where the level of our expertise rises and falls, rises and falls throughout the discussion. As we talk about design, I’m
an expert and a product person is just a smart woman with an opinion. As we shift to what that design needs to accomplish in the market, I become the smart person
with an opinion and she speaks with authority. Back and forth, up and down until we define and solve big problems.
If your design process is busted, one of the things you might want to look at is how expertise is (or isn’t) leveraged during projects.

17. TA C T I C N O . 3
P R O T E C T
E X P E RT I S E
210calories 40
Savings in a week
Savings in a year
Weight loss in a year
1,190 calories
61,880 calories
18 pounds!!!
vs.
As far as I know a single, powerful tool for protecting expertise has not emerged. Which means we may need to get by with small tactics that add up. Here’s one.
Based on the percentage of its population that is obese, the U.S. is the 12th fattest nation in the world. (Canada is number 25.) And we are obsessed with ways we might
trick ourselves into losing weight without going on a big-time diet. If we just substitute carrots for candy bars, for example, we can lose 18 pounds a year!

18. vs.
TA C T I C N O . 3
P R O T E C T
E X P E RT I S E
So maybe there are simple substitutions we can make within our busted ass design process that will protect expertise where it isn’t currently protected.
Despite what I might think of it, it is still a common expectation that a design project at some point should include three solutions that we present to stakeholders for
consideration. This is, and always has been, a horrible practice.
The first response is always “can we do a little bit of each of these ideas?” And by agreeing to the exercise, we’re reinforcing any existing belief that design is about
creating alternative skins rather than solving big problems. But the greatest sin of this technique, by far, is that it involves people creating solutions based on their design
expertise so those solutions can be judged by people who lack design expertise. It is as unfair to the stakeholders as it is to the designers.
Instead of substituting carrots for candy bars, we can substitute a critiquing technique for the three-skins approach:
1. The designer explains the problem they were trying to solve.
2. They describe how their design, as presented in a medium or low-resolution artifact, addresses that problem.
3. The stakeholder is asked to explain how the solution, based on their own expertise, does or does not address the stated problem.
4. With that data, the design is revised and another round of critique takes place.
If your design process tramples on expertise, try this or similarly simple substitutions.

19. TA C T I C N O . 4 F I T P R O C E S S T O S K I L L S
I worked for an international hotel chain for a while, setting up their mobile design practice. Right before I got there, they decided that they would improve their digital
operations by focusing on product management rather than just project management. Their primary tactic in this strategy was to take a staff of project managers and
change their job titles to product managers.
It went as poorly as you might expect. Actually, it might have gone worse than you thought because while none of the new product managers had any actual product
management skills, the project management skills of some of them were suspect as well.
Upgrading to a product development system wasn’t a bad idea, but it failed in practice because it didn’t in any way fit the skills of the people asked to make it work. And
that wasn’t an isolated incident for the organization.
For years, they didn’t ask much of their designers. Designers were rewarded for getting along with people in other divisions no matter how much shit was thrown at them
and no matter how much in the dark they felt. Designers who questioned the value of the shit or who raged against the darkness quickly washed out. It created
generations of mushroom designers.
Then one day, a visionary leader decided he wanted an elite user experience design practice. He was right that such a practice could take on the organization’s greatest
challenges, but it would have required a staff of unicorns. Very few of the mushroom designers would ever get close to becoming unicorns. And unicorns can get a job
just about anywhere, so why would they choose to work in a field inhabited for generations by mushrooms?

20. TA C T I C N O . 4
F I T P R O C E S S
T O S K I L L S
1. Who are your most important users?
(A business question)
2. What are your most important users’ most important goals?
(A user research question)
3. Of those goals, which ones, realistically, can you actually address?
(This is what you build)
This is an anti-climactic tactic. It is an approach based on doing no more than can be supported by existing resources. If successful, it provides only incremental
improvements. But if you’re stuck in a busted ass design process, you may have already realized that a small improvement that succeeds is more valuable than a grand
improvement that never happens.
It can be helpful to analyze how well your current design process fits the skills of your current staff and be open to changing process to fit those people. The goal is not to
extend the status quo, but rather to find small changes that can have surprisingly significant effects.
Here’s an example of one of those small changes. What might happen if at the beginning of every project, your designers helped stakeholders answer these three
questions?
For the more mushroom-like designers, this is a simple checklist; for the aggressive ones, it can lead to a deeper understanding of the problem that the design must
solve. In both cases, this tactic can raise the level of conversation for a project and over time broaden the definition of design.

21. TA C T I C N O . 5
R E D E F I N E T H E
P R O B L E M
Last tactic. I believe that design is what it does and what it does is solve problems. That puts a bunch of pressure on getting a good definition of the problem.

22. TA C T I C N O . 5
R E D E F I N E
T H E P R O B L E M
Make it look
pretty
World
peaceReality
Design solves problems
When you treat the purpose of design as a tiny thing, like making things look pretty, it can only solve tiny problems.
On the other end of the spectrum, problems described with grandiose expectations for design are rarely solvable.
The sweet spot is in the middle.
To be successful, a designer has to take responsibility for both the scope and definition of the problem they’re trying to solve.

23. “I need a button.”
TA C T I C N O . 5
R E D E F I N E
T H E P R O B L E M
Bad things happen when designers fail to take responsibility for problem definition. Here’s a case study.

24. The What The How
TA C T I C N O . 5
R E D E F I N E
T H E P R O B L E M
People have a tendency to rush their way through problem definition in a scramble to get to solutions.
That’s an issue because once you start talking about The How, you are done talking about The What. As soon as you say “I want a big red button,” that button is the only
thing the team is going to talk about.

25. I need to get a good
cup of joe without
increasing the risk of a
full-scale nuclear missile
launch.
The What The How
TA C T I C N O . 5
R E D E F I N E
T H E P R O B L E M
It’s on the designer to disentangle The What from The How and to keep everybody working on The What until the problem is fully defined. Fail to fully define the problem
before starting to design and you will likely spend the rest of the project chasing symptoms instead of delivering an effective solution.

26. F I T P R O C E S S
T O S K I L L S
A S S E S S O R G A N I Z AT I O N A L
C A PA C I T Y F O R D E S I G N
R E D E F I N E
T H E P R O B L E M
A D J U S T Y O U R
S TA K E H O L D E R S
P R O T E C T
E X P E RT I S E
TacticsFER YER BUSTEDASS DESIGN PROCESS
DAN WILLIS @UXCRANK DAN@DSWILLIS.COM
These tactics might fix your design process, but even if they don’t, they will improve the quality of your design solutions and help you feel better about the work you do.
• Consider aligning your efforts with your organization’s true capacity for design
• Treat each stakeholder as the delicate snowflake they assume they are
• Aggressively find ways to protect the expertise of the people involved in your design work
• Fight the urge to introduce brilliant processes that far outstrip the actual skills of your team
• Use design to solve problems and don’t rely on anybody else’s problem definitions
Thank you for your time and please let me know how it goes.