Interface design – Simple vs. Sparse
When starting any new application design project one of the discovery phase tasks I like to complete early on is to get a feel for what visual style my clients are looking for. This may constitute nothing more complex than a five minute discussion about their favourite designs or could be as involved as a half day session evaluating screenshots of designs that they love and hate to help understand why and what elements of one design make it good in their eyes over another.
Going through this exercise I’ve noticed a change in trends of what clients are looking for.
In days gone by I’d get requests like “make it like Amazon / Google / Ebay / insert-poster-boy-application-of-the-day-here“
The most common request I get for now from all clients is: “Make it simple” (often followed by; “like Apple do“).
As someone who spends a lot of his time thinking about the holistic user experience of the applications he designs, I love that they want simple. But I know that making something look simple and making it simple to use are two very different things; many of my clients don’t.
When they say make it simple, they mean make it look simple. They mean make the interface sparse. They argue for one word where three are needed to explain the context of a label. They argue for removing icons or background colours where they are intended to add meaning to elements on a screen. They argue in favour of text being bunched up, smaller and badly spaced so it takes up less room on a screen, so it fits “above the fold”.
They lack an appreciation of the difference between simple and sparse. Between merely looking at or admiring an interface and actually using and interacting with it.
To paraphrase the excellent Mr Steve Krug; “A web application’s interface should be obvious“. It should be self-explanatory. A user should look at every image, every label, every heading, every input or button and know what to do with it, know its relevance to them in their quest for information or task completion. They should not have to think about how it may work.
One word labels like “Filter”, “Save” and “Add” without very careful placement or grouping with the things that they are related to can raise more questions than they answer. “Filter results“, “Save settings” and “Add a user” are more self-explanatory and even when carefully placed next to, or grouped with, their related interface elements still serve to re-enforce their meaning and reassure the user about what they are referring to.
While I once spent my time encouraging my clients to remove the guff and bloat that they insisted on adding to every screen of their applications, I now find myself spending time encouraging them to add just enough back in to make their interfaces understandable and meaningful.