Why understanding the business is part of a successful user-centered 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.
Everybody is talking about user research but there is another part of research which often gets overlooked: business/stakeholder research meaning the understanding of the business, its organizational goals and – important – 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.
This means that we should never start a project without understanding the business, the product and what it is meant to 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 and this is why:
People, who want us to jump directly into sketches and wireframes are actually telling us that they are not interested in a product design strategy. But design strategy is important 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 behavior 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 are 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, 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 with 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 his/her own 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 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 absolutely 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 actually first fully understand the problem we are trying to solve. This is done by understanding the business and the challenges the business is facing by an initial discovery and research phase because only then chances are very high that we get things right the first time.
Image credit http://baronius.deviantart.com/art/Business-Cat-Vector-343479770
