Learnability, affordance, and rejected systems.


Lots of people talk about the need for simplicity in designs, and some even provide various examples of what makes for a good minimalist design and what doesn’t.  I often find myself disliking lots of these examples for various reason, but mostly from my experience of critiquing designs from a usability perspective, and knowing what works, and what doesn’t.  That being said, I’ve no intention of rambling on about a subject which has been covered to great extents already by many people.  Instead I’ll talk about an often forgotten aspect of good designs, called learnability.

When we talk about the learnability of our software, we are generally discussing how hard it is for a user to learn how to use it.  Now the learning part could be the product as a whole, a feature, or just some aspect of the design that we’re unsure about.

This is a very interesting subject, and a wonderful aspect to test for as it really gets your brain cells working and debating furiously with one another.  However be warned, making design decisions based upon what we feel is right or wrong is a very biased thing to do.  We might feel the decisions that we make are for the best, but how do we really know for sure?  That’s why user feedback techniques such as paper prototyping, and usability evaluations are so useful, as they provide real feedback, from real users.  Of course, one of these techniques takes a very proactive approach to user feedback, whilst the other is more often than not a late, reactive activity which comes with a much higher cost to implement changes.

Common get-outs

Before going into some examples of what makes for good or bad learnability, I’d like to mention some things to be wary of when discussing learnabilty issues with others.

Users will be trained on how to use the system

In the past I’ve discussed some genuine leanability issues with developers, and encountered invalid arguments for why they shouldn’t be resolved.

One such argument was that all new users of the product (which at the time was custom built for individual companies) wouldn’t have to worry about learning certain aspects of the user interface, as they would be trained on how to use it.  We obviously couldn’t guarantee that a company purchasing our product would pay extra for training costs as part of their purchase.  Nor could we guarantee that whatever was being discussed as a potential learnability issue would be included in any training material, should it occur.

I’ve often encountered the training argument in the past when discussing learability issues, and it’s always an interesting one, as even should the training be provided to the users of the system, and the participants be able to remember some distinct issue that was discussed, and be such fantastic users that should they ever forget, they immediately read the products user documentation (more on that later), and then…  You see where this is going don’t you?  It’s kinda like writing a nasty big if statement, and finally at the end of all these pointless checks, something happens!

You could, and please stop me in my tracks if I’m talking nonsense here, but you could just do it right, and have an elegant design that doesn’t force the user to think deeply about how to complete some action they wish to do.  Rather than adding layers of bandage around the problem, simply fix it, and learn from what you did wrong to improve your designs in the future.

Probably the biggest flaw in the training argument is the inability to accept that this could be a fundamental issue with the original design.  In a worst case scenario, potentially requiring you to go back to the drawing board, and flesh out a new design that works.

The emotional investment problem

This is an emotional investment problem.  Some people find it hard to accept flaws, which will potentially require changes, or indeed re-writes to designs that they’ve invested time in, and have therefore become emotionally attached to.  We see this all the time in science with flawed theories which have had so much time invested in them, that some scientists are unwilling to accept that they simply won’t work as they’d originally expected.  Despite science itself ruling out supporting evidence for such theories, many will still strongly defend them, and refuse to drop all their hard work, to start again, or accept that their idea simply won’t work.  The good scientists, and developers will accept the flaw, and come up with a new approach that will work, and will keep the project moving in the right direction.

The documentation get-out

Another learnability argument, which I’m sure you’ve heard many a time, is that users can read the accompanying documentation, to learn how to use something.  Sure, obviously all users do that!  Just like training, this is another easy excuse to give should you not wish, or have the time to do something.  Most often than not the documentation discussed doesn’t even exist yet, so again this might not include instructions for the discussed issues.  We can’t predict how a user will react to learnability issues, but wrapping layers of further learning around them certainly won’t help matters.

As a side note, I absolutely love good documentation!  However should I need to access it, to learn the very basics of your product, then you have clearly already failed.

Learnability isn’t about teaching users how to use your product.  It’s about making them not have to think!  Or at least doing your best to prevent the amount of mental mind-work that they’re required to do.  People don’t like to think after all when using something that’s new.  Thinking too much is what creates rejected systems.  Things should be immediately apparent, and when they’re not, they should be so far outwith the critical path of your product that the user doesn’t care.  If they do, then great!  It’s their choice (yup that’s right, their choice) to learn that nice to have extra feature, which doesn’t necessarily prevent them getting from a to b.

On rejected systems:  You have two types of users when it comes to a rejected system:  Those who are forced to use it (since their company, or perhaps themselves have invested a lot of money into it) and those who have browsed upon it by interest, and quickly rejected it.  Both matter greatly, and the quickest way to lose these users interest, is to make your product difficult to learn.

Good learnability

When I talk about good usability, and learnability in products I always shout from the rooftops about a prodcut named Jing!  Jing is essentially a screenshot and video capture tool, which in itself is a very basic task.  The good thing about Jing is that they’ve realised that most people want to grab content quickly and share it with others.  This is essentially the model for their entire product.

Out goes the loading of an application to take a screenshot, or remembering some shortcut to take a picture, instead it’s replaced with a vibrant, highly visible globe which appears at the top of your screen.  When you don’t need it, you forget it’s there.  When you do need it though, it’s quickly accessible, and intuitive to use.

Should you wish to add some visual highlights to your screenshot, you can quickly, and easily, using the next to rapidly load edit screen.  From this screen you can simply choose to save the image and move on, or edit it, using some well thought out basic editing options, which are very quick, and simple to use.  Even the fact that the most commonly used edit action (a line) is pre-selected allowing you to immediately begin to highlight things, is well thought out, and shows that the company is keen to make the product work for those that matter most, the users.

An example image of editing a screenshot with Jing.
The above image, demonstrates an edited screenshot in Jing.

You can choose to save, or upload to a service called screencast which will let others view your screenshot from anywhere via a simple URL, which is immediately copied to your clipboard for pasting in a email, or bug report, because obviously that’s what you would have done next.  See, a smart company who consider their users needs, right down to the minute details.

The whole process of taking a screenshot, editing it, and sharing it can literally take as little as thirty seconds, due to the easy to use (no thought required) interface.  Doing the same thing with video is just as simple, and painless.

Learnability is so important, and preventing your users from having to think, is what makes good products great!  Jing is an excellent example of simplifying your products critical path, and creating a really simple, sleek, usable system.

Borderline learnability

TweetDeck is a good example of what I would class as borderline learnability.

An example image of the TweetDeck user interface.
An example of TweetDeck’s user interface. The non critical path, tiny buttons are highlighted with a red border.

You can see from the above screenshot that the interface achieves the basic needs you’ve downloaded it for in consolidating your social media streams, and providing alerts when someone has mentioned you, or shared your content.  Whilst it has some niggles, for the most part the critical path doesn’t involve much thought.

What makes TweetDeck a good example for borderline learnability, is its use of extremely small icons, and lots of them, to do various actions.  In order to find out what any of these do, you’d need to hover over them and learn about what their capabilities from the tool tip.  With some you could tell immediately from the icon what they would do, such as the photo icon, which would indicate that you could add a photo to shared content.

The tool does however tread a thin line in terms of learnability.  Some users will love it, and want to learn extra functionality outwith the critical path, as and when needed.  Others might simply look at it, and choose to ditch it, thinking it looks too complex, or even just too much of a hassle for their liking.  That’s the problem with tiny icons for actions, they quickly went out of fashion because people didn’t like them, as their purpose wasn’t immediately apparent.  TweetDeck decided to keep them, and as they are not in the users critical path (viewing and sharing content), they don’t pain users as much.  However it is a slippery slope, which should be avoided when possible.

Poor learnability

vSphere from VMware, is a perfect example of poor learnability.  Essentially it allows you to manage virtual machines that you’ve added to a server with Hypervisor (ESXi) installed.  It doesn’t matter if you’ve had no experience of either product, or virtualization of any kind, read on.

Now I’ve got a fair bit of experience installing and configuring virtual machines, and apart from the very poorly laid out UI that is vSphere, there was one thing that had me utterly confused.  Any time I had to download a new operating system to install on the ESXi server, I needed to burn it to a DVD, and using the clunky vSphere interface, instruct the new VM to boot itself from this disk so I could go through the steps required to install the OS.

“Why not just upload the ISO to the machine, and install it directly?” you might ask.  Yeah well, that would make a lot of sense, however for the life of me I couldn’t find an option to do this on the interface.  It was almost as if they’d hidden it in plain site, just to toy with me!  Anyway this was plan A, the burning to DVD was plan B, developed from giving up and trying to find a workaround.

Fast forward about a week, and I had to burn a disk for another operating system I needed to install.  The problem was, this time the ESXi server refused to recognise the disk, or indeed the second one I burned shortly after trying the first.

Now I really needed to figure out how to upload my ISO files directly to the server, so I did a bit more exploring.  Thankfully by chance, this time I quickly found out how to do it.

An image highlighting vSphere's hidden option to upload content to your servers datastore.
Above is vSphere’s hidden option for opening your servers datastore, to allow you to upload content such as ISO’s for new virtual machines.

Hidden in the context menu of a table on the summary tab of the server, is an option “Browse Datastore”, which  funnily enough even though it is hidden away from you has its own shortcut key (how thoughtful).

Introducing affordance

Now this brings me to a topic we haven’t covered yet called affordance.  Affordance and learnability, are very closely related.  Whilst good learnability often goes hand in hand with not making your users think, affordance makes them think, and discover.

Affordance is very big in the mobile world, you’ll see a lot of affordance considerations there that you may not have thought about previously.  Things like pinching a picture to zoom, and sliding left to right to navigate content, all come with a level of affordance provided to them.

Affordance essentially dictates that a user will be granted the ability to learn a new feature in a product, and it will not be immediately apparent to them.  Really good affordance almost urges the user to learn and unlock a feature.  In the mobile world, with touch screen technology we see lots of good affordance techniques, and as people are often crazy about their phones they often learn these very quickly, or hear about them from others.

People are less passionate about applications, and will generally be less forgiving of poor affordance choices.  vSphere for me take the term poor affodance to a whole new level with their crazily placed context menu option, which leads you onto a popup screen, to then allow you to upload content to the server.

In products, just like learnability, considerations for affordance should be scrutinised when they are in your users critical path.  As a general rule of thumb, if a critical path option has a level of affordance for learnability with it, and it doesn’t have an immediately apparent alternative, drop it!


So I’ve talked a lot about learnability, and looked at some common get outs people will use to try and not fix these issues.  I briefly touched upon rejected systems, and why poor learnability choices can quickly lead to one of these.   I looked at the good, the ok, and the glaringly bad in terms of learnability, whilst also touching upon the topic of affordance.  What I’d briefly mentioned, but didn’t cover, was the use of usability techniques such as paper prototyping and usability evaluations to help uncover such issues.  That tough is another topic, for another time…

Thanks for reading.

No related posts.