Does UX Research make sense in a Go-to-market strategy?

To include design methodologies in a release process can create opportunities and reduce unnecessary costs

by Carlahaydee and Larissa Tramontin, from Sensorama’s Design team

The areas of Service Design, Product Design, User Experience and the like are often seen superficially within organizations. Generally, the most thought out concepts are taken for appearance and aesthetics. However, Design is much more than that. It means understanding the needs of everyone involved: the company’s business area, the customers/users who will use that service or product, the existing market and market trends. In addition, it may involve several other areas of the company, such as customer service or even technology (assuming the intention is to build a web platform, for example).

Design consultancies, such as Sensorama Design, are often called upon to validate and optimize Go-to-market strategies (such as launching a new product/service on the market) for an idea already conceived by the company that hired us. But in this case our proposition is to take a few steps back and think about some fundamental questions: if the customer already analyzed the reason why the product needs to be developed, what problems it aims to solve, what needs it meets and what will improve from a business point of view, taking into consideration the organization’s future vision.

But what does a Go-to-market strategy have to do with UX research?

Everything.

We will explain these concepts to you through a project that is still in development. So for now we are not going to bring the outcome, but an opening to the possibilities in a scenario like this. We were asked to perform a usability test on an MVP that was divided into 2 web platforms (B2B): an e-commerce and a portal that would manage customer data (both e-commerce customers and those who purchase other products which are not yet marketed online).

Design Thinking: a journey from idea to validation

Contextualizing for those who are still new to design processes, testing is one of the last steps. Testing means that something was built and a path was taken to get to it, right? In other words, within a methodological process (such as Design Thinking) it is necessary to understand the business, the present strategies and future plans, the real needs of the users and everything else that involves the problem. The next step is to interpret the findings and define what will be done to solve the problem at hand. Then, it is time to ideate and effectively execute what was planned. Finally, these solutions need to be tested to identify possible adaptations, improvements, changes, among others. All of these steps do not have to be linear throughout a project and you may need to re-understand, re-define, re-execute and re-validate.

Now, back to the case of our project. At first, one can think: it must be a good idea to go ahead and perform a usability test. This means that the customers’ pains have been identified, the strategies have been determined, and the business knows everything that really needs to be in the product. It is also understood that the product has already been defined with an initial base of use flow and information architecture and the expected results for the business and the customer are already known. However, this is not always the case.

What happened in the case at hand is that when we started the conversation with the stakeholders and saw the interfaces for the first time, we found out that the websites (which were already online and being accessed by a minimum number of customers) had been developed by different teams, within different design agencies, with no research history nor information architecture, in addition to already having 2 disconnected backlogs.

In other words: we were asked to perform a usability test on a product that might not be meeting the real needs of the user, but rather the perceptions of the business.

Immediately, we noticed many improvements that could be made from the point of view of usability. We could do heuristic analysis, usability tests with the use of precise and quantitative tools, questionnaires, among many other methodologies that would bring improvements to the product. But would we be working for the end user or just fulfilling our customer’s request?

That’s when we started our challenge and, talking to the project’s stakeholders, we agreed that we needed to know more. We held a workshop with other areas of the company, which had a broader perception of users and we realized that it was necessary to go back a few steps so that something much more important for the business, for the end user and for the success of the product could be made. We then proposed changing the scope of the project.

Instead of carrying out a usability test to validate features that might not even need to be considered, it was necessary to understand points such as:

• What would be the functionality of that product?
• What tasks would the user actually perform?
• What other platforms did the user already use?
• What were the biggest difficulties that the users face on their journey (and which ones could be solved by a portal)?
• What content should each feature have?
• What was the development priority for each feature in the portal?

Considering the complexity of the product, in addition to this process, we proposed a market analysis through desk research and benchmarking so that we could understand what other market inputs we might have in order to design a product that could be more adherent, in a general context, and different from those competing portals.

Based on the consolidation of these data, we will present the prioritization of user needs, which will be assessed with the stakeholder thinking about the company’s strategies and even what the development area will be able to produce. Once the MVP has been adapted with the improvements and a new strategy drawn up consistently by the business, it will be the time to finally carry out a usability test.

What did we learn?

There is no problem in going back and retracing a project. On the contrary. It is a great opportunity to reduce unnecessary costs, avoid rework and actually meet the expectations of final users and the company.

Of course, we had an understanding customer, who valued our opinion and accepted the challenge. But with this we demonstrate that the areas of service design, product design and UX must be considered important strategic components within an organization.

Wait for updates! Maybe in another moment, we will be able to show more details of this project that Sensorama Design had the pleasure of contributing and to inspire business areas!

*Este artigo também está disponível em português, acesse aqui para conferir. :)