10 software concepts that non-technical people cannot understand

If you are developing consumer software (Consumer software), then you must be aware that you are at a completely different level from most of your clients in understanding the computer. When you start technical support for your software, you may be shocked by the magnitude of the gap. This doesn't mean that your users are fools, just because they don't spend countless hours on the computer like you. The following is a summary of some of the thousands of technical questions that have been gained by answering my row block software.

1. Copy and paste

From the large number of technical support emails I received, it was clear that users often re-enter the serial numbers that I sent them by email, which seems to be because they don't know how (or they can) copy and paste text. True! You can mitigate this problem by explaining how to copy and paste the serial number in the software manual (this is not only fast, but also avoids confusing characters such as "0" and "O").

2. Differences between Web pages and local applications

Many users who use Web apps 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 the result can be quite tragic if you make a mistake.

3. Data storage

Many users do not understand how their data is stored, or where they exist, or even know that the data is separate from the application. They cannot understand that some of the data exists in their local hard drive, while others are actually in the "cloud". They do not understand the differences between files, databases, and registries. So when they install desktop applications on a new machine, they may be amazed at the inability to access documents created on the previous machine. So adding a note about how to move from one machine to another is valuable in your FAQ.

4. The terminology you use

Using terms that your users don't understand often makes users very annoyed. For example, a non-technical person is completely unable to understand what the dialog box (dialog) is, not to mention the modal dialog box (modal dialog). You can call it "window".

5. Right-click

Some users did not find (perhaps did not want to try) to click the right mouse button. So you don't have to put any functionality in the Mail menu or anywhere else that's not easy to find.

6. Parallel (Concurrency)

Some applications can handle parallel access (such as client-server applications and Web applications), while others do not (for example, most desktop applications). But many users think that all software is safe when used by multiple users at the same time. If your software does not do this, you may need to explain this in your brochure to prevent users from making false expectations.

7. What kind of modifications can be restored

Technicians can be very happy to use some software and observe what's going on. They usually don't worry about "trying" something because they can recover most of the changes through undo, version control, or backup, and often they can tell if an operation is unrecoverable. Non-technical people don't feel so confident, so they don't try things the same way. In fact, some people may seem to think that a wrong move could cause the computer to explode. So usually try to do only the traditional operations they understand (for example, they use Microsoft Office and Outlook on Windows), and provide detailed tutorials for complex tasks.

8. When to back up

Every few days I get an email from someone saying that because of a big hardware failure, all of his data is lost and not backed up on a standalone device. Sometimes this is because they don't even realize that the data is stored on their own computers. You can remind them in your documentation or software that they need to be backed up, but that makes no difference. History proves that this is a lesson that most people have to learn (including technical staff). Reminding a backup doesn't hurt anyone, and if you point that out after something happens, it can also help defuse the user's anger.

9. They should read the documentation

People use your software because they have something to do. Whether you like it or not, your beloved software is just the way to get to the finish line. While some users may read the document, most people think it is a waste of their valuable time. In fact, I can see an undeniable fact from the customer mail I received: Some users don't even see a word explaining the error message. This shows that you need to write a clear and precise document, but you also need to take a hypothesis to develop your software: Most users don't read it. That's why we need usability testing (usability testing).

10. The problem between the keyboard and the Chair

Users who lack skills often do not realize how poorly they are. This way they may blame your software for the mistakes they have made. Only as polite as possible on this issue. If it is obvious that the customer does not have enough skills to use the software, then you should politely suggest that "obviously their needs are not ideal" and provide them with an unconditional refund. However, if you personally ask the same question, then you need to modify your product to be more relevant to your users (changing the user to fit your software is certainly good, but unfortunately for most people it is not feasible).

10 software concepts that non-technical people cannot understand