Being a software developer can be difficult. Especially when you’re part of a small team writing internal software. You’re also the de facto support for the software you build. So when a user has a problem with the software, you’re often in direct contact with that user. You have to find out the nature of the problem. And whether that problem is within the software or with the expectations of the user. Or if there even is a problem.
What are problems?
A problem is going to have three basic components. You need to know what the user did, what was expected, and what actually happened. Anything less than all three of these and you don’t have enough information to work. It’s also a mistake that this information will come in formally. Sometimes it’s as simple as a user saying, “When I click on Foo , it florbles when I thought it should fleeble”. What did the user do? Clicked on Foo. What did they expect? Fleeble. What happened? Florble. You can check the logic of Foo and tell the user, “Foo is currently wired to florble, to fleeble, you need to click on Bar.”
Compare that to “Foo didn’t work”. Ok. So without investigating any further, we go test Foo. We look through the code. We see that clicking it causes things to florble. We test it out and it florbles as expected. So we go back to the user and say “Foo works fine on our end”. Then the user is satisfied until they try to Foo again. They come back and say “It’s still not working”. Eventually, after some back and forth, someone is going to let slip that Foo is florbling. And then we will finally discover the real problem, that the user expects Foo to fleeble.
It’s important to lead users to this path as soon as possible. Before looking at anything, make sure you understand what’s being asked. The sooner you have the three components, the sooner the problem will be solved.