Intuition And Complexity

I just ran into a situation where I had to describe an easy, but not intuitive process to a coworker. The net result of the conversation is that I realized I would much rather have software or process that it intuitive yet difficult, rather than simple yet not intuitive.

If a process is intuitive yet difficult, the user will be able to find there way through the process with minimal (if any) any external guidance. The user will be able to see the on-screen cues that have been built into the software, to facilitate the process, and they will be able to make informed decisions based on the on-screen cues. This holds true even if the process is difficult – for example, filing my taxes every year. This is a tremendously difficult thing to do and it takes a wealth of knowledge to know and understand everything that is happening in the process. However, the online tax filing service that I choose to use had made the process so darn intuitive that I have not required the assistance of a professional accountant or other tax advisor in years. I follow the on-screen cues, I read the instructions that they lay out in front of me, and I make informed decisions because they have made the process intuitive.

But, on the other hand, a process that is easy but not intuitive will often result in mistakes and may cause problems that are difficult to fix. In this case, the process involved a few mouse clicks on our Hudson build server to get the parameters that were supplied to the previous build. As I went through the process of describing how to get the information and how to use it, I realized that the process was simple, but not intuitive. It was simple because the links are clearly available and the information is easy to find and use. It is not intuitive, though, because you really shouldn’t have to go back to previous builds to figure out what you need for the new build. Hudson should be able to pre-populate the parameters for you, or you shouldn’t have to worry about previous builds at all. The end result is that I have to log into several servers, delete several files and remove several database records. All because the process was not intuitive.

The greatest compliment I ever heard a customer pay to a development team (from UX and BA down to coders and DBAs) was that the software was “intuitively obvious”. The customer knew how to use the software without having to be trained, because it modeled the reality of the user’s job and functions. It provided what the user needed, when the user needed it.

So, how do we create a system that is intuitive, regardless of the complexity? Feedback, feedback, feedback! Talk to the end users, if you can. Talk to the product owners and business analysts. Get something in front of them as quickly as possible – even if it’s just a picture of a whiteboard drawing or a sketch on paper. Get feedback early and often, and incorporate that feedback along with the entire knowledge base of the system and the business being modeled, into the software’s process. Pick your favorite development methodology and extend it out beyond developers, into the business and user interaction processes, to include your customers as often as possible. It’s only with this constant feedback that you’ll be able to know whether or not your software is intuitive or not.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Analysis and Design, Craftsmanship, User Experience. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Nolan Egly

    Interesting thoughts.

    One factor you’ve left out is the minimum expected experience of the observer. What I consider complex an airplane pilot probably considers “essential background knowledge”, and I’d hate to be on an airplane with an “intuitive” cockpit usable for “inexperienced” pilots.

    I definitely agree about the short feedback loop. Not only does it help shape the design into something intuitive and usable for the domain experts you’re serving, but it will also jump start your understanding of the domain and help uncover misunderstandings and unspoken assumptions between everyone.

  • And then there’s the situation I landed in when I got my current job a few years ago: the primary application we develop is a data entry and analysis platform for in-house use. The previous system was ugly and bug-prone and not intuitive at all, but everyone working here had the thing memorized. I was hired for the expressed purpose of rewriting the system in a form that would be scalable, maintainable and extensible, which I immediately set about doing. Unfortunately, when I started asking users what they wanted, they kept describing the same system they’d been complaining about for years; they’d become so used to the old system that despite all its shortcomings the only improvements they could come up with were minor usability tweaks. I’ve since discovered that new hires (our organization has a lot of turnover, since most of the data entry staff are students) are a gold mine of useful suggestions, whereas the experienced folks, despite being much better at their jobs, are practically useless for providing any useful feedback on the design or workflow of the application itself. So, I make it a point to keep track of when we hire new entry staff and I pump them for feedback as soon as they’ve made it through training, and I’ve gotten a lot better feedback that way.

  • John Teague

    There are also metrics that can help you wit this. Heat maps, show what is clicked the most often. time spent on a page is a good metric as well. Generally speaking if someone spends too much time a page, they are either confused, or the page is doing too much. Add metric gatherings on rollovers. if you get a lot of rollovers, then the user unsure about where to go. Also check the referring url, if there is a lot of back button action, you know something is up.

  • Good post. Thanks.

    Recently a colleague showed me a feature that he implemented and while the feature was cool, it was not intuitive so we changed it around to be intuitive. In our system we want our system to be intuitive because the system will be rarely used by any particular user, kind of like the tax software where you use it only once a year.

    Where a professional tax preparer may use a simple but non-intuitive software solution, a person preparing their own taxes requires intuitiveness because the heavy upfront training is hardly necessary. So for a professional tax preparer the simplicity may result in faster prep times and the training investment has a considerable ROI.

    So I guess a lot of it depends on what Nolan is saying. How much up front training is acceptable. In the case of a pilot it’s probably a lot, whereas for a person preparing their own taxes proably little or none is the requirement. I can’t imagine the personal tax software company’s being so succesful if their produc wasn’t so intuitive. I also can’t imagine trying to do my taxes with the old paperforms with any of the little bit of complexity in my taxes such as rental property, IRAs, 529s etc.

  • I’d rather have simplicity and clarity – in all things. These things, as well as familiarity, feed intuitiveness.

    That said, settling for intuitive yet difficult often means eschewing the holistic benefits of adopting continuous improvement culture and creating a learning organization.

    I’d rather have a situation where anything that is difficult but valuable can be taught so that the value isn’t traded for the expediency of avoiding the difficulty in teaching and improving.

    There’s an old saying at Toyota: “If the student hasn’t learned, then the teacher hasn’t taught.” Of course, this depends on the presence of a student, but when we do in fact hold a teaching position and we do indeed have a student in front of us, our imperative as teachers is to go beyond our own limitations.

    I understand what you’re saying about the value of interaction surfaces that reveal their intentions at a glance, but this notion of “difficulty” doesn’t reconcile with “intuitive”.

    We are always called to be careful about the trade offs we make when we’re in a position to influence. We don’t have one goal, or the other. Our duty is to do what we can to eliminate all kinds of re-learning – and sometimes that’s served by creating intuitive interactions, and sometimes it’s created by teaching. But it’s rarely served by trading expediency for difficulty, especially when difficulty is a signal for more opportunity for continuous improvement.

  • The whole area of UX and interaction design exists for this purpose. I think it’s something we need to embrace much more from the dev side.