When developing software products, developers need very much to get feedback from users of their programs. The article discusses various means of arranging communication for getting this feedback. In this article, by an example of the tool for software developers, we discuss efficiency of various methods to get feedback.
While developing software, it is very important to get feedback from users to make products better. It may seem strange but developers are not always interested in improving their programs. The use of a particular program might be often controlled by orders "from above" and users cannot refuse a bad program for a good one. In this case, developers are not interested in getting feedback from users and making the program better. It is even just on the contrary - they'd better hide in order not to be disturbed by "silly users". It is especially evident in the banking area when using some internal software. The developers of this software hide from users. But users find their phone numbers in phone books all the same, call them and simply MAKE the developers improve the program since users' work depends upon it. But in the competitive environment, people simply refuse to use a software product if they cannot contact the developers (and ask them to improve something). That is why developers in the competitive environment are interested in users' being able to easily contact them and send their feedback.
Relying on his experience, the author of the article shows various methods of stimulating feedback from users and communication between them and developers. This experience is about developing/promoting/selling the tool for software developers called PVS-Studio. PVS-Studio is a set of static source code analyzers intended to detect 64-bit and parallel errors in programs. PVS-Studio integrates into the Visual Studio 2005/2008/2010 environment and supports the C/C++ languages.
It may seem strange, but there are still a lot of sites and programs on the Internet from which you cannot understand who the authors are and how to contact them. It is especially typical of developers of new software products when in haste (wishing to release the first version as quickly as possible) they forget to specify their contacts.
'Of course' (as developers think), users will guess to write by the e-mail support@domain. Why to specify it anywhere? But users do not think this way and sometimes they want to write a letter but do not know where.
If you want the users of your software product to be able to easily contact you, add your contacts both in the program and on your site. And place them where they will be seen well! You can increase the number of users who will write to you by making the "Contacts" link more visible.
One of the simplest and most evident means to get information about the users of your software product and even start to communicate with them is to lay out an inquiry form on the download page asking them to write the first name and last name, job and contacts. Users will not be able to download the program until they type all these data.
After that, you may choose one of the following ways:
1. The user immediately gets the link to download the file on the site.
2. The user gets the download link in a letter which is sent by the e-mail specified by the user during registration.
3. The user gets the download link only after the company's workers responsible for checking the user data phone this person.
4. The user DOES NOT get the link if he does not seem to be solvent enough to the company.
What can you use the information obtained from users before downloading the software product for?
5. To provide your sales managers with materials.
6. To control distribution of the trial version of your program (break-in security).
7. To reduce load on the company's server.
In early versions of PVS-Studio, we did not permit to download the program without specifying this information. Thus, we have learned that most people work for the company "1111″, the most popular e-mail is "a@b.com" and there was a user with the name "222″ who downloaded the product VERY often.
Of course, we could introduce the mechanism of checking personal data both with the help of special software and our workers but we completely rejected user registration when downloading the program. The main reason was that there was not too much sense in communicating with users at this stage. They only began to study the program and had no particular questions or requests. Still, many were kept from studying the tool due to the necessity of creating an account. Despite the fact that most code analyzers require specifying information about the user at the stage of downloading the product, we gradually decided to reject this mechanism. And we do not regret about it yet.
However, this method of obtaining information about your users is still rather popular.
One more popular way to get information about a user is to ask this person to fill in an inquiry form when installing the program or after uninstalling it. This method is popular because it is easy to implement.
But it is hardly good. Just like in the previous case, the user has nothing to say to the developers when installing the program - he simply has not seen the program yet and therefore has no questions. But the user has all the more nothing to tell the developers when he uninstalls it! For example, you are often asked during the uninstallation process what the reasons are and even offered variants to choose from. But the reason why the user uninstalls the program is ALWAYS the same - he does not need SUCH a program. By "such" we understand either a poor quality of the program, or a high price, or something else. Anyway, there is no sense in further communication with this user - he has made up his mind. Well, of course you may try to make a conclusion from the data you receive and improve the program for those who will use it next.
Unfortunately, programs have errors. Very often developers do not see errors that can cause a program crash. Although it is an unpleasant situation, it can also be an occasion to establish communication between the user and developers.
For example, in PVS-Studio, when the program crashes (it is very rare but still it happens), a special dialogue box is displayed (Figure 1):
Figure 1 - A message with the appeal to contact us when the program crashes
Once we have implemented this window, the number of users who would like to communicate with us about the program crash has greatly grown. Very often, relying on this message, we can determine what the problem was and how we could fix or circumvent it.
In some software products, for instance, in the Opera browser, you can easily contact the developers. In Opera, there is a special command "Report a site problem". By choosing it, the user can complain to the developers if some site is badly displayed in their browser. Although there are no open statistics about how many people use this function, most likely, it is rather useful.
Sometimes you may invent unconventional methods of inviting users to communicate with you. In PVS-Studio, we invented such a mechanism. But at first consider a small explanation.
The code analyzer is a program that parsers the source code and shows those fragments that might contain errors. The programmer looks through these messages and decides: either to correct the code (if the error is real) or ignore it (if it is a false alarm). Sometimes the programmer cannot determine if the error is real or not. In this case, he can highlight the corresponding message (Figure 2) and use the PVS-Studio command called What Is It.
Figure 2 - The list of messages generated by the code analyzer
After choosing the command What Is It in the menu, the window is displayed (Figure 3) with the text of the message you can send to the developers.
Figure 3 - The message for developers
This text also contains a fragment of your source code for us to be able to give a detailed and sufficient answer.
We did not automate the mechanism of sending the message deliberately and ask users to copy the text into their mailers. The reason for that is the privacy considerations. Companies very often have restrictions concerning "disclosure" of source code, so the user should understand that he sends a fragment of source code and that it is permitted by the rules accepted in his company.
Answering this question, we try to explain to the user what the problem in his code is and how to fix it. Meanwhile, we can communicate with the user concerning other questions and perhaps get a new customer.
Communication between software developers and users is useful since it allows the former to improve the product's quality and attract new customers. Let's point list possible means once again:
You should understand that choosing particular means of communication with users very much depends upon the class or even segment the application belongs to.