I was talking to someone about how UX works at Marketo and how it is different than other places. At Marketo, the UX team has specific responsibilities and ownership within the process of development that differs from the norm.
Product Management defines WHAT the feature needs to do. They define it’s required capabilities. PM does not however, provide wire-frames or storyboards or any details of implementation. User Experience defines HOW those requirements are manifested in the system. UX defines how it works and what it looks like. We provide specific details around how the system should behave under various inputs and constraints. We define the edge cases. Let’s call this model “UX designed“.
In most companies (to my knowledge), the product management team is responsible for the WHAT as well as the fundamentals of the HOW. UX is there to help PM with the details. If there is any ownership it is focused on how it looks graphically. If your PM team makes wire-frames and flows, they are designing the experience. If they are “collaborating” with UX to do that, but are still ultimately responsible for those documents, they are still designing. Let’s call this model “PM designed“.
Note: We have ample collaboration happening for all stages of development. However, each department has a focused responsibility that they are on the hook to deliver. It’s not all on the PM.
There are many reasons why I think the UX Designed model is superior, but I don’t think it matters. Nature (and human psychology) usually dictate that things that are not normal should be eradicated, regardless of merit. Changing the “norms” are incredibly hard to do. I imagine it like this:
The Norm has gravity. Left to “normal people”, there would be no abnormal behavior, the abnormal would feel pressure/gravity to come back into the norm. Our species usually adheres to the herd mentality.
“Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves.
All progress, therefore, depends on unreasonable people.”
– George Bernard Shaw
So the question is: How do we sustain this abnormal behavior? How do we maintain ownership of the design details rather than devolve into the norm where PM is “owning” and dictating a huge portion of the decisions that go into a product.
The key is to use persuasion. As I have stated in the past, Design is Decisions. So whoever makes the decisions IS the designer. The goal is to persuade your co-workers, on a continual basis, to support and execute delightful products. Persuasion’s importance can be summarized by this short clip from the Last King of Scotland.
Idi Amin: I want you to tell me what to do!
The Last King of Scotland
Garrigan: You want ME to tell YOU what to do?
Amin: Yes, you are my advisor. You are the only one I can trust in here. You should have told me not to throw the Asians out, in the first place!
Garrigan: I DID!
Amin: But you did not persuade me, Nicholas. You did not persuade me!
It’s not enough to be right.
I interview designers all the time who KNEW they were right, but the company went in other directions. It saddens me greatly to hear the stories, but great design is regularly thrown in the trash because the designer did not know how to persuade the organization properly. In fact, many designers have given up trying.
Here are some techniques to help you with various stakeholders. These are keys to software design persuasion.
Pair design (1:1)
I often get a stakeholder to sit with me at my computer and design together. When they have an idea, I go with it for a little while and then show them visually where the design hits limits or problems. I save those as “versions”. I tell them that we are supposed to come up with multiple options. In this mode, they often can see how hard it is to design and how their ideas have flaws. They also feel included and respected.
When they have a good idea, I immediately adopt it and put it into the design. This gets their fingerprints firmly installed in the design. When it comes times to support it, I can count on that person’s help because they are supporting their own decisions.
The fundamental rule there is: The best ideas win. (Especially if it’s THEIR idea!)
Have others make decisions no matter what
If you can’t find something in someone’s ideas worth adopting ask them to make a decision that can go either way. Let’s say you could use an accordion or tabs in some situation, either would be acceptable. Ask THEM what they would do. The more you spread out those decisions, the better.
You need to decide what matters to you as a designer and what isn’t as important. Your chart should look like this:
Everything can’t be YOUR way. You need to focus on what will make or break the experience. It’s not about being perfect, it’s about getting the fundamentals right. Get the CORE right. If you have too much in your slice of the pie, you won’t have enough fingerprints on it to succeed.
This is not meant to be design-by-committee. You don’t vote as a group. You work with people 1:1 to invest them in the process. Engineers, Product Managers and Executives will trust you more if they walk with you down the road.
Break bread
Nothing builds rapport more than having food with people. Build up a rapport. Ask them about their jobs. Listen. Understand. Sympathize and empathize with their issues. Don’t complain about the design process during these meals. Be friendly and professional, but most of all be a good listener.
Use high fidelity storyboards
I feel strongly about this one. I believe that showing low fidelity mockups lends themselves to design churn. It looks so easy to produce that people think it must not be that good. I use PowerPoint and make it look nearly identical to the real application. When people see it, they are evaluating it as it would really be. They don’t need to squint their eyes and imagine what it would be like. They can see how the interactions would work. They can empathize easier.
Additionally, storyboards allow you to tell a story, rather than let the audience go wherever they want. A story is something memorable. It is essential to use a mouse pointer in your storyboard and animate each click-transition. You MUST show the transitions so people can follow the story. My team uses PowerPoint to animate and design the interaction storyboards.
Use real data!
Never put “Sample” or “Lorem Ipsum”. It makes it impossible for people to understand the design when it doesn’t have plausible data. Use a realistic use case. You will find people accept your conclusions much easier when they see the data in your pie chart adds up to the right number. I can not emphasize this effect enough. Dummy data yields bad design and poor acceptance by the engineers, executives and product managers.
Listen and mirror
Often executives want to make sure you heard THEIR point of view before they can hear YOUR point of view. Listen, make sure you understand what they are prioritizing. Often it is one detail they must have or they will push back. Mirror back their ideas, without committing to them. I often start sentences with, “Let me mirror that back to you to make sure I understand what you are saying. I am hearing you say…”
If you aren’t listening then you won’t get their good ideas and won’t get their pet peeves. Those are golden. Often the pet interactions are the ones that are most important and get the best buy-in.
Keep it productive, but hold your ground
Don’t get in yelling fights, it’s all about the work. It’s not personal. Keep designing. Keep owning. Never give up. Work harder than everyone else and people will respect that. How can someone give you authority if they don’t respect your work ethic?
Institutionalize the process
I wonder if the process would devolve into the norm if I weren’t here. I think it might, but my plan to keep us in orbit is to create more leaders on my team who think the way that I do. People like Atanasio (shout out!) are quickly becoming leaders who can keep us away from the norm. If I can make a whole team of people like that, then the process is institutionalized and can withstand the changing of staff over time.
Avoid formal testing
Testing is a sacred cow, but it isn’t a good idea. Done well, formal testing can be informative and helpful. Done medium or poorly it can destroy a product. Most importantly for our purposes here, it reduces the trust placed in design to know what they are doing. The norm is to expect the design team doesn’t know what they are doing and only testing should be trusted. If you want to stay in orbit, avoid this pitfall.
The head of the QA department often says, “You can’t test quality into a product. Engineers must build quality into a product”. I feel the same way about design. You can verify with it, but you can’t test inspired design into a product.
Summary
If you can not persuade people that you deserve authority and responsibility in design, then you are going to be pretty unhappy as a designer. It isn’t just about talent. We don’t live in a world where we are given responsibility. We must earn it and continuously maintain it. There are more techniques, I’m sure, but these should help get you started.
Whatya think?