A recent article by Steven Sinofsky on “Learning by Shipping” (which I think means something like “permanent beta” which is a rant for another time) makes a great point about user interface design. He uses some cludgy terms and doesn’t delve particularly deep, so I will try to translate and expand if I may.
A design can be minimal but still have a great deal of friction. The Linux command line interface is a great example of minimal design with high friction. You can do everything through a single prompt, as long as you know what to type and when. The minimalism is wonderful, but the ability to get going comes with high friction. The Unix philosophy of small cooperating tools is wonderfully minimal (every tool does a small number of things and does them well), but the learning and skills required are high friction.
His main point, which I strongly agree with and which is supported by research, is that task complexity is a much bigger problem for users and usability than visual complexity. If the task is simple, having a dense and asymmetric visual design is not a problem. But a minimalistic visual design is not usable at all if the task is complex. Steve refers to this as ‘friction’ but I think complexity works just fine. The sad thing is that so many design teams seem to be jumping on the minimalist design bandwagon without thinking about the negative effects on the task.
He also mentions an additional challenge, which is a great catch. Early adopters are different. They are often willing to fight through a complex task to find cool functionality. We have to be careful when recruiting participants for studies. Early adopters are often the first to volunteer and are the only “experienced” users early after launch. Especially in the permanent beta model. But then the mass market rejects the product as too hard to use.
Then we get to the most useful part of the article, the recommendations. Again, I will try to expand on them a bit:
- He recommends defaults. This may seem obvious, but I would suggest that a well-selected default can make a design much easier to learn, especially given how many users leave the defaults in place for a long time. It is not hard to move settings and preferences to a drill down area.
- He recommends having one path for each task. Not mass redundancy to make sure users can find functions no matter where they look. And not piggybacking multiple tasks onto the same path.
- He recommends personalization rather than customization. I use these terms differently, but what he is suggesting is that we stop relying on analytics to guess what the user wants and then making changes automatically based on those. Only if you are correct 100% of the time is this going to be well received. If users want to make changes to settings and preferences, let them do it themselves.
- Then there is one recommendation where he introduces a term that I am going to adopt. The “futzer.” He differentiates a function, which allows users to achieve something useful, from a “futzer,” which allows them to play around with content, waste time. And maybe have a short term burst of positive experience but in the longer term . . . .
- Then finally, he recommends having a system. A design pattern library. Some way of being consistent when it comes to tasks, not just visual design. This can help avoid the bloatware that adds complexity and yet that we see appear on a regular basis.
So what do you think prioritizing task complexity over visual complexity? Are you already doing that?
And for my personal benefit – do you like the idea of the “futzer”?
Image credit: wham! Bam!