The Art of the UX Steal

I’ve been building interfaces for a very long time, and I can tell you that the number of times I’ve had to solve a completely new and unusual user problem is remarkably small. This isn’t surprising. The vast majority of products we build incorporate a lot of familiar elements.

For example, think about the number of products you use that include one or more of the following: login, purchasing, comments, rating systems, order history, inventory management, or user generated content.

Do you expect that every single login experience gets redesigned completely from scratch in a vacuum? Of course not! It would be annoying if they were, since each new version would almost certainly differ just enough to make things confusing. Having design standards for things like logging in makes a lot of sense for both users and designers.

However, this tendency to fall back on patterns, or just to copy whatever Apple/Amazon/Facebook is doing, can cause some problems, especially for startups. There are a few big reasons why you shouldn’t just adopt another company’s solution without serious consideration.

They May Not Want Exactly What You Want

Companies have hidden agendas. But their agenda is not always your agenda, which means that their optimal design is not your optimal design. And if you think that they’re always optimizing for the best user experience, you’ve lost your damn mind.

Want an example? Ok! Have you ever purchased an item and been opted in to receiving email deals from the company’s partner sites? As a user, who likes that? Who thinks that’s a great user experience? Exactly.

Then why do companies do it? They do it because they have made the business (not UX) decision that they make more money by opting people into partner deals than they lose by slightly annoying their customers. That’s a totally reasonable calculation for them to do.

Now, let’s say your biz dev person comes to you and says he wants to add that feature to your checkout process because he has a partner lined up who is willing to pay for the privilege of getting your users’ email addresses. He says it will be ok to add the feature because other big companies are doing it, so it must make money.

But you have no idea how much money they’re getting for making their UX worse. You have no idea of the number of users they may be losing with this practice. And even if you did know their numbers, you can’t decide whether this feature is the right business decision for you until you know what those numbers are going to be for your product.

In an ideal world we could always just choose whatever made the best possible user experience, but realistically, we make these kinds of business/UX tradeoffs all the time. They’re inevitable. Just make sure that you’re making them based on realistic estimates for your product and not on the theory that it’s right because a bigger company is doing it.

They Don’t Do Exactly What You Do

By my count, Amazon has sold at least one of pretty much everything in the world. Ok, I’m just extrapolating from my purchase habits, but you know what I mean.

Not only do they sell products directly, they also allow other companies and individuals to sell through their marketplace. They also sell a lot of different versions of the same product. This makes their product pages pretty complicated.

Does your product do all of those things? If you work for a startup, I certainly hope not, since many of Amazon’s features were added over the course of more than a decade.

If your product doesn’t have all those features, then you might want to do all sorts of things differently than Amazon does. For example, your product pages could be significantly simpler, right? They could emphasize entirely different things or have clearer Calls to Action or more social proof because they don’t need to account for all of Amazon’s different features.

Whether or not you even have product pages, the point is that no other company is doing exactly what you’re doing (or if they are, you have an entirely different problem), so their optimal UX is, by necessity, going to be different from yours.

They Can Get Away with It

If Dante were writing today, the 9th circle of Hell would have involved trying to sign into multiple Google accounts at once. True story.

A friend of mine decided to make me angry the other day, so he showed me a Google docs screen where the Save button was so cleverly hidden it took him several minutes to locate it. This was on a screen that had maybe four elements, and he’s a very senior software engineer, so this probably wasn’t user error. I find the usability on certain Google products almost sadistically poor.

But I put up with it because Google provides me with incredible value for free that I can’t get anywhere else even by paying for it.

I don’t use things like Google docs for their UX. In fact, I use them in spite of large portions of their UX. And if your UX borrows from Google through some misguided notion that just because Google does it, it must be right, I will quit your product in a freaking heartbeat and bad mouth it to all my friends.

The moral of this story isn’t just “don’t steal UX from Google,” although that’s not bad advice. The moral is that very few companies succeed in spite of their UX, and if you happen to steal UX from them, you’re doing it wrong.

On a side note, you know what had a fabulous UX? The original Google product - the one where there was just a single search box, two buttons, and a hugely successful algorithm for finding great results. Unsurprisingly, that’s the UX that got us all hooked in the first place.

The Right Way to Steal

Now that the horror stories are out of the way, you still shouldn’t be coming up with every design element from scratch.

Not only is it ok to steal a basic login process from another product (although not Google), it’s almost certainly the best possible thing you could do. Having a non-standard way for users to log in to your product is just needlessly confusing.

One product I use on a regular basis used to put their Log In button on the top left of their home page instead of the top right. Just this little change meant that several times I had a hard time remembering how to get into the product, and wasted several seconds searching for the button. I probably wasn’t the only one to complain, since they fixed it relatively quickly.

Logging in isn’t the only thing to standardize. Any time you have a simple activity that users do regularly in lots of other products, you should at least check to see whether there is a standard and consider adopting it.

Of course, you can always choose not to do things the way everybody else is doing them, but you should have a very strong reason for changing things, and you should definitely a/b test your change against the standard design pattern.

Trust But Verify

Most importantly, when you are planning on stealing - or “adopting a standard” as we’re now going to euphemistically call it - it’s still important to test it.

I like to do quick qualitative tests to observe some people actually using the standard. In fact, often I’ll test the standard on competitors’ products before implementing it, rather than implementing it and then finding out that it’s crap. Then, I’ll test again once it’s implemented in my product.

In general, the more companies who are doing things identically the less likely it is to be confusing. But it’s still necessary to make sure that the design works in the context of the rest of your product.

Like the post? Follow me on Twitter!

Idiots, Drama Queens, and Scammers - Improving the Customer Service with UX

I recently published another article in Smashing Magazine. This one is titled Idiots, Drama Queens, and Scammers - Improving the Customer Experience with UX.

Here's an excerpt:
User experience design isn’t just about building wireframes and Photoshop mock-ups. It extends to areas that you wouldn’t necessarily think are part of the discipline.

For example, your customer service department can have a huge impact on your website’s overall user experience. Similarly, the design of your user experience could have an awfully big effect on your customer service department. Of course, not all of your users will interact with the customer service department, but for those who do, their experience can improve or destroy the customer relationship.

Read more now >

How Metrics Can Make You a Better Designer

I have another new article in Smashing Magazine's UX section: How Metrics Can Make You a Better Designer.

Here's a little sample:

Metrics can be a touchy subject in design. When I say things like, “Designers should embrace A/B testing” or “Metrics can improve design,” I often hear concerns.

Many designers tell me they feel that metrics displace creativity or create a paint-by-numbers scenario. They don’t want their training and intuition to be overruled by what a chart says a link color should be.

These are valid concerns, if your company thinks it can replace design with metrics. But if you use them correctly, metrics can vastly improve design and make you an even better designer.

Read the rest here >

Need Help with Your Design and Research?

I used to do a lot of design and research for companies. Don't get me wrong. I still do design and research, but I’ve recently made a pretty significant change.

I no longer do design and research FOR companies. I now do design and research WITH companies.

I promise this isn’t just semantic nonsense. It has a huge impact on my relationship with clients, and I think it has some good lessons for people who choose to work with outside UX help.

Give a Company a Fish

Let’s take a look at the typical experience you have when you hire a contractor or an agency. Typically, you give a lot of input to the contractor about what results you want, and the contractor goes off and produces something that hopefully fits those results. 

With a good contractor, you get a lot of discussion and iteration, but at the end, you get a design or a research report that somebody did for you. And that’s all you get.

If you want to change part of the design after the contractor is gone, you run the risk of making major mistakes, because you are very unlikely to understand all the decisions that were made in creating it. If you have a question about the research or want to do a quick follow up about something you learned, you don’t know how to do that yourself.

This means that the next time you want some research or design done, you need to hire somebody to do it for you again. This is great for the contractor, and it’s not bad for companies with big budgets, but it can be especially hard for startups.

Going Fishing Together

Last year, I decided to try a different model. When I was hired by clients, I came in and worked as part of the team. I was still doing the majority of the design and research, but I came in and worked at the office and tried to be integrated into the teams as much as possible.

That worked better than the old agency style I was used to. I had more contact with the engineers and product owners. We could iterate on the design faster because we were all in the same room. I learned far more about the product and users. Sometimes they learned a little about the design process.

Still, with some clients, I found that I was the only person in the room while doing customer research. I was the only one coming up with questions I wanted answered. I was still having to schedule design reviews rather than having everybody involved in the design process.

The worst part was that I was the only one learning anything about the customers. But they weren't MY customers!

Too often, what this meant was, when a project was over, everything at the company went right back to where it was before.

I started to look at why some projects ended this way, while in others, the companies seemed to incorporate good design and research skills into their own development process.

Teach a Company to Fish

Based on what I learned from the companies who improved, I have a different model now for all of my new clients. I’m helping companies learn to do more design and research on their own.

Instead of running a research study, I help product owners figure out what sort of research they need to do. I then help them plan it, execute it, analyze the data, and create actionable designs. If this were a sports team, I’d be a coach, not a ringer.

Of course, this does mean a lot more work for my clients. They have to figure out what questions they want answered. They have to talk to their customers. They have to do design work. They have to understand the process. It’s really hard, and not everybody wants to learn to do these things.

But the beauty of it is, once they’ve done it a few times, it all gets easier. It becomes part of the company process. More people in the company become interested in conducting research and creating designs.

Of course, eventually, my clients won’t need me any longer. It may not be the best business model, but I think it’s the best thing I can do for my clients.

What This Could Mean for You

This means that I can help you learn how to be better at research and design. For example, I can work with you on things like:

• Which type of research is right for you at any given stage of your product development
• How to plan that research correctly
• How to moderate a user discussion properly
• How to analyze your research results
• How to create usable personas and write good user stories
• How to turn research results into actionable designs
• What changes you need to make to your product based on your results
• When to use metrics and a/b testing in your design process
• What to build now, what to test, and what to iterate on later

If you’re interested in any of those things, you should contact me at laura@usersknow.com. I’m happy to discuss the process in more detail and explain a typical engagement.

Why Your Test Results Don't Add Up and What To Do About It

Check out my guest blog post for KISSmetrics: Why Website Test Results Don’t Always Add Up & What To Do About It!

Here's a little sample:

If you do enough A/B testing, I promise that you will eventually have some variation of this problem:

You run a test. You see a 10% increase in conversion. You run a different, unrelated test. You see a 20% increase in conversion. You roll both winning branches out to 100% of your customers. You donʼt see a 30% increase in conversion.

Why? In every world Iʼve ever inhabited, 10 plus 20 equals 30, right? Youʼve proven that both changes youʼve made are improvements. Why arenʼt you seeing the expected overall increase in conversions when you roll them both out?

Read the Rest at KISSmetrics.

Breaking the Rules: A UX Case Study

Recently, I was lucky enough to be featured in Smashing Magazine's brand new UX section! Smashing is already a fabulous resource for web design and coding, and I think it's going to be a great place to learn about user experience.

You should read my first article, Breaking the Rules: A UX Case Study.

Here's a little something to get you started:

I read a lot of design articles about best practices for improving the flow of sign-up forms. Most of these articles offer great advice, such as minimizing the number of steps, asking for as little information up front as possible, and providing clear feedback on the status of the user’s data.

If you’re creating a sign-up form, you could do worse than to follow all of these guidelines. On the other hand, you could do a lot better.

Design guidelines aren’t one size fits all. Sometimes you can improve a process by breaking a few rules. The trick is knowing which rules to break for a particular project.

Read the rest of the article!

Stop Worrying About the Cupholders

Every startup I’ve ever talked to has too few resources. Programmers, money, marketing...you name it, startups don’t have enough of it.

When you don’t have enough resources, prioritization becomes even more important. You don’t have the luxury to execute every single great idea that you have. You need to pick and choose, and the life of your company depends on choosing wisely.

Why is it that so many startups work so hard on the wrong stuff?

By “the wrong stuff” I mean, of course, stuff that doesn’t move a key metric - projects that don’t convert people into new users or increase revenue or drive retention. And it’s especially problematic for new startups, since they are often missing really important features that would drive all those key metrics.

It’s as if they had a car without any brakes, and they’re worried about building the perfect cupholder.

For some reason, when you’re in the middle of choosing features for your product, it can be really hard to distinguish between brakes and cupholders. How do you do it?

You need to start by asking (and answering) two simple questions:

• What problem is this solving?
• How important is this problem in relation to the other problems I have to solve?

To accurately answer these questions, it helps to be able to identify some things that frequently get worked on that just don’t have that big of a return. So, what does a cupholder project look like? It often looks like:

Visual Design

Visual design can be incredibly important, but nine times out of ten, it’s a cupholder. Obviously colors, fonts, and layout can affect things like conversion, but it’s typically an optimization of conversion rather than a conversion driver.

For example, the fact that you allow users to buy things on your website at all has a much bigger impact on revenue than the color of the buy button. Maybe that’s an extreme example, but I’ve seen too many companies spending time quibbling over the visual design of incredibly important features, which just ends up delaying the release of these features.

Go ahead. Make your site pretty. Some of that visual improvement may even contribute to key metrics. But every time you put off releasing a feature in order to make sure that you’ve got exactly the right gradient, ask yourself, “Am I redesigning a cupholder here, or am I turbocharging the engine?”