Software cannot be made to be intuitive to every person.
Intuition is but one of three aspects of ease-of-use in software. They are, in no particular order:
- Least surprise
- Time to resolution
Intuition is the measure of how little documentation is needed to accomplish a particular task. One leans on expected behavior of similar software. If your software is not intuitive, users would need to consult the manual often to use your software effectively. They might even need to read a book on it.
Least surprise (also known as the Principle of Least Astonishment) is a measure of how internally consistent your software is. When your users go do a task, how often does something surprising happen?
Time to resolution is the measure of how long it takes a user of your software to complete a given task. For easy-to-use software, it should not take too long to accomplish most tasks.
These three aspects are not entirely independent variables.
Improving the consistency of your application's UI, for instance, will increase all three aspects to varying degrees. Least surprise will be the most impacted, as users will be used to how your software works, which will, in turn, improve the time to resolution.
Intuition and least surprise are also very closely connected, but they are distinct. Intuition is a measure of how consistent your software is with the external world. Least surprise is about internal consistency.
Often people will overestimate the importance of intuition to the detriment of the other two aspects. If your software is used repeatedly, least surprise and time to resolution will be more important. Intuition is merely a nice-to-have in that case1.
Why? Because intuitive behavior to me is likely different than what intuition is to you. We both come from different backgrounds and it will be impossible to offer both me and you an ideally intuitive experience. I could offer a modal editing feature for my WYSIWYG editor, but if you haven't used vi or vim, you won't find it intuitive at all.
As software grows in breadth and depth, it becomes more and more difficult to offer intuitive software. This is because there is yet another aspect of software that relates to ease-of-use: power. Powerful software by its very nature is often not intuitive.
The perfect example of this is git.
Using git, especially at first, is an exercise in how much bewilderment and confusion you can stand. Even tasks that seem as if they should be simple involves commands with strange names and stranger arguments.
So you Google for solutions. Luckily StackOverflow exists, otherwise you'd have to go back to using Subversion.
But the git maintainers aren't concerned with intuition. They want you to take the time to learn it. They want you to read the documentation and Pro Git.
Why? Because the design of git enables truly powerful actions. It lowers the time to resolution of previously difficult tasks to low levels. It enables you to do things that were previously impossible. And it's all due to git's design, which may be unintuitive to you at first.
Once you have taken the time to understand git's design, git becomes consistent2 and doesn't surprise you anymore.
If intuition was the primary goal of git, many of the powerful actions would be neutered. It would likely not have rebase, nor the index. What's intuitive about the reflog?
You use your VCS every single day as a programmer. It's worth some loss of intuition if you get can time to resolution way down.
The intuition trap is the unfortunate situation that occurs when the desire for intuitive software drives out the other aspects of ease-of-use.
Your users have grown accustomed to how intuitive your software is. When something surprising or unintuitive happens, they are blindsided. Your software has little documentation because of how intuitive it is or your users don't need it. Now it's difficult or impossible to inform them of this surprising behavior.
What do you do when your intuitive software has a necessary unintuitive aspect? This is the intuition trap: you lose or frustrate users because of how intuitive your software was.
Notable examples are called gotchas. Everyone can think of a few of these. You might think git is complicated, but when you're merging branches with deleted files, it does the right thing. Subversion doesn't.
Designing your software
So, what aspect of easy-to-use software is most important to your product?
Is your product to be used without a manual, by non-technical users, or only occasionally? Is getting as many users to use your product as possible critical for its success? Then you better make it as intuitive as possible. Talk to your users and find out how to do this and relentlessly iterate. Avoid the trap if you can.
Is your product used by professionals or for complicated tasks? Is it likely that users will read a manual or a book if they need to? Are the switching costs for your software high? Or is your software novel3?
Then making your product internally consistent (least surprise) or powerful (time to resolution) will be most important. Documentation driven development4 is the name of the game, so do it early and get it right. Write blog posts and make videos. Write a book if you need to and release it for free online.
Intuition is merely one aspect of easy-to-use software. As software gets more complicated and more powerful, it will be the first to go. Get used to reading books and documentation. They're here to stay.
Part of the reason for this is that intuition helps users start using your software and doesn't pay dividends after that. I find recurring benefits (like time to resolution and least surprise) more attractive. Although, if your software is so alien that no one uses it, time to resolution won't be very important at all. ↩
Yes, many of the git command names are inconsistent and doing similar tasks requires different commands. The design of git is consistent even if on the surface it seems scattered. Take the time to learn git, really. You probably use it every day. ↩
Have you ever read Tim Berners-Lee's proposal for the World Wide Web? It sounds foreign nowadays. Berners-Lee spends a lot of time talking about categorization, keywords, and other things that seem, now, tangential to the issue at hand. This is because the World Wide Web was, by the fact of its radical nature, was not intuitive. If he was restricted to making his software intuitive, he could never have developed the World Wide Web. ↩
This is the development methodology we follow at Squadron. First, we write the documentation for the feature. Then we make sure it's easy to understand and that it's consistent with the rest of Squadron. Only then do we implement it. Documentation is central to our workflow because we think it's critical to our success. ↩