how to not design

Download How to NOT Design

Post on 17-Aug-2014

1.280 views

Category:

Design

2 download

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.

TRANSCRIPT

  • 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 d

Recommended

View more >