Six Things User Experience Designers Forget When They Criticize Websites
It’s easy to criticize the user experience of an application or website, because we’re all end users.
But sometimes we use it once, while many have to use it day after day as a part of their job. We talk about how we like using some sites, but there’s always the “I wish it was this way.”
We are our own worst enemies.
We constantly pick at sites and snipe on Twitter how certain missing features are UX 101, but we don’t offer constructive feedback. We don’t understand that some decisions are based on conscious business decisions. Worst of all, we don’t get that company culture, most of all, plays a part in the final product.
Not every company is Apple where design is king. Trade offs are made all the time, sometimes without any input from the user experience stakeholders. All good user experience designers make decisions regarding what they can live with and what they can’t.
What do you forget when you comment?
The User Experience Designer Is the Wrong Fit
All user experience designers aren’t created equal.
For most of my career, I’ve been involved in large projects. One site redesign over 300,000 pieces of content. The current application I work on has hundreds of screens, many with complex interactions.
Because of my past experience, I could tell you a lot about content management, Internet Postage and consumer level escrow transactions.
But please, please don’t ask me to design a microsite.
I tried once. After two weeks, my client and I mutually agreed it wasn’t a fit.
There’s a reason why job descriptions read: “Must have 3 years of mobile experience.” There’s all these nuances and details that come only when you work on projects. If you go from one type of site or application to another, you’re going to make mistakes. And in the end, users suffer.
I’ve made conscious decisions now to tell recruiters up front that I’m not a fit but will refer someone that’s a better candidate. Not everyone does that. Many User Experience and Visual Designers are “out of position,” because they are working at companies or on projects that aren’t in their sweet spot. Other User Experience Designers have to come in behind them to clean up the mess.
Often, this cleanup lasts longer than the initial development because of migrating legacy user experience issues and redesigning the technical implementation with users in mind.
Technical Debt Affects User Experience
There’s a lot of truth in Joel Spolsky’s statement: “All applications suck until version 3.” It takes a lot of time to learn the users, build the features and fix all the crap that you broke in the first place.
All of the startups where I have worked functioned on the “just good enough” philosophy of development. Some places where I worked, tasks that should have been automated were done by hand, because the system didn’t support it.
I worked at one startup where we were up against the wall.
One month before launch, and nowhere near complete.
They had to launch.
On time.
No questions asked.
The development team was in a meeting room late at night trying to figure out all the features that absolutely had to be done. There was a bunch of arguing, a bunch of negotiating, and then someone brought up something completely unthinkable.
“When we launch, we don’t have to bill the customers for at least a month. That would buy us some time,” a developer said.
So they launched the product without billing. Absolutely amazing. Later on, we had to pay the technical debt because the billing system they did write was written by developers that had been working 14 hour days for months. But that was a business decision that at the time seemed worth it.
Why? We shipped on time.
Many startups begin without a user experience designer, and that affects every decision that is made. That forces the incoming user experience expert to be a janitor — something that’s not really seen until the redesign is complete.
Culture Puts User Experience at the Back of the Bus
There’s a famous tale of a web designer that called out American Airlines for how bad their site was. He redesigned their home page, doing a great job creating a very clean design. Easy to do, right?
He got a response from a user experience designer that worked there, a very talented one at that (and one that eventually got fired). The designer listed all the divisions that were stakeholders on the site and explained the interactions that lie outside of user experience but made it in the final product. He mentioned that one group might have control of the pages, user experience designers get overriden by executives and, in the end, the visual designers might have final say, affecting the shipped product.
The group running AA.com consists of at least 200 people spread out amongst many different groups, including, for example, QA, product planning, business analysis, code development, site operations, project planning and user experience. We have a lot of people touching the siteand a lot more with their own vested interests in how the site presents its content and functionality.
I’ve been in many places where user experience is back of the bus to the direct opposite of what they sell. Some places, creative runs the shop. It really just depends.
A culture has to value user experience and product management to let it lead. The best organizations I have seen have been collaborative, but in the end, product and user experience had the final call. If that isn’t the case, then it’s a culture issue.
Resources Are Constrained
I was at a meetup a few months ago, and a few people I met worked at a company that recently IPO’ed. We were talking about the size of teams. In their company, they had 60 visual and interaction designers. Most of the places where I have worked, I was on a team of one. Sometimes, I’ve been lucky enough to have a visual designer.
That’s a pretty big gap.
When you’re working with smaller teams, you make a lot of decisions that you would never make if you had unlimited resources. You know that drag and drop WSYISYG editor you’d like to drop in? Can’t do it, but we can create something on a smaller scale. The site-wide redesign? Don’t have the resources, but we could do it on a rolling basis. Rewrite every email that gets sent out? Sure, but we’ll have to do it over two months.
All of the situations above I’ve gone through. Multiple times.
Not everyone works at really large companies with unlimited resources.
Nor do we work at startups trying to solve very specific business cases. One project I worked on, there wasn’t a product manager for a single screen. The majority of us work at companies were there’s job security for three years, because you’ll be redesigning the application one section at a time.
Because of this, we all make decisions on which battles to fight. Often, it’s the difference between shipping and not shipping a product. Not shipping leaves one year gaps in your resume. You ask yourself the following: Is digging in worth that one year gap? Do you want to own the decision that could negatively affect the profitability of the company?
Do you want to put your job on the line because you want something cooler?
Business Goals Trump User Experience Goals
If I was working at some software services, the last thing I would do is improve the user experience too much.
There are a lot of services companies that sell great software. But what they really sell is services to install, maintain and extend the software. It’s going to be easy enough so sales engineers, most of them making much, much more than user experience designers, can show how customizable it is, but hard enough so anyone without experience can customize it.
Because at the end of the day, the business value of user experience hits the bottom line.
Great user experiences for consumer products not only sell the product, they prevent customer support and save money. The reason Mint.com had to be so easy to use is because customer support representatives cost money, and that’s something you can’t charge for with their business model. What you can charge for is solution architects, because there’s a perceived need.
I worked for a consulting company, and we did a lot of customizations. We played this game all the time, and none of it was about User Experience. It was about the bottom line. We billed by the hour, and the easier the package was, the less we could bill.
Any software consultant can tell you the best thing about open source is the lack of real support.
To really learn what matters for the product, talk to everyone else in the company and ask where they fit in the bottom line. You’ll realize that your wireframes are a very small part of the big picture.
You Aren’t the Target Market
There are a few things I don’t like about 37signals.
I wish it had auto-numbering.
The lack of categories annoys me.
I wish the permissions system was better.
However, say want you want to say, they’re doing something cool over there. They’ve invented the perfect lifestyle company. They have a solid team. They’re making a virtual team work across multiple time zones, using their own products to manage product development. They are contributing to a very profitable SAAS product that has an enthusiastic community behind them. Their process works.
Who am I to criticize?
I’m a power user of project management tools.
I’m always going to ask for more features.
I’m not their target audience.
They have filled a very specific need that serves millions of users well, and they are making money on it. I could make suggestions all day long, but they have a good handle on their target market. They get their users. They understand the personas. They will be king of the hill until someone makes something better.
The same goes for any product. I look at products on which I’ve worked, and I always see features we can improve. But then the users (remember, “user” experience? Not “what you want” experience.) rave about the product, and it’s profitable. Or almost so.
It works for them, and the users are happy even if it’s not perfect.
Who am I to criticize?
The End Game
There’s no such such thing as an ideal situation.
It’s easy for someone like 37signals to talk about how a product can be improved, and it’s another thing to actually do it when you’re not driving the bus. Not all companies have the luxuries a small startup does, with a clean codebase and clear objective.
The real world isn’t some startup where people will run through walls to launch a product, or some college product. The developer you work with wants to work realistic hours, and that means making realistic choices. We all want to see our family and friends; a satisfying work/life balance might mean shipping a feature in the next sprint.
If you have feedback, here’s a better approach: reach out to someone personally and give your feedback.
More often than not, you’ll get an honest response. Taking this approach is a very professional way that, hopefully, can be easily achieved by using LinkedIn or Twitter, and both make it easy to find that person who’s designing the product. I’ve done so several times (I have to dig up that email to Quora), and I’ve enjoy the conversation immensely. Having that conversation publicly through Twitter is something that is bound to come up with people evaluate you for other positions. Social Media is forever.
Doing so privately also doesn’t get the designer fired for talking frankly about the issues they encounter.
It takes a certain amount of maturity and mutual respect for the designer to have that conversation. We are all after the same end goal: great user experiences.
But that’s easy to forget, isn’t it?
