I am an interaction designer who loves minimalism, elegance, flow and agile.

Verbosity does not equal usability: why you can’t solve design flaws with wording

A recurring theme I come across – particularly when dealing with larger organisations – is the tendency for people to try to fix design flaws by throwing more words at the screen.  These have a way of quickly adding up like spitballs, creating screens full of mushy fragments of content that don’t really add up to anything cohesive or useful.  The catch-phrase used at a large bank I recently did some work for was “that’s ok, we’ll just put some wording in there” and it was uttered repeatedly every time we ran usability testing sessions.

Despite being well-intended, it doesn’t work.  In fact, it usually makes the problem worse.  This is because content problems need to be fixed by content and design problems need to be fixed by design.  If people are confused by something there is often a good reason for it.  Is the label poor?  Is the visual hierarchy at odds with the logical hierarchy?  Is the sequence out of step with customer’s mental models?  Is there a disconnect between the action and the entity it acts upon?  Should the action be there at all?  Throwing wording at broken designs just weighs them down more and reduces the relative visibility of everything else on the screen that is actually important.

Repeat after me: verbosity does not equal usability.  ”Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” is the oft-quoted wisdom of Antoine de Saint-Exupery.  Can you spot the content in the following example that might be considered tedious verbosity?

The area of the screen that is visually strongest here is that which conveys the least content.  In fact I would go as far as saying that it actually conveys nothing at all and this screen would be clearer and more usable without it.

Dealing with settings in-flow

Settings (or is that preferences?) in software – like their mechanical counterparts – have long been grouped together and placed out of sight from day-to-day use.  Alternatively they are surfaced to create a control-laden interface weighed-down with options that are almost never needed.  Revealing options contextually can be an elegant third way to solve this problem but the execution needs to be tight.

The Kindle iphone app has a nice example of how this can work in the way that it manages orientation.  Rather than having an option to lock it buried away in a menu somewhere or always cluttering the screen, it instead appears the moment the screen switches.  It’s subtle but obvious and presented in an elegant, modeless way that doesn’t interrupt you if you did intend to switch the orientation and extends a hand if you didn’t.  If you’ve already locked the orientation it provides a nice status indicator right at the point it becomes relevant; which doesn’t interrupt your reading if you didn’t mean to switch the orientation but catches your eye if you did.

I’m reading my book:


The orientation switches (whether accidently or deliberately) and the lock status/control appears:


If I’ve already locked it I’ll instead see this:

You aren’t conscious of the orientation of the screen until it switches; and at the very moment your locus of attention is drawn to the orientation, the locking option appears.  Before you can finish thinking “I need to lock that screen” the control to do just that appears – it almost feels a little bit like magic.

I’ve always found the iPad’s handling of orientation a little bit clunky.  I need to think about it and it becomes a mini-task in its own right.  This is a more elegant solution and an exemplar of how to deal with complexity without breaking flow.