UX Research faz sentido em uma estratégia de Go-to-market?

Incluir metodologias de design em um processo de lançamento pode gerar oportunidades e diminuir custos desnecessários

por Carlahaydee e Larissa Tramontin, do time da Sensorama Design

Áreas de Design de Serviços, Product Design, User Experience e afins muitas vezes são vistas de forma superficial dentro das organizações. Geralmente, os conceitos mais pensados são levados para a aparência e estética. Entretanto, Design é muito mais que isso. É entender as necessidades de todos os envolvidos: a área de negócios da empresa, os clientes/usuários que vão utilizar aquele serviço ou produto, o mercado já existente e as tendências de mercado. Além disso, pode envolver várias outras áreas da empresa como o atendimento ou até mesmo a tecnologia (supondo que se pretenda a construção de uma plataforma web, por exemplo).

Consultorias de design, como a Sensorama, frequentemente são chamadas para validação e otimização de estratégias de Go-to-market (como lançar um novo produto/serviço no mercado) de uma ideia já concebida pelo cliente. Mas aqui a proposta é dar alguns passos atrás e pensar algumas questões fundamentais: se o cliente analisou o motivo pelo qual o produto precisa ser desenvolvido, quais problemas ele visa resolver, a quais necessidades atende e o que vai melhorar do ponto de vista de negócio, tendo em conta a visão de futuro da organização.

Mas o que uma estratégia de Go-to-market tem a ver com UX research?

Tudo.

Vamos te explicar esses conceitos através de um projeto que ainda está em desenvolvimento. Então não vamos trazer o desfecho, por enquanto, mas sim uma abertura às possibilidades de um cenário como esse. Fomos chamados para realizar um teste de usabilidade em um MVP que foi dividido em 2 plataformas web (B2B): um e-commerce e um portal que faria a gestão de dados dos clientes (tanto do e-commerce quanto daqueles que adquirem outros produtos — que ainda não são comercializados de forma online).

Design Thinking: um percurso da ideia até a validação

Contextualizando para quem ainda é iniciante em processos de design, o teste é um dos últimos passos. Realizamos um teste quando algo foi construído e um caminho foi percorrido para chegar até ele, não é mesmo? Ou seja, dentro de um processo metodológico, como o Design Thinking, é necessário que se tenha entendido o negócio, as estratégias presentes e futuras, as necessidades dos clientes e tudo mais que envolve o tema. O próximo passo é interpretar as descobertas e definir o que será feito para resolver o problema em questão. Em seguida, é hora de idear e efetivamente executar o que foi planejado. Finalmente, essas soluções precisam ser testadas para identificação de possíveis adaptações, melhorias, mudanças, entre outros. Todas essas etapas não precisam ser lineares ao longo de um projeto e é possível que você precise voltar a entender, definir, realizar e validar.

Agora, voltemos ao caso do nosso projeto. Em um primeiro momento pode-se pensar: deve ser muito bom fazer um teste de usabilidade. Isso significa que as dores dos clientes foram identificadas, as estratégias foram feitas, o negócio sabe tudo que de fato precisa ter no produto. Entende-se também que o produto já foi definido com uma base inicial de fluxo de utilização e arquitetura da informação e já se conhecem os resultados esperados para o negócio e o cliente. Entretanto, nem sempre é assim.

O que ocorreu no caso em questão é que, quando iniciamos a conversa com os stakeholders e vimos as interfaces pela primeira vez, descobrimos que os portais (que já estavam no ar e sendo acessados por um número mínimo de clientes) haviam sido desenvolvidos por times diferentes, com agências de design diferentes, sem histórico de pesquisa e arquitetura da informação, além de já estarem com 2 backlogs desconexos.

Ou seja: nos solicitaram um teste de usabilidade em um produto que talvez não estivesse atendendo as necessidades reais do usuário, e sim as percepções do negócio.

Imediatamente, percebemos muitas melhorias que poderiam ser feitas do ponto de vista de usabilidade. Poderíamos fazer análises heurísticas, testes de usabilidade com a utilização de ferramentas precisas e quantitativas, questionários, entre muitas outras metodologias que trariam melhorias no produto. Mas estaríamos trabalhando pelo usuário final ou apenas atendendo o pedido do nosso cliente?

Foi aí que iniciamos nosso desafio e, conversando com os stakeholders do projeto, alinhamos que precisávamos saber mais. Realizamos um workshop com outras áreas da empresa, que tinham uma percepção mais ampla dos usuários e percebemos que era necessário voltar um pouquinho para trás para que fosse feito algo muito mais importante para o negócio, para o cliente e para o sucesso do produto. Propusemos, então, uma mudança no escopo do projeto.

Em vez de realizar um teste para validar funcionalidades que talvez nem precisassem ser consideradas, era necessário entender pontos como:

• Qual seria a finalidade daquele produto?
• Quais tarefas o usuário realmente iria realizar?
• Quais outras plataformas o usuário já utilizava?
• Quais as maiores dificuldades que o usuário enfrentava na jornada (e quais poderiam vir a ser resolvidas por um portal)?
• Qual conteúdo cada funcionalidade deveria ter?
• Qual a prioridade de desenvolvimento de cada funcionalidade no portal?

Considerando a complexidade do produto, além desse processo, propusemos uma análise de mercado através de um desk research e um benchmarking para que se pudesse entender quais outros inputs mercadológicos teríamos para conceber um produto que fosse mais aderente, em um contexto geral, e diferente dos portais concorrentes.

A partir da consolidação desses dados, vamos apresentar a priorização das necessidades dos usuários, que serão avaliadas junto ao stakeholder pensando nas estratégias da empresa e até mesmo no que a área de desenvolvimento conseguirá produzir. Feita a adaptação do MVP às melhorias e nova estratégia traçada pelo negócio de forma consistente, será hora de finalmente realizarmos um teste de usabilidade.

O que aprendemos?

Não existe problema algum em voltar atrás e rever um projeto. Pelo contrário. É uma grande oportunidade para diminuir custos desnecessários, evitar retrabalho e atender de fato as expectativas dos clientes e da organização.

É claro, tivemos um cliente compreensivo, que valorizou nossa opinião e aceitou o desafio. Mas com isso demonstramos que as áreas de design de serviços, produtos e UX devem sim ser consideradas como componentes estratégicos importantes dentro de uma organização.

Aguardem notícias! Quem sabe em um outro momento conseguiremos mostrar mais detalhes desse super projeto que a Senso teve o prazer de contribuir e inspirar áreas de negócios!

*This article is also available in English. Follow this link and check it out. :)