Fear when using a product is always there, manifesting itself in different ways. On Twitter it could be the fear of posting something private to your public timeline. For a CRM, it could be the fear of deleting an important contact. It happens to everyone and on every product. I remember when I was first using VisualWebsiteOptimizer I set up a test that used the regex on the URLs to control the pages that the experiment was to occur on. However, there was no way for me to test that the regex was correct and I hadn’t inadvertently done something wrong that would break the site. As I couldn’t be sure it was correct I abandoned the experiment and VWO. The benefit from the experiment was outweighed by the downside of getting the regex wrong. I feared running the experiment.
Fear causes users to abandon products or avoid using a product to its full capacity, which makes it a crucial problem for product managers. It doesn’t matter how slick or how ‘usable’ your site is. If it doesn’t minimise fear, the product won’t get used.
Here lies the fallacy of ‘intuitive’ user experience. The much-vaunted ‘intuitive’ products aren’t actually intuitive. They are ‘intuitive’ not because they have some wonder design, but simply because they have successfully (on purpose or by accident) reduced the fear in the product to the point users are happy to play and experiment. There is still a learning curve, but users can just rise up that curve quickly and safely.
Starting with the concept of minimising the fear in the product from the beginning will help you build an ‘intuitive’ product. Even if you’ve got a mature product you can still progressively work through the product reducing the fear points. Assuming you don’t have infinite resources (what product manager does?), you need to focus on the most important fear points. Fear points are the steps, actions or functions within your product that generate fear in users.
Focus on the fear points of the product that generate the most damaging fear in users. Surprisingly, this is straightforward. Fear is created when the risk of being wrong exceeds the benefit of doing. Review your product for the journeys and functionality where that happens and then consider the importance of each journey to the overall experience of the product asking yourself the question:
‘Does not using this part of the product material reduce the effectiveness of the product to the user?’
If the answer is yes, then you need to fix that and quickly. Otherwise, your product is not worthwhile to users and they will stop using it. If no, then you don’t need to fix right away.
There are multiple strategies for minimising fear in a product and the approach that you take will depend on what your product is . As a starting point you can consider the three major strategies of undo, sandbox and user guides.
Make everything undoable. Allow users to undo the various actions they have done. This provides the comfort of being able to easily fix any mistakes someone makes make simply by pressing undo.
The original version of merging ideas in ProdPad was irrevocable. Once merged two ideas couldn’t be unmerged. So we had a great big warning during the merge process that it was irrevocable. Every time I used it there was always the fear that I’d screw up the merge and so despite being useful I rarely used it. The current version of idea merge is undoable. If necessary a merge can be reversed, so the psychological barrier to using the feature is much lower. I use merge a lot more now than I used to because I know I can always reverse it if needed.
Give users a chance to ‘try’ functionality and practice before working on the real data. The opportunity of testing stuff helps users build the confidence in their abilities. They can make mistakes and fix them without fear of screwing anything important up.
Zapier has an interesting approach to this for both users and developers. For developers you create the Zap and test in ‘dev’ mode allowing you to fix all the problems before making it live to general users. For users as you are creating the Zap you can test to see if you’ve set up everything correctly (the correct data is being pulled from x and is translated correctly for y) before making it live. Both approaches help reduce the fear of using Zapier for the two different user personas that Zapier has.
Teach, I need help
Provide users with the ability to learn how to use a product. Don’t rely on them being able to guess how things work. Providing learning aids gives users confidence when using a product. Whether or not they end up making mistakes, this confidence reduces the fear of the consequences of mistakes. Training aids could be videos, help/how to guides such as we’ve written for Prodpad and interactive guides built into the product, such as you can do with Zurb’s jQuery Joyride plugin.
If you use help/how to guides, don’t rely on the FAQ/knowledge base. You aren’t answering a question, you are teaching. The guides need to walk users through each step of a function or journey and use screenshots so users can understand what is going on. I see far too many companies rely on the FAQ/knowledge base services provided by GetSatisfaction and TenderApp. Mailchimp has some great examples of teaching aids.
Fear is damaging to a product’s value to the user. Unfortunately, fear doesn’t manifest itself in an obvious manner. You have to hunt for fear points within a product. Usability testing can help here, but in the end you need to put yourself in the user’s shoes and work through looking for the places where mistakes could have disastrous effects for the user.
No product is intuitive, despite what the gurus say. There are products where the fear is minimised to the point that users happily adopt and learn how to use it through trial and error, safe in the knowledge that anything they do won’t be disastrous. This is the real ‘intuitive’ UX. There is still a learning curve, but the user is supported to rise as quickly as possible up the curve.