how to not design

of 26 /26
Title slide

Author: dan-willis

Post on 17-Aug-2014




2 download

Embed Size (px)


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.


  • Title slide
  • So somebody within your organization wants something. For simplicitys sake, lets call them Stakeholder.
  • 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, its awesome and everybody Lives Happily Ever After. Thats how it works in your organization, right?
  • I dont know most of you, but Ill 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 its oh, did you run it by ... Revise, revise, revise. Then This doesnt 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.
  • Austin Govella, a Texas-based unicorn, says organizations design experiences, not designers, and like it or not, hes 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.
  • There are steps we as user experience professionals can introduce to greatly improve the chances that good design work will survive our organizations. Im going to talk about three steps and my argument is that all of them fall within the purview of UX design ... so were not going to ask anybodys permission before we implement them. We still need Stakeholder to do their best describing what they need. If theyre 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 theyre 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.
  • First, its going to be helpful to describe how your organization sees design. Im not talking about mission statements or any other kinds of happy talk artifacts. Im 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 wed 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. Theres 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.
  • To get the next piece of data for defining your organizations personality, we need to identify how it views innovation and well 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. Its 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. Thats a little crazy, but at least its 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, its 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 isnt going to change quickly and might only be adjusted slightly.
  • The third and final spectrum to look at for defining an organizations 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.
  • 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 cant promise youll be safe in this room. The middle example here reflects an organization that doesnt 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 Ive 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, theyre 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.
  • Now that weve done some analysis around organizational personality, we can take a look at structure.
  • Your organizations structure probably feels substantial, like its made of concrete and steel. If true, building it around a personality that is unlikely to change much would really limit your options. Im 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 Im right about the inflexibility of the organizations personality.
  • So lets imagine the organization as a hairball. Does that seem fair? Lets consider some structural variations.
  • 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 banks 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
  • The tactic Ive 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.
  • Every organization renovates, but this isnt 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 dont work can be quickly replaced. Disadvantages: High staff frustration and turnover, continuous crisis mode, lack of organizational patience, not great for people problems.
  • Some organizations build themselves around getting other people to provide the key work of the company. This isnt 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 cant suggest any Im 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.
  • You may choose to experiment with one of these structures, or some other solution, but just be consciously examining your organizations structure, youre going to increase the alignment and relevance of how you design.
  • Okay, so youve defined your organizations personality, youve studied your existing structure and played around with potential alternatives to it, youre still not ready to design yet. Its time to look at process.
  • 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 youre 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: Youve 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, youve got to get your problem definition to that level of specificity.
  • With a laser-sharp problem definition, now its time to figure out what youll actually be able to test. Will your design make someones 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.
  • 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.
  • 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 isnt about justice or wisdom, its about what will be effective in that specific environment.
  • 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.
  • If you really want to take advantage of that unicorn, take the steps Ive suggested before a single pixel has been designed.