User research is a key foundation for software projects. Software development is a complex field and needs a lot of creativity for software developers. This makes it inherently volatile and unpredictable. It often happens that what you think would work doesn’t work. And what you think is impossible is actually quite possible. So, how can you get the assurance that you are looking for but maintain the flexibility needed for software development actually to work?
User research is key for software projects.
We see that the biggest success factor in this regard is well-designed user research. The thing with user research is that users act a lot like humans, with complex emotions and all. And there are a couple (well, actually quite a lot!) of psychological effects you need to take into account.
For example, before thinking about your digital product, you’d want to target potential users. And ask them what they’d like and what they won’t like. Of course, this is enormously valuable information. Consequently, it should be harvested before you start with the actual development. However, two things will happen. First, people tend to overestimate their future reactions. For example, if I ask you how you would feel two years from now if you won the lottery today, you would say: ‘fantastic!’ While, sadly, you won’t be noticeably happier.
User research is needed to validate assumptions.
Secondly, you’ll force people to think about something you’d want them to do automatically. That shouldn’t matter. Turns out our brain handles automatic actions very differently than conscious actions. So for an application that wants to lower the threshold for users to use it, conscious experiences are not that helpful.
What’s needed is solid user research. That is to say, you’ll need to validate the assumptions with your potential users. This leads to the art of MVP-ing, creating a minimal viable product to show to your users. You’ll then see if they hate or love it as much as they thought they would. It’s a bit like Henry Ford said:
So, what is the art of MVP-ing? It’s a subtle art that I cannot fully describe here. But with two-pointers, you can come a long way. First, I believe most have seen this picture.
What this picture tries to convey is this: build the most simple version of your end product in mind, with a focus on your most valuable feature. So if it is an app for farmers to diagnose crop diseases, first build the diagnosis of the diseases. Everything else is dependent on the diagnosis functionality working correctly. So test that first with users using it, and then develop further. This way, you ensure you don’t put too much effort into features that are not relevant yet.
Use it to rearrange priorities continuously
Always keep change in mind. Of course, it is good to start with a fixed scope. But be prepared to prioritize and divert resources to more promising features. I’ve been in software development for over ten years. During that time, I have seen more often than not that features that seem hugely important at first actually reap no benefit at all.
Meanwhile, seemingly insignificant features become part of the most valuable set of an application. Changing this prioritization, of course, impacts the certainty that fixed scope brings. But based on well-structured user research, that trade-off will lead to more certainty concerning the actual usage of the product.
So with proper user research and mastering the art of MVP-ing, our clients succeed in getting what they want exactly for what they paid for. Fixing parameters does not have to come at the price of losing flexibility. As long as you keep your user right in the centre of it.
