I’ve worked in this field for a very long time, yet explaining how User Experience works to my parents is one of the most frustrating conversations I always have.
They consistently get asked by friends what their sons do. My brother is easy, he owns a bowling pro shop. Me, not so.
Everyone understands what we do
User Experience Designers are still a misunderstood bunch. It’s not a bad thing, but it does create confusion, even in Silicon Valley.
I’ve tried explaining my job to my friends. The conversation goes sort of like this:
“So I design really large websites. Name some sites. I’ve had a hand in at least one of them (my favorite bar bet).”
“Do you do web design?”
“Not quite.”
“Do you build them?”
“No.”
“Do you write for them?”
“Sometimes, but from a content strategy standpoint.”
“What do you do then?”
“I craft how they work.”
That ends the conversation, and they want to talk about the latest Vince Vaughn film. I had this conversation once on an airplane — another passenger asked a few questions before we took off. He didn’t respond until we landed three hours later, saying, “Wow, that sounds cool.”
Now I flash my Pick An Excuse application, and they get all giddy because I have an iPhone application.
It’s really not that hard. The analogy I use is that I’m like an architect for houses. I design the structure of the house, the three rooms, and where the kitchen is so that it’s livable. Someone builds the structure (programmers), wires the house for water and power (database architects), paints the walls (visual designers), and determines the value of the house and how to sell it (those pesky product people that think they are UX designers ;) ).
Everyone has a say on how the house is built (Can we move the hallway over there? I don’t like that color of red.); but at the end of the day, if the people occupying the house don’t like how the house works, they move. Period.
Or as my friends say, I get paid for doing nothing and having no say.
It’s awesome.
We are Visual Designers or HTML Programmers
Interaction designers come from a variety of backgrounds, it is a jack of all trades position. You have to understand programming, design, business needs, user needs, and have communication skills.
Sure, I have a visual design background. I used to be a print designer back in the day and still have those skills in my backpocket for some work. However, it’s something I don’t advertise. I don’t advertise a lot of things, like my knowledge of HTML and CSS. I see a lot of jobs that ask for the unicorn (Interaction + Visual + Front End Development). These are three separate skill sets.
In conversations with with many UX professionals, I’ve heard they come from a variety of fields like sales (one used to be a car salesman) or programming. A lot of them were writers, because communication is key to this position. We are in this field because we’re good at interaction design or user experience design, not because we can code. We might be able to put together a quick prototype but most likely not a full website.
Interaction designers come from a variety of backgrounds because it is a jack of all trades position. You have to understand programming, design, business needs, user needs, and have communication skills.
That’s about three more skills than most people have.
We have all the answers
We draw on our previous experience on what’s worked at other companies or on other projects. We do user research and competitive analysis on other products. We make gut decisions based on the style of User Experience we have practiced for years.
During a meeting, I made a wisecrack that “User Experience Designers can’t tell you how it should work, but they can tell you what’s currently broken and why.”
It’s really true. We don’t have all the answers, but we do know where to find them.
We draw on our previous experience on what’s worked at other companies or on other projects. We do user research and competitive analysis on other products. We make gut decisions based on the style of User Experience we have practiced for years.
Every audience has a slightly different take on how an application or website should work, and that’s something you can’t really plan for. For example, the needs my mother has for a email client are much different than someone like me (or maybe not). The statement, “We did this at the last place I worked at” is a good starting point but shouldn’t be the final product.
When I design an application, and I have to take that into consideration. I do user testing to validate my assumptions, and if I’m wrong, I change the design.
We have (or even want) final say over a product
There’s a famous post over Oatmeal about how a website design goes straight to hell. It’s indicative of how the process can go.
When I design a feature, I usually start by looking around the web for other examples and interviewing users. The interviews can take place over the phone, or even better, at a bar (specifically Tony Nik’s in San Francisco). I get feedback and design wireframes.
Here’s where the real fun starts:
- Product Managers will chime in, pointing out user stories that I missed.
- The front end developer mocks it up, miss three hover-overs, and make a comment that one of the design patterns was incorrect.
- The development team will point out the feature is impossible to build or will bring the servers down to their knees.
- The visual designer uses a color that violates Section 508 standards or moves a button to a different part of the page I know isn’t going to test well.
- User testing performed on the mockups or the final prototypes finds an issue that is a showstopper.
Why do they get a say? They’re users, sometimes right in the core audience. They have received different feedback. Or maybe they just want a say, which is valid. Or sometimes, it’s just bullshit, as Joel Spolsky says.
We take all of that feedback, and make changes. We aren’t so much of a gatekeeper, but rather a collector of information to construct the final approach. In a house. sometimes a wall has to be moved, a color changed, a faucet is too expensive, etc.
Based on all of this, it shows how little of the product we control. Yet some of the results (the $300 million button, for example) shows the immense value User Experience Designers can add to the process.
That’s why they have a voice, but not the final one. It’s really the user’s product, especially if they are footing the bill.
We want all the control
Patterns make my life easy, because I don’t have to reinvent the wheel. I try to use what works within the context of a client.
Follow my thinking.
Most of the design I start with is based on design patterns I follow on the web, and look for other best practices. I watch a lot of the large websites (Amazon, eBay, Google), figuring they have much more money than most of my clients to spend on User Research.
I use patterns that have tested well at other clients, and I try to deliver solutions efficiently because: a) not working efficiently costs clients money and time and b) working past six cuts into the time I can spend on a barstool. And there’s nothing that stands in the way of my Macallan at Tony Niks.
Patterns make my life easy, because I don’t have to reinvent the wheel. There’s one specific design pattern (web forms) that I’ve used for 10 years, because it’s never, ever, ever failed me.
Always, I try to use what works within the context of a client. I also complain occasionally, but have learned to pick my battles better. Well, on good days.
Many outside of the process try to exercise a lot of control over the design, determining where every checkbox and every hyperlink goes. They ask about color schemes (totally outside of my realm) and navigation patterns in terms they don’t quite understand.
Yet, the more this happens and they fight over the wrong things, the more I want to dig my heels in. The more they follow my lead or approach that I want to have a collaboration. Most User Experience Designers give the middle bird to authority, because that’s what make them what they are: professionals who ask “why” at the right time.
Joel Spolsky has a great post about Program Managers and working with developers:
Of course, when programmers are peers of the program managers, the programmers tend to have the upper hand. Here’s something that has happened several times; a programmer asks me to intervene in some debate he is having with a program manager:
“Who is going to write the code?” I ask.
“I am…”
“OK, who checks things into source control?”
“Me, I guess, …”
“So what’s the problem, exactly?” I ask. “You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?”
Where I work best is coming up with high level patterns and working with developers that want to polish and shine every single detail. I can’t think of everything (especially when I’m out-numbered by developers five or seven to one), so I need people dedicated to great User Experience. Software development is a collaboration, not a dictatorship.
Data drives every decision
Users notice inconsistent design and will point that out. They notice that tabs are in different positions and that searches don’t work the same. Sometimes, they’ll point out features that are missing because they can’t find them. Most of the time, they’ll mention it works like crap.
It goes back to what a friend of mine said to me while I was a print designer.
He said if someone notices a design, it’s over-designed.
I’m all for assigning return on investment for every single feature, but sometimes the value of user experience is more holistic than that. That’s why it’s called User Experience and not Widget Design. It’s about the experience of the product which contributes to the overall value.
Sometimes it’s the parts of a whole.
Apple has the same value with designing their products. Their AirBooks are phenomenal pieces of equipment, yet there’s not a single feature you can point that makes you want to buy it. There are tons of tablets that have the same featureset as the iPad, yet Tech Crunch said it has no competition. Filemaker Pro is a great product, but there isn’t a single feature that other databases don’t have.
You can’t replicate all of this by analyzing data, but you can optimize as much with what you have, using data to get there. Do the basics first, then worry about changing the world.
There’s an interesting post by Douglas Bowman about design at Google, specifically the 41 shades of blue. There are also other opinions that sometimes you have to take a leap of faith and create something totally new. Truly great teams realize the answer might be in the tea leaves that you have to try something different.
I firmly believe this dedication to data-driven design at Google has been the reason they don’t get people. People aren’t numbers, and you have to understrand their core needs outside of a return on investment analysis.
Comments |
Comment
