Reflections on "Intuitive"
People sometimes criticize a piece of software as being "unintuitive". In fact, its one of the most common complaints you'll hear whenever anyone starts using a new piece of software. Its often entirely justified too - its rare that a complex application manages to be obvious to every new user, or even most new users. Some software developers have a good track record here, Apple in particular, whose rules and guidelines for how to design user interfaces keeps on manage to churn out remarkably intuitive software. Well, it does as long the application is fairly simple and its scope is well defined. By the time you get to applications such as Final Cut Pro or Logic Pro, it would be hard to find anyone who found them "intuitive" in the same way that, say, iTunes or even Garageband is.
The fact that users want "intuitive" software puts some software developers in a difficult position. If their software is intended to perform many of the same goals as an existing software tool, then they can end up being faced with two possible ways to go about things:
- slavishly copy the precise workings of the existing tool(s), and see their work labelled as a copy-cat, derivative and "catch up" application
- do things differently (to some degree) compared to the existing tools, and see their work labelled unintuitive, hard to use, "unnecessarily different"
Neither of these are desirable outcomes for most software developers, but its hard to see how they can avoid either of these outcomes if they are working on software that is aimed at tasks already addressed by several successful tools. As a result, it becomes necessary to develop a rather thick skin when people make these kinds of observations. Most people who think that a particular human tool (software or otherwise) is intuitive often fail to realize just how many hours/days/week/months they have put into getting to their current understanding of the existing tool(s).
Of course, its also necessary to be open to the idea that whatever ways your application differs from "established design" might actually be wrong or inefficient. Unfortunately for us software developers, its much harder to convince users that their existing ideas of what is "intuitive" or "easy" or "efficient" might actually be sub-optimal. This is one of the reasons that a healthy open-source-centric user community is such a great asset during software development - the give and take between the developers and users in this model tends to be filled with far less exaltation and timidity on both sides and instead is often characterized by healthy skepticism on both sides that the other really knows what they are talking about. Its really great to be able to chat with Ardour users in real time on IRC, and often have both myself and the user(s) arrive at new levels of understanding of the task, possible designs and workflows and the pitfalls of each of them.
Of course, its not that proprietary software doesn't involve a certain amount of this kind of feedback, and in some cases (mostly very large companies) there is is really wonderful use of end-user testing that leads to deep insights that would not be obtained by just talking to the user. But the awareness that only the annointed developers can ever change the behaviour of the source code changes the balance of the dynamic between developers and users - here in open source world, even as "lead" developer of Ardour, I am constantly aware that anyone may come up with a patch that others see as a great improvement over the work that I did, even if I do not. This benefits users - for obvious reasons - and it benefits me (and other core developers) by keeping us honest about our power to control the design of the software. It also enforces a certain humility - the next great way to improve Ardour's operation may not come from any existing developer at all, but someone we've never heard from before.