Why understanding the business is part of a successful user-centred design concept.
Einstein once said:
„If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
You can apply this quote 1:1 to user experience work. While everybody is talking about user research, there is one area of the research often overlooked: business/stakeholder research meaning the understanding of the business, its organizational goals and – most importantly – even its internal politics.
Even though our job title “user experience designer” implies that we are advocates for the end users, our principal job is to help our customers achieve their business goals.
Meaning we should never start a project without understanding the business, the product and what it should accomplish. We achieve this through business/stakeholder research, which can be done during the same project phase as user research.
When we are hired as a user experience design studio we are often asked to jump straight into production work like sketching and wireframing and to quickly hand over some solutions and deliverables.
We are not very comfortable with this approach, this is why:
People, who want us to jump directly into sketches and wireframes are telling us that they are not interested in design strategy. But design strategy is key because it can help define an action plan, which is the basis for UX work with an impact. What they are interested in is interface design. Interface design should not be confused with user experience design. Of course, we can jump right into the process of defining interaction behaviour and placing UI elements based on knowledge and best practices – but this is not going to solve any individual problems & challenges the business or product is facing.
As user experience designers we consider our roles to first be about understanding the business/organizational goals as well as the user groups so we can clearly articulate the underlying problem. Only then – once the business is understood and problems are identified and articulated – we can work on solutions for the end user. This process can also help to get everyone on the team on the same page and to create a shared understanding of possible solutions, which is another important aspect of successful instead of blue-sky designs.
If we start the project by creating solutions by creating conceptual models – such as wireframes – chances are high that we will fail and not get the best solution, simply because in most cases the problem is not fully understood, not clearly defined and everybody in the team has a subjective understanding of the problem. Next step: endless discussions and iterations of the design are guaranteed.
This is why every project should best begin with an understanding of what the product should accomplish and what business goals it will/should serve.
We strongly believe that fully understanding the business and articulating and defining problems firsthand is essential and only after the business is understood and the problem is articulated we can start with the actual problem-solving process.
While this might all sound logical, it is often requested that we skip this step with the argument to save costs. But this is a fallacy!
The less expensive way is to fully understand the problem we are trying to solve. This is done by understanding the business and the challenges the business is facing through an initial discovery and research phase because only then chances are very high that we get things right the first time.
