Learnability
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.
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.
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 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.
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!
Wrapup
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.
Good post that confirms that the learning curve of an application should be as fast as possible, effortless and natural.
My point of view is also that learnability will decrease while the complexity of the application/supported process increases and it is difficult to maintain a good balance.
Another point is that the design/usability of an application also depends on the targeted audience. Some applications are designed for technical people (as VM management softwares or server monitoring tools) or professionals of a specific domain (as project management, unit testing, biological analysis…). So usability is percieved differently by a different audience and their experience in the domain, even if I admit that I am more comfortable with a mind manager-like tool to manage projects instead of a MS Project-like and that some standards exist about software usability and software design.
This is not an easy issue to solve but I think that the best rule while an application is defined is that the usability must be evaluated all along the developement process and that users (current, future or potential) should be involved in any manner.
Arnaud
Hi Arnaud,
Thanks for your thoughts. They make an excellent extension to the post.
Of course the learnability of an application is context sensitive, and a very good point that you make here. However very few complicated applications manage to strike a balance between providing complexed functionality, and an easy to use means of accessing and using them. Many also fall into old habits of poorly designed UI paradigms, which have been well documented as flawed UX models. This is probably a lack of knowledge on their part, that could have been resolved by hiring a good UX person at the design stages.
Testers can play key roles in identifying learnability issues, however the problem is that many still consider this as a role for specialists, even though this is not always the case. Hence why many applications can be tested by experienced testers, but have lots of usability issues associated with them, resulting in very poor UX. Quite often as well, testers have been pushing for these issues to be fixed, but find the decision makers are more interesting in a functional, working product that can be shipped quickly. That’s why presenting a compelling story around issues is often half the battle in getting them fixed.
Thanks,
Darren.
Whoa, Jing is a great wee tool!
Totally forgotten about it after you had mentioned it last year.
I’m a bit of a RapidReporter-ite these days, but as you said, capturing an annotating images, not to mention video with Jings is an absolute snap.
If only Shmuel could integrate Jing into Rapid Reporter, eh?
Hey Del,
I messed about with Session Tester ( http://sessiontester.openqa.org/ ) for a while when doing session based testing, then I had a play with Rapid Reporter as well.
In the end though I found myself using windows notepad, and anything unresolved from my notes either went straight into my todo list as a task, or a mindmap for visual feedback.
I find google docs is good as well for taking session notes, as you can share your document prior to the session starting with others, such as other testers, or a developers code that you’re testing. That way when you go to discuss something from your notes, and if you’ve added a screenshot or a stack trace with it, you can easily ask them to open the document you shared, while discussing it.
Thanks,
Darren.
True enough, Darren but some company environments are a bit more restricted than others. Proxy access for instance at our place, prevents us from using simple things like Google Docs and there’s alsways the issue of having proprietary information of any sort on a public platform.
Still, swings and roundabouts, eh?
Fair point, and for Jing that was certainly an issue in our last workplace. Not so much a restriction in accessing certain internet services, but more so in the data ownership of remotely stored content. After making sure ScreenCast (a remote data hosting service for Jing) didn’t retain ownership of any data we would upload, we’d use a password protection feature for our pictures / videos to make sure our data wasn’t viewable by the public.
I guess from a learnability viewpoint this was a notable issue with Jing, as password protecting content on ScreenCast wasn’t immediately apparent. I remember it took a bit of digging about to work out how we could do it. Hopefully it is much easier to use now, but I wouldn’t know as I no longer use the ScreenCast side of Jing.
I guess this goes back to the critical path viewpoint. Ensuring that your products critical path provides a fantastic experience, will cover the vast majority of your users needs. High investment here usually pays off. The non critical path features will often get less attention though, which can lead to even the best products having niggles.