Who wouldn't want their apps to be described as intuitive? Certainly no customer has ever walked in the door at Lofty and asked us to build something un-intuitive.

It's something everyone asks for, but I have to be honest–they almost never get it right on the first try. That's because the meaning of intuitive software can be... counter-intuitive!

What does "intuitive" mean, in software applications?

It might be more productive to define what it doesn't mean first.

Intuitive software does not mean software that guesses (or intuits) what your users want to do. Most people who strive to build something intuitive start there and many never recover.

Engineers everywhere can tell you stories of the applications they worked on where there were always ten ways to accomplish the same goal with slightly different rules, leaving a trail of bugs in its wake. Every screen's content was variable, based on the type of user or the context of how they had recently used the application. The app is changing itself while you use it to try and guess what you want to do next. Intuitive.

The deep irony here, is that this is our intuitive understanding of what "intuitive software" means. We have to re-train our brains, and the brains of our customers to understand this important truth:

An application is truly intuitive when the user is the one doing all the intuiting.

That's right, we don't actually want the software to be intuitive. We want the process of understanding how to use it to be intuitive.

In order to be successful in building great products, we have to embrace this notion. Our mission is not to build a "smart" application that seems to read the user's mind. Anyone have that coworker that tries to finish your sentences for you but gets it wrong half the time? Yeah, you don't want to hang out with that app.

Instead, our job is to build products that stay out of the user's way and let them get to what they need quickly, easily, and without an instruction manual.

Here are some common examples of common counter-intuitive features and potential ways to invert them.

Magic navigation

Don't do:

When a user logs into the application, it always loads the project they most recently used.

Do this instead:

When a user logs into the application, it always brings them to the same home screen. From there, there is an easy one-click path to any project in the app.

Guessing where the user wants to go will only be correct sometimes. Whenever it's not, the user will be confused or frustrated. By always navigating to one distinct page when someone logs into an app, the user is never surprised. If they are only a click or two away from anywhere they might want to go, they are never frustrated either.

Content guessing

Let's set up this example with a bit of background. You are building an application that allows users to upload two types of information: Solar data and geographic data. Geographic data is always going to be in a format called Shapefiles, while Solar Data might be in Shapefile format, or a proprietary format from a solar hardware vendor.

When a user uploads a shapefile, you can tell about 90% of the time whether its solar or geographic data by looking for some headers in the file.

Don't do:

On a file upload screen, accept any file from a user and attempt to check its format later. If there is an error, send the user a notification that their file didn't work.

Do this instead:

Ask the user if they are submitting Geographic data or Solar data before they upload.

I know you want to bug the user less and have it just be "magic" most of the time, but there's just no substitute for a human being giving you context here. The outcome is that processing logic will be much simpler to construct and therefore less prone to error. At the same time, if something goes wrong the user can get a more direct and specific error message, like "The file you uploaded is not valid solar data," instead of "We could not determine what type of data was uploaded."

Having this user context potentially opens up better experiences. For example, based on what type of data the user selects, your app might be able to do some validation before the file is even uploaded and give the user instant feedback.

Disappearing buttons

Don't do:

The presence of navigation links or action buttons depend on the user's session context, like filters that were applied in another part of the app or data the user needs to enter.

Do this instead:

The contents of navigation elements or action buttons are always the same, but are treated visually in a way that indicates they are disabled or unavailable when needed.

When buttons or links aren't always there the user feels lost. The user's first reaction is not "there used to be a button there, but it's gone now so I must need to do something first."

Instead their reaction is, "I'm in the wrong place. The place I want to be usually has a button here."

By leaving these elements consistent, the user knows they are in the right place and something else is blocking their path. Even better, you have an opportunity to put some help text over that disabled button now that tells the user exactly why it is disabled.

The User already knows how to use intuitive software.

If they don't have a basic understanding of how to use your app by playing around with it for a few minutes, then you've missed the mark. Here are some other red flags:

• Phrases like "this page always does x, except when y"
• You're screen-sharing with customers often to "see what they see" in order to debug a problem
• You're making walkthrough videos as an instruction manual rather than a sales tool.

What do you think? What other things make software intuitive, or what are other red flags? Let us know in the comments!

‍