The Road to More Successful Digital Products.
It is estimated that 70% of software projects fail due to poor requirements.
When you calculate how much that costs in terms of rework, you have a real challenge on your hands.
The question here is, why does this happen in the first place? Project requirements are supposed to be based on market needs, so where do things go wrong?
The primary reason for failure seems to be that actual customer needs are neglected in favor of product requirements that are thought to be relevant by stakeholders. Businesses focus solely on their goals and objectives and mostly assume that they understand their customers and know their users. The keyword here is: assume.
Successful Products Are Desirable, Viable and Buildable
Product success is not about one single factor, but rather it’s a dynamic balance between three factors, namely: design, business, and technology.
Successful products answer these three questions:
- What do people need? (desirability)
- What will sustain a business? (viability)
- What can we build? (buildability)
Focusing on a single factor and neglecting the rest inevitably leads to product failure. Striking the right balance while placing more emphasis on one approach—be it user needs for example—is possible, as long as your general strategy targets all three.
Take the age-old Microsoft/Apple debate. Microsoft, are definitely achieving business goals left, right, and center, but at the end of the day, their products fall behind in the desirability area. They do the job, but their products are not an object of desire. Apple on the other hand places ultimate focus on desirability and user satisfaction with intuitive, pleasurable products that may compare less on some criteria against Microsoft products.
Practically speaking, there is no perfect product in the real world. It’s all about trade-offs and making the right decisions that line up with business strategies and objectives. Successful product teams operate with the goal of balancing all of these factors without neglecting one of them.
You Are Not the User
A recurring scenario that takes place during kick-off meetings is when the CEO or product stakeholder proclaims: “I want to build an app that does X and helps people do X,” and starts to explain how this solution will help people and can potentially change their lives.
And when you argue “do people really need this feature?” the answer for 90% of the time is “of course they do!” followed by a list of problems and pain points that they suffer from and think all users suffer from too. So what you have here is someone designing a product for themselves. This is actually a scientifically observed phenomenon.
The False-Consensus Effect refers to people’s tendency to assume that others share their beliefs and will behave similarly in a given context. We tend to assume that users will like a certain feature or use a specific flow that we use or need, while the reality could be far from this. People are different, they share different beliefs and values and they have different needs and preferences.
Successful product teams operate with the presupposition that they don’t know anything about their users until they meet them, observe them, and listen to them. Any requirement not based on observed user needs should be treated as an assumption that requires validation.
The Flexibility to Pivot
Did you know that Youtube started out as a video dating site? When their idea didn’t take off as planned, they realized that their users wanted to use the platform differently, so they allowed this desire to point them in the right direction. Would they have come this far had they stayed chained to their original model, preaching how amazing it was and how understood they were as a product team? The answer is a big resounding no.
Adopting a mindset that treats requirements as uncontested facts will make you rigid and stubborn when it comes to exploring ideas. Instead, requirements should be treated as mere assumptions until they are verified. This way you will remain flexible and open to new ideas, alterations in user behavior, and market changes.
Successful product teams are quick to admit the failure of a particular direction and are flexible enough to adapt based on their learnings.
Assumptions Vs. Requirements
Requirements are singular, documented physical or functional needs that a particular design, product, or process aims to satisfy. Assumptions, on the other hand, are believed to be true but require validation.
So as UX designers, do we work with rigid requirements or flexible assumptions?
For a long time, the norm was that designers were sent a long list of product requirements and specifications, which they immediately used to design the solution. However, working with assumptions means the necessity of introducing a stage the precedes design: research. UX research is a truly critical activity that could spell the difference between your product’s success or failure.
The best way to collect assumptions from your clients is through researching their needs in interactive workshops. You can use these workshops to help clients think, talk, and express their opinions about their users, market, and product.
There are several techniques you can use to help your clients express their ideas easily such as brainstorming exercises that help express assumptions about prospective users and competitors. You also need to work with your client on coming up with a unified product vision, as this can sometimes prove challenging for big teams.
What’s Next?
Now that you have a list of assumptions, you need to start doing your research to validate them. Your assumptions may turn out to be wrong, in which case your research will provide the new input for your requirements. Or, if your assumptions were true to begin with, then your research will have helped you learn more about your users, their goals, and their behaviours- providing a solid base for the design phase.
