26
Title slide

How to NOT Design

Embed Size (px)

DESCRIPTION

Presented at Big Design Conference in Oct. 2013. Can we finally let go of the Designer/Wizard Myth? Not that it wasn’t an enchanting tale: The socially awkward genius all in black, working vampire hours, wearing headphones and horn rims and cranking out magical solutions to transform mediocre ideas and questionable product management into gazillion-dollar success. In reality, jumping straight to design intensifies any organization’s pre-existing dysfunction and guarantees half-assed solutions and endless cycles of equally ineffective redesign. Design isn’t magic and it doesn’t take place in a vacuum. Like it or not, organizations create successful user experiences, not designers. This talk will outline what an effective UX professional should be doing long before a single pixel has been designed. Participants will walk away with specific “bottom-up” tactics to more accurately define the organization, adjust team structure and tweak process.

Citation preview

Page 1: How to NOT Design

Title slide

Page 2: How to NOT Design

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

Page 3: How to NOT Design

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?

Page 4: How to NOT Design

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.

Page 5: How to NOT Design

Austin Govella, a Texas-based unicorn, says “organizations design experiences, not designers,” and like it or not, he’s dead-right. 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.

Page 6: How to NOT Design

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.

Page 7: How to NOT Design

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.

Page 8: How to NOT Design

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.

Page 9: How to NOT Design

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.

Page 10: How to NOT Design

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.

Page 11: How to NOT Design

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

Page 12: How to NOT Design

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.

Page 13: How to NOT Design

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

Page 14: How to NOT Design

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

Page 15: How to NOT Design

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.

Page 16: How to NOT Design

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.

Page 17: How to NOT Design

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.

Page 18: How to NOT Design

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.

Page 19: How to NOT Design

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.

Page 20: How to NOT Design

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.

Page 21: How to NOT Design

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.

Page 22: How to NOT Design

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.

Page 23: How to NOT Design

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.

Page 24: How to NOT Design

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.

Page 25: How to NOT Design

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

Page 26: How to NOT Design