Error: Twitter did not respond. Please wait a few minutes and refresh this page.
Exploring the information space
I have been told, over and over, to keep the systems I design simple. The mantra is familiar; we all know it well: KISS – keep it simple, stupid.
Everyone and his half-brother is quoted saying something of the sort:
“That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
Now, I have a big problem with how many people choose to interpret this concept of simplicity. There are several ways in which KISS can be applied.
This is the aspect of KISS that people like Jobs have referred to: it is about reducing the set of requirements; eliminating second-tier functionality.
KISSing the system is about identifying the tasks that really need to be supported, and eliminating the rest. If you can halve the number of tasks the system supports, thereby halving the overall complexity, while maintaining 90% of the user-task needs (i.e. the retained tasks are used more than the discarded), your return on effort will increase.
Of course, just because a task is not frequently performed does not mean it is not critical (e.g. a purchasing process involves putting items in a cart, and a check-out; just because the average shopper selects five items before checking out does not mean we can do without the less-used step).
There are actually two parts to this:
Picking on the interface as something to KISS is easy for management: interfaces are the most immediately visible representations of the complexity of a system. One button is more intuitive – at least at the first step – than 15 buttons; clearly, you know what to press to get started.
But, and here is where the simplification breaks down, if there is only one button that needs to accomplish everything the 15 could, then there is complexity in using the interface.
While a system that has been pared down to basic tasks will generally have a less cluttered, sleeker interface, the clean interface is not – of itself – an indication of less complexity. It may well be a sign of reduced usability.
The other place where some people try waving KISS around as a guiding light is the design of the mechanisms underlying the interface. If, they surmise, the supporting mechanism is simple, it will be easier and cheaper to develop.
Here, though, is the catch: while KISSing the system simplifies the black box, KISSing the interface does not have the same effect on the inner workings. Your one button interface needs to accomplish something: it triggers a cascade of consequence, the change in the button’s state from off to on results in more than one bit being changed in some data system. The signal is processed, and acted upon. Your interface allows you but to drop a snowflake; an avalanche results.
If we were to limit the inner workings as we do the interface, then the cascade of consequences would need to be manually managed by the user, through this one-button dumbed-down interface we have given them.
There is a simplified equation that shows us the distribution of complexity within a system:
Cs = Cx × Ci × Cg
The thing that needs to be understood about this equation is that value Cs is the initially supplied unit. The system needs to accomplish certain things, and so will have an inherent level of complexity as a result. Which of the three parts of the system it is presented in is a development choice.
If you want to make the interface (Ci) and the usability (Cg) extremely simple, then the inner black box workings (Cx) will need to be significantly more complex to compensate. And keep in mind that these are products, not sums: to half the complexity of the interface, the inner workings must be twice as complex.
An example of how simplifying an interface will make the inner workings required more complex is an address input form. The task is to take an address from a user’s knowledge and get it into a database, in appropriate fields (street, town, post code, country).
The low-Cx approach is to display a form with one input field per database field. But from a user’s perspective, this can be complicated. How is the address to be split across the fields? What if my country does not have post codes? Or if I need more fields than the interface provides? Ci is not overly high, but it is still messy, with half a dozen fields, and Cg may rise significantly for certain users.
We could make both Ci and Cg very low, by providing a single input field, and moving the determination of which line (or part thereof) goes to which data field into the black box. It’s really easy for the user, but a lot of work, with hundreds of edge cases, for the developer.
KISS is a very powerful acronym. It is simple. It lives up to its own instructions. And, so long as it is not taken to extremes, it makes perfect sense when talking about the overall system.
Trying to apply KISS to the interface, or the black box, however, is another story entirely. There is always a trade-off. If one aspect is simplified, another is made more complex. And simplification of an interface or the mechanisms supporting it will result in a less obvious user experience.
KISS is an approach that should be applied to the overall system, but tempered by real business cases. Once the system’s scope is set, any further KISSing comes at a price.
Comments are closed.