This document discusses how to successfully implement design work within organizations. It begins by describing how design work often gets repeatedly revised during implementation due to various stakeholders providing feedback. It then argues that defining the organization's personality, examining its structure, and establishing clear processes can help design work survive implementation. The document uses spectra to define an organization's views on design, innovation, and customers. It also discusses experimenting with different structural approaches. Finally, it emphasizes establishing a clear problem definition and focusing on designing testable solutions. The overall message is that understanding an organization's context is crucial to ensuring good design work is successfully implemented.

1. Title slide

2. So somebody within your organization
wants something. For simplicity’s sake,
let’s call them “Stakeholder.”

3. Stakeholder tracks down the staff unicorn,
somebody who is an expert designer, a
killer IA, a veteran content strategist, all in
one. Stakeholder explains what they want,
Unicorn designs it, it’s awesome and
everybody Lives Happily Ever After. That’s
how it works in your organization, right?

4. I don’t know most of you, but I’ll tell you right now that that is NOT how
it works in your organization, at least not the Happily Ever After part. If
Stakeholder goes directly to Unicorn, the work is going to get
redesigned a half-dozen times before a single customer sees it.
Not that your organization calls those revisions “redesigns.” It starts
politely enough, with somebody saying “this is great, but did you
consider ...” Revise, revise, revise. Then it’s “oh, did you run it by ...”
Revise, revise, revise. Then “This doesn’t conform to policy 37B ...”
Revise, revise, revise. And finally, “Who authorized this? This has
some major issues ...” Revise, revise, revise.
The result? Genius design sliced and diced into mediocrity; one pissed
off Unicorn; and a stakeholder who is either frustrated or clueless about
the gap between what they needed to accomplish and what actually
launched.

5. Austin Govella, a Texas-based unicorn,
says “organizations design experiences,
not designers,” and like it or not, he’s deadright. We can rage against the machine all
we want, we can try to pound good design
into our organizations by sheer force of will,
we can sneak around in the shadows trying
to trick good design into existence, but all
those efforts are going to fail eventually.
So, do we roll over and try to develop a
taste for mediocrity? Hell, no.

6. There are steps we as user experience professionals can introduce to greatly
improve the chances that good design work will survive our organizations. I’m
going to talk about three steps and my argument is that all of them fall within the
purview of UX design ... so we’re not going to ask anybody’s permission before
we implement them.
We still need Stakeholder to do their best describing what they need. If they’re
good at their jobs, they will focus on the “what” of that and let us be the experts
of the “how” of it. And, of course, we should help them with that.
Before we move a single pixel, we take the time to define the personality of our
organization. Just like with humans, organizations develop their personalities
young and at some point it locks down: They become who they’re going to be for
the rest of their existence. Just like with humans, trying to change personalities
is pretty much a waste of time, the effort is better used to define what exists
instead of trying to improve it.

7. First, it’s going to be helpful to describe how your organization sees design. I’m not
talking about mission statements or any other kinds of happy talk artifacts. I’m
saying we need to locate the organization along a spectrum. At one end of the
spectrum, design is lipstick on a pig, a superficial change to appearance that
provides no meaningful value. At the other end of the spectrum is the kind of place
we’d all like to work where user-based design is one of the greatest tools available
to us to solve big, fat, hairy problems. In the middle are organizations that see
design as more meaningful than lipstick, but treat it like a surprising perk of some
other process. Or maybe the organization has made enough progress to provide
structural safeguards around design by empowering a design department. There’s
not real organizational understanding of design, but there is some investment in the
people who practice it.
As tempting as it might be to place your organization on this spectrum based on an
aspiration, the point is to honestly appraise how design is treated. This is a data
gathering exercise, not a motivational technique.

8. To get the next piece of data for defining your organization’s
personality, we need to identify how it views innovation and we’ll
again use a spectrum. At one end, innovation is primarily a tactic
to generate money. At the other end of the spectrum, innovation
is what happens when the organization is effectively solving big,
fat, hairy problems. It’s a side effect. Towards the middle of the
spectrum, innovation is more than just a money-maker, it has
become some sort of policy or has been built into KPIs. That’s a
little crazy, but at least it’s value is better appreciated. Some
organizations go even further in valuing innovation, but they can
only understand it structurally when they put it into a job title with
a specific job description.
Again, it’s not like the organizations at the far right of this
spectrum “win” or the ones at the far left “lose.” Personalities are
locked in early, so placement on these spectrums isn’t going to
change quickly and might only be adjusted slightly.

9. The third and final spectrum to look at for
defining an organization’s personality is
about customers. On one end of the
spectrum, customers are almost
exclusively seen as a source of income. At
the other end, they are valued as key
assets in the development of products and
services. In the middle, and this is where
most organizations land, customers are
“owned” by a specific group.

10. After placing an organization on each of these three spectrums, we can do some interesting analysis. If you are in this room
as a representative of an organization that sees design as an amazing problem-solving tool, harvests innovation as part of
that problem-solving, and takes full advantage of customers as co-designers for product development, the rest of us are
really, really jealous. In fact, my advice is to keep it to yourself for the rest of this talk. I can’t promise you’ll be safe in this
room.
The middle example here reflects an organization that doesn’t understand design and positions customers out of corporate
convenience, but they do bind innovation to problem-solving. This is like a bunch of mobile app startups that I’ve seen. They
get their investors lined up and hire for deep engineering talent and some time after their first release, they bring in their first
design staffer. By their third release, they’re pounding on their customer care folks who they expected to know everything
customers want.
The third example is where somebody has been successful arguing the case for design, but they are way out in front of the
rest of the organization. This kind of organization is probably going to have great planning and not-great implementation.
Hopefully, what you see here is that the simple combination of three spectrums can be a powerful way to define the
personality of an organization. The challenge for the first organization is to keep standards and momentum high. If you
worked for the middle organization, you might need to focus on small wins and solid, but tightly focused design solutions
rather than enterprise-level magnificence. UX professionals in the bottom organization might need to build expertise outside
of design to move things through the organization.

11. Now that we’ve done some analysis around
organizational personality, we can take a
look at structure.

12. Your organization’s structure probably feels
substantial, like it’s made of concrete and
steel. If true, building it around a
personality that is unlikely to change much
would really limit your options. I’m going to
argue that the foundational feel is a bit of
an illusion, that really structure is like the
walls of a beehive.
Bees can build their homes in any dark
enclosed, dry space. Worker bees use
honey stored in their stomachs to make
bees wax, which they shape into hexagonal
tubes.
In the same way, the structure of an
organization can be modified to fit its
environment; it can be easily built and
rebuilt over generations of workers; it is
sized to fit the existing population rather
than for some larger or smaller future. That
flexibility is helpful if I’m right about the
inflexibility of the organization’s personality.

13. So let’s imagine the organization as a
hairball. Does that seem fair? Let’s
consider some structural variations.

14. To avoid having new work swallowed up by
the hairball, some stand up skunkworks
operations completely outside of the
organization. Lockheed Martin set up one
to build aircraft more than 50 years ago.
More recently, Capital One set up its
Innovation Labs outside of the bank’s
massive global system.
Advantages: Less institutional baggage
and a fresh start, faster product
development.
Disadvantages: No way to improve the
hairball, little mobility for staff between the
hairball and the skunkworks, big buckets of
resentment

15. The tactic I’ve used the most over the
years is to launch pirate operations within
the existing hairball. You create a discrete
space where much of the institutional
etiquette is ignored.
Advantages: Speed for short-term
solutions, higher levels of job satisfaction,
less risk for individuals than for
Skunkworks.
Disadvantages: Eventually, every pirate
operation is shut down and eventually
forgotten.

16. Every organization renovates, but this isn’t
that. This is when an organization is under
major construction all the time. Structure is
constantly shifting.
Advantages: Low or no fear of change,
things that don’t work can be quickly
replaced.
Disadvantages: High staff frustration and
turnover, continuous crisis mode, lack of
organizational patience, not great for
people problems.

17. Some organizations build themselves
around getting other people to provide the
key work of the company. This isn’t just the
ones trolling around for offshore discounts
on wages. Some, for example, choose to
stock up on managers rather than doers.
Advantages: Frankly I can’t suggest any –
I’m the guy usually arguing against this.
Maybe speed to solution, since you hire
people who already know how to do the
thing you need done.
Disadvantages: You are basically paying
for other companies to increase their
expertise.

18. You may choose to experiment with one of
these structures, or some other solution,
but just be consciously examining your
organization’s structure, you’re going to
increase the alignment and relevance of
how you design.

19. Okay, so you’ve defined your
organization’s personality, you’ve studied
your existing structure and played around
with potential alternatives to it, you’re still
not ready to design yet. It’s time to look at
process.

20. Design is what it does and what it does is
solve problems. With your success on the
line, are you really going to trust anybody
else to define the problem you’re trying to
solve? People and organizations suck at
defining problems. They tend to intertwine
what needs to happen with how it will
happen; they pile on complexity and lack
the intestinal fortitude required for clarity.
Every problem is the same: You’ve got a
rock on this side of the river and you need
to get it on that side of the river. One way
or another, you’ve got to get your problem
definition to that level of specificity.

21. With a laser-sharp problem definition, now it’s time to figure out what
you’ll actually be able to test. Will your design make someone’s life
better? Maybe, but how would you prove it? Other unrealistic research
targets that we hear all the time: Find out if people will “like” our
solution, or use it, or be delighted by it. All moshy, subjective terms.
Testable questions include: Have we provided the right kind of
information for people to accomplish their goals with this design? Is
this how our most important users think about our product? Does this
work they way our most important users expect?
By talking about this stuff before you design, you will produce more
pragmatic solutions. Pragamatic solutions are easier to move through
organizations because they don't require as much salesmanship as
more subjective ones.

22. You can come up with plenty of effective
processes, but before you do, try
identifying the approaches that are doomed
in the places where you work.

23. Think back to those personality spectrums I
talked about earlier. If, for example, you
work at the organization that thinks design
is about making it look pretty, and thinks
customers are the responsibility of one
department, design research is going to fail
every time. This is a tough pill to swallow,
because we know that organization actually
needs to test designs even more than other
places. But this isn’t about justice or
wisdom, it’s about what will be effective in
that specific environment.

24. I started by talking about the myth of the
unicorn, that all you have to do is get the
right designer and they can magically solve
any problem for any organization. The
reality is that even the perfect solution can
get chewed up and destroyed by the
organization.

25. If you really want to take advantage of that
unicorn, take the steps I’ve suggested
before a single pixel has been designed.