When using software for the first time, discoverability is important, but at the very least it needs to be backed up with clear documentation. Without this the developers could be fighting a losing battle
The last few months have seen me spending a great deal of time working with brand new software tools and services – something in which I take great personal delight.
While it’s always interesting to work with the latest and greatest software from the well-established vendors, I often find brand new tools more interesting. It’s with these that you find the potential for true innovation, rather than evolution.
I’ve been test-drving software long enough to be confident to dive in and work out how things work without recourse to the online help. But in this instance, I got stuck.
The problem was that no matter which buttons I pushed, which sliders I slid, I couldn’t get the thing to render out properly and ended up with poor results.
The supplied documentation wasn’t much help, as it simply didn’t tell me what I needed to know. i.e. how, in the name of all that’s holy, could I get the rendering tool to… well, render?
I worked through the documentation word by word, from start to finish. Nothing. Quite a frustrating result for three days of work.
Then I found it. It boiled down to one slider and one selection from a drop down list and once I realised this, away I went. Rendering like a maniac, I managed to create some amazing imagery in the space of an hour and really went to work on the tool. With that key discovery the software was transformed and actually became easy to use.
This made me think about how ‘discoverability’ is more important than ever before, or for those not familiar with the term ‘how easy it is for a user to locate a command in order to complete a certain task.’
Many of today’s software applications are available as 30-day free downloads and, as a result, we’re becoming more and more used to starting them up blind, seeing what they can do and working out how they might fit into our workflows. The odd thing is that only once we have decided to purchase a product do we consider investing in training.
Introducing new interfaces and workflows is the only way for progression, otherwise we’d still be using command prompts and cascading menus, but sometimes software developers forget that potential customers have very different levels of skill and experience.
What might seem obvious to one user is completely alien to another and if a product is not immediately discoverable it certainly needs to be backed up with clear and concise documentation that does not make assumptions about prior knowledge or expertise.
Being able to pick up any software tool and immediately start running with it is the Holy Grail of software development. But with the inherent complexity of product development software this is rarely achieved. In the case of VRED Essentials I’m glad I persevered as it turned out to be a good, usable tool, but I wonder how many others, less stubborn than me, would have switched off before getting anywhere near a purchase order.
Al Dean is Editor of DEVELOP3D. He once vowed never to let software defeat him, unless it’s Microsoft Office for OS X which only lasted three months on his Mac.