Over a million developers have joined DZone.

Help People Understand How to Use Your Software

DZone's Guide to

Help People Understand How to Use Your Software

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

In my previous blog I unveiled some subtle reasons why people don’t understand how to use some software products, despite the genuine efforts of the UX teams to come up with an intuitive UI.  Today I will write more on who those “not-understanding” people are, and how to help them understand. I recommend giving this blog some 10+ minutes of your time, as it’s not a clueless quick fix tip but rather an essential consideration that has to be taken into account by product owners and UX designers if they truly intend to create a comfortable and easy-to-use tool that will sell itself well.

  • Do I need this software?
  • Does it help me do what I want to do?
  • How it saves my time, if at all?

With slight variations, these are mostly the questions that people want to get answers to, and fast, as they start looking at a software app.  They want to understand how to use it, figuring out at the same time if this tool will help solve their problems and/or address their needs, and if they can do what they want to do intuitively and fast enough. This question-asking is not a sequential process but rather a non-linear one. Obviously, each and every software maker wants people to get committed to their product faster, so let’s take a closer look at those prospective users.

People Are People: Explorers, the Confiding, and Give-Me-Someone-Live’s

I’m a proponent of the human-centric approach to anything. Never will I get tired repeating, that each and every screen, and interaction model in software is made for humans. So, people should be the starting point even for the decisions that might seem purely technical. This is all based on human psychology.

After more than a decade of my work in marketing, I can single out the three main categories of such product seekers: the Explorers, the Confiding, and Give-Me-Someone-Live’s.

Explorers are like restless kids. They want to click through and to probe everything, to do what they need to do hands-on, with no outside help. They usually ignore the product walkthroughs. They explore software products intuitively.

The Confiding are good boys and girls. They want to follow the process of learning the product diligently. They confide in software product makers to help them make their decision. So, first thing, they look at the getting started flows, user guides, tutorials, cheat sheets, the help documentation.

Give-Me-Someone-Live’s  are very different. They think that any time spent on exploring, or following the getting started flows is wasted time. So, they want someone “live”, e.g.  a live online chat or a live demo from a product specialist or a support engineer, to help figure them out if the product is what they need.

This is a very rough outline, of course, these 3 types intermix quite often, but in general anyone who is looking for a software product has more or less from one of those categories in them. That’s why I’m not presenting this information in the finite visual form of, say, a table with the categories and lists. It’s non-finite, and very individual, and it depends on people. This relative categorization gives an outline of the idea only.

One flow fits all? Hardly so!

Now, what is it that software makers can do, keeping in mind those 3 types of prospects? They now have more knowledge to create the optimal learning space for such people, depending on their preferences.

Explorers need the intuitive UI more than the other 2 types. They’re more likely to go away if the UI is not intuitive, they won’t spend their time figuring out if a setting that has to be changed to do what they want to do intuitively, is hidden somewhere far inside the software (just an example).  That’s why Explorers also need the clear tooltips, the “What’s that?” messages, and all kinds of smart contextual help tips.  But the intuitive UI comes above all. That’s the first thing such people need. And the error messages. If the software throws back an error, they need a good error message that will tell them how to do what they need to do quickly. Or, at least, if the context is ambiguous, the error message would tell that what they tried to do can not be done. It all depends on the context very much.

Here’s how the exploration paths can look.  The broken paths are marked with the red crosses, and a few success paths with the green ticks:

the multiple flows

For the Confiding, wise Getting Started flows, all kinds of guided tours, well-written user guides and tutorials are the major prerequisite. They want to be guided. They will work to follow the lines that software makers should have had in place for them to make their decision. As a side note, from my observations, the Confiding type are quite often the elderly people, that keep their beliefs from non-software world that a producer of some commodity will give them good guidance on how to use their product. Just a side note.

You might wonder, why I said nothing about the product videos and recorded demos? It might seem that videos are a great option both for Explorers and for the Confiding. I wouldn’t be that sure. Watching a product demo video is passive, like watching TV. What people see as they watch a product video is the joyful Hollywood finale of how someone else is using the software for something that the watcher might not have yet grasped. So, it’s like a cartoon. Besides, it’s not easy to get back to a video if they want a quick tip on how something should be used.  Here’s the one thing that people can take out from the videos:  this product is really capable of doing something well, and fast. A smart video will provide them some encouragement, the feeling that this product is exactly what they need. It’s not bad at all, but it’s passive, and I think that the Confiding are more into watching videos, than the Explorers.

Finally, what do the Give-Me-Someone-Live’s need? Obviously, they need some live flesh :) *joke* They want to chat with someone online, or to talk on the phone, or they want a product specialist to come to their office with a demo. For them, you need to put up signs wherever possible showing how to get  in contact with the live support, or with a product specialist, to set up a live demo of your product.  This category of prospects can be too costly, unless you’re a well-established company with the smooth-running support and product specialist teams. So, for bootstrapped software start-ups the Give-me-Someone-Live prospects are not an option. If you’re small, you just can’t afford keeping the field troops (read, the support team and the product specialists team). In this case, you need to be even smarter, and invest more of your time and consideration in holding the comfortable learning space for the Explorers and the Confiding right in your product. This means, you need to take more time thinking about the paths, to provide the connections between those paths wherever possible (compare with the image above):

the interconnected flows

Let me emphasize, that these 3 types are singled out just for easier reference. It’s very rare that some user is purely one of those types. But this categorization helps you see what in the UI needs to be done like this or like that, again, to ensure that casual leads find out if your product is what they need as fast as they can, and eventually become your clients. It’s about the bottomline $$$ stuff even more than sales and marketing.

I intend to write one more blog post about the “help” aspect of software products. Stay tuned.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies


Published at DZone with permission of Olga Kouzina, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}