Intent to Solve

I wrote an article about finding out whether prospective customers will buy your product over at Boxes and Arrows. You should read it!

"When we’re building products for people, designers often do something called “needs finding” which translates roughly into “looking for problems in users’ lives that we can solve.” But there’s a problem with this. It’s a widely held belief that, if a company can find a problem that is bad enough, people will buy a product that solves it.

That’s often true. But sometimes it isn’t. And when it isn’t true, that’s when really well designed, well intentioned products can fail to find a market."

Read More > 

Building the Right Thing vs Building the Thing Right

This originally appeared as a guest post on the O'Reilly Programming Blog.

I love it when companies test prototypes. Love love love it. But it makes me incredibly sad when they use prototype testing for the wrong thing.

First, let me give you my definition of “prototype testing” here. I often build interactive, or semi-interactive, prototypes when designing a product. These prototypes are not actual products. They’re simulations of products. People who see the prototype can often click around them and perform some simple tasks, but they’re generally not hooked up to a real back end system.

“Well, what good is that?” you might reasonably ask. Excellent question. Interactive prototypes are incredibly useful for finding problems in usability testing settings. In a checkout flow, you might create a simple interactive prototype and watch four or five people go through the process (with test accounts) in order to find out if there were any parts of the flow they found confusing or hard to use.

It’s a great technique for any reasonably complicated interaction that you want to test before you spend a lot of time writing code. Interactive prototype testing can save you a ton of time because it helps you make sure that you’re building the product right before you spend a lot of time and money actually writing code.

Read the rest of this post on the O'Reilly blog >

Don't Allow Behaviors. Encourage Them!

I wrote this post for the O'Reilly Programming Blog. Here's an excerpt:

As a consultant, I’ve talked to a lot of startups who have “social” products. You could tell that the products were “social” because they had comment sections and sharing icons that let people post to Pinterest or Facebook.

Of course, one of the things that the founders complain about is that too few users are actually making comments or sharing or doing anything remotely social with the product.

There’s a very simple reason for this: the founders have added features to their product that allow users to be social rather than encouraging them to be social.

Read More at O'Reilly > 

Mobile First? Not So Fast! The Importance of Flow and Context.

I recently wrote a post for the O'Reilly Programming Blog called "Mobile First? Not So Fast!
Why "flow" and "context" are more important than screen size."

Here's an excerpt:

Are we done with the Mobile First meme, yet? Can we be? Please?

Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.


The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.


Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.


Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.


Those two things are: Flow and Context.


Read the rest at the O'Reilly Programming Blog >

Want more information like this? 


My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. 

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 >

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!