If you are developing consumer software, you must be clear that, in terms of computer understanding, you are at a different level than most of your customers. When you start to provide technical support for your software, you may be shocked by the wide gap. This does not mean that your users are all dummies, just because they didn't spend as much time on computers as you do. Below I have summarized some experiences gained by answering thousands of technical questions about my seat-arranging software:
1. copy and paste
From the large number of technical support emails I received, we can clearly see that users often re-enter the serial number I sent to them by email, which seems to be because they do not know how (or they can) copy and paste text. Sure! You can alleviate this problem by explaining how to copy and paste serial numbers in the software manual (this is fast and can avoid confusing characters, for example, "0" and "O ").
2. Differences between web pages and local applications
Many Web applications do not understand that they need to download and install new versions of desktop software to use some new features. You can avoid this problem by automatically updating the program, but if you make a mistake, the result will be quite tragic.
3. Data Storage
Many users do not understand how their data is stored, where it exists, or even how the data is separated from the application. They cannot understand that some data exists in their local hard disks, while others exist in the cloud. They cannot understand the differences between files, databases, and registries. When they install desktop applications on a new machine, they may be surprised that they cannot access the documents created on the previous machine. Therefore, it is valuable to add instructions on how to migrate data from one machine to another in your FAQ.
4. terms you use
It is often annoying to use a term that your users cannot understand. For example, non-technical personnel cannot understand what a "dialog box (DIALOG)" is, rather than "Modal Dialog. You can call it "window".
5. Right-click
Some users do not find (or may not want to try it) by right-clicking. Therefore, do not place any function in the right-click menu or other places that are not easily discovered.
6. Concurrency)
Some applications can process parallel access (such as client-server applications and Web applications), while others (such as most desktop applications ). However, many users think that all software is safe when used by multiple users at the same time. If your software cannot achieve this, you may need to describe this in your brochure to avoid user-generated errors.
7. What changes can be restored?
Technicians are very happy to use some software and observe what happens. They usually don't worry about "trying" something, because they can recover most of the changes through "undo", version control, or backup, generally, they can determine whether an operation is unrecoverable. Non-technical personnel are not so confident, so they will not try something in the same way. In fact, some people may feel that a wrong mobile operation may cause a computer to blow up. Therefore, we usually try to only do the traditional operations they understand (such as using Microsoft Office and outlook on Windows), and provide detailed tutorials for complex tasks.
8. When do I need a backup?
Every few days I will receive an email from someone saying that all of his data is lost due to a big hardware fault and not backed up on an independent device. Sometimes this is because they don't even realize that data is stored on their own computers. You can remind them of the need for backup in your documents or software, but there is no difference. History has proved that this is a lesson that most people have to learn (including technicians ). The reminder that backup will not hurt anyone, and if you point this out after the incident occurs, it will also help to resolve the user's anger.
9. They should read the document
People use your software because they have something to do. Whether you like it or not, your beloved software is just a means to reach the end. Although some users may read documents, most people think this is a waste of valuable time. In fact, I can see an unquestionable fact from the client mail I received: some users did not even read an error message to explain the problem. This indicates that you need to write a clear and accurate document, but you also need to develop your software with a hypothesis: most users will not read it. This is why we need to test availability (usability testing ).
10. Questions in the middle of the keyboard and chair
In the middle of the keyboard and chair? You may ask, what is this translation? For more information, see:Paebk, problem exists between keyboard and chair
Users with a lack of skills often do not realize how many skills they lack. In this way, they may blame your software for their own mistakes. You can only be as polite as possible on this issue. If the customer doesn't have enough skills to use the software, you should politely suggest "Obviously their needs are not ideal" and provide them with unconditional refunds. However, if many people ask the same question, You need to modify your product to better suit your users (it is good to change users to adapt to your software, but unfortunately it is not feasible for most people ).
Http://successfulsoftware.net/2010/08/24/10-things-non-technical-users-dont-understand-about-your-software/.