Well-designed user research is a big succes!

Software development is a complex field and needs a lot of creativity for software developers, which makes it inherently volatile and unpredictable. Put simply, 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 to actually work?

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, 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 you’ll begin 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 and should definitely be harvested before you start with the actual development. However, two things will happen. First, people have a tendency to overestimate their future reactions. For example, if I ask you how you would feel 2 years from now if you would win the lottery today, you would say: ‘fantastic!’ While, sadly, the reality is you won’t be noticeably happier at all.

Secondly, you’ll be forcing people to think about something you’d want them to do automatically. That shouldn’t matter, right? 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 actually use it, conscious experiences are not that helpful.

"Turns out, our brain handles automatic actions very differently than conscious actions."

So, 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, one that I cannot describe fully 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 actually using it, and then develop further. This way you ensure you don’t put too much effort in features that are not relevant yet.

Second, 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 features that are more promising. In the ten years that I’ve been in software development, I have seen more often than not that features that seem hugely important at first, actually reap no benefit at all, while seemingly insignificant features become part of the most valuable set of an application. Changing these prioritizations of course impact the certainty that fixed scope brings, but based on well-structured user research that trade-off will actually 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 do not have to come at the price of losing flexibility. As long as you keep your user right in the centre of it.