How to gather user feedback before developing an application

End-users should help testing

People underestimate the importance of end-users testing the app and the time that this requires. After all, what could go wrong, right? Well, developers are humans too! So even if they make their best effort to deliver a bug-free app, we guarantee there is still a way to make it malfunction. This is especially the case when the developer does not have any domain knowledge, which makes it extra hard for them to check the results and think of all kinds of unusual but still realistic cases. An experienced domain expert, on the other side, can come up with all kinds of special cases and can identify in a split second that a result is a bit off.

“It’s hard enough to find an error in your code when you’re looking for it; it's even harder when you’ve ASSUMED your code is ERROR-FREE." – Steve McConnell, Author of bestselling software engineering textbooks

Plan testing in advance

Everyone has a busy job. Experience has shown that not making a time-planning and setting deadlines to test the application, leads to people not testing it at all in the end. Testing the app and giving feedback will be low on people’s to-do lists and only happen once they have a good reason to do it. This often reads: In case something really goes wrong. Trust us, you really don’t want to be in that situation, especially close once you get closer to the deadline.

Four reasons to add feedback

Getting feedback regularly really helps improving the application. With rounds of feedback every two weeks, bugs, errors, and other mistakes and/or misunderstandings can be solved quickly. “It’s hard enough to find an error in your code when you’re looking for it; it's even harder when you’ve ASSUMED your code is ERROR-FREE." Steve McConnell Author of bestselling software engineering textbooks 29 Throughout the process, you want to test your application so you can receive feedback on both objective aspects, such as whether the correct answer is presented or not (for example with calculations), and subjective aspects, such as the layout and usability. The benefits of testing are:

Reason 1: Issue prevention

If feedback is given in time, problems later on can be prevented and anticipated. You don’t want to build on loose soil. Otherwise, things can get really ugly. It is crucial to schedule not only the coding sprints, but also the tests and following feedback moments with everyone involved. Such feedback moments are not just 5 minutes of talking but rather take up several hours of testing and reviewing the application thoroughly to add the most value.

Reason 2: User-friendliness

Most times it is clear (but maybe laborious) how you get the right numerical solutions to a problem. However, designing the interface for a good user experience can be a much more complex and abstract task. The layout and usability of an application are subjective aspects and therefore differ from user to user. To get the most optimal results, it is important to gather feedback from as many end-users as you can get. All of this information should then be combined to build the final concept version of what your application is going to look like, tending to the most common and important needs of every user.

Reason 3: Gaining insights

Not only end-users but also developers benefit from this feedback. In sessions with domain experts, developers often gain the best insights into the technical processes that are happening and then come up with creative ways to solve problems!

Reason 4: Making things clear

Additionally, you may find out that a user story appears to be too broad because it is not formulated clearly enough for developers to understand well. During these feedback moments, problems like this can be discussed and anticipated. Now you know your user story needs to be described in more detail, so that the developers have a clear image of where they are headed and what concrete steps, they need to take to get there.

If you start building without having feedback rounds in between, an assumption you made at the beginning may turn out to be wrong in the end. This means you can throw away a lot of code and start all over again. A frustrating and time-consuming way of developing, in our opinion.

“Your most unhappy customers are your greatest source of learning” – Bill Gates

How to give feedback

When giving feedback, try to be as specific as possible. Developers cannot read anyone’s mind and certainly are no domain experts. So, don’t take anything for granted. To make sure feedback is as specific as possible, always take the following aspects into account:

• Who: Developers want to know who provided the feedback so they can reach out to them to find a good solution together. Mention the feedback came from you.
• Location: To which part of the app is this feedback relevant? In the input part of the interface? Or some visualisation? A calculation? The menu? Etc. You could also add a screenshot to clarify it even more.
• Condition: Did you find a bug? Please also report under which conditions this bug happens so it can be reproduced and checked by the developer. For example: I get error X when using input X when toggle button Z is activated.
• Priority: Feedback is good, but too much can be confusing. Please let people know how important this feedback is. For example: not needed – nice to have – should have – must have – urgent to have.
• User story: Can you relate this feedback to a user story of the backlog?

Processing feedback

It is recommended to use an issue board to keep track of all the feedback you have gathered from your end users. In this board, you can indicate which items of feedback already have been processed and which items should still be worked on.

In a small application team, sending feedback directly to the developer seems more convenient than making a whole issue board. However, this isn’t the best practice. The more people that get involved in the application, the more reason why you need to have an issue board to keep track of all the suggestions. Sending the feedback directly via email to the developers creates a lot of extra work for everyone, since that way there is no clear overview of the to-do’s.

Creating an issue board

If you want to keep it simple, you can create an issue board in a worksheet. This sheet contains all the feedback, problems, and other comments that you have gathered up to this point. Also, relevant information such as when the feedback was given, who gave the feedback, an extra description, the priority, and if the feedback has been incorporated and approved.

Here is an example of such an issue board in a worksheet:

If you want to bring it to a more professional level, you can use platforms such as GitHub, GitLab, or others. Here you can make issues for each feedback point, assign them to a developer, classify them, give them labels, and plan when they will be solved (sprint planning). You can also start a discussion on each issue, where you can ask for more input from clients or developers. Additionally, you create a new branch to solve each issue or a collection of them. A branch is a copy of the code on which you can work to solve the issue without affecting the original code. Once you have solved the issue, you can merge the branch with the ‘main code’. This also makes it possible to solve several issues simultaneously with different developers, without breaking the main code.