Events Hub um dos produtos da Sensedia uma empresa de tecnologia líder em solução API.

Contexto

Fui responsável por entregar uma nova versão, redesenho com uma nova proposta de valor, do Events Hub, propondo uma experiência de autoatendimento, abstraindo a complexidade alinhada com indicadores.

Meu papel

Fui contratada para trabalhar na Sensedia na área de Produto como a Designer de Produto da squad Events Hub, meu papel era de redesenhar o Events Hub implementando o processo necessário com técnicas e boas práticas, mitigando riscos da implementação da nova versão e migração de clientes, garantindo que as funcionalidades da versão atual fossem aprimoradas para a nova versão.

Durante meu tempo na squad Events Hub eu mantive presença cross no Chapter de Design e Guilda de Marketing. Com minha experiência e certificação em Design System pude estar na posição de co-frente da criação do Design System da Sensedia.

Meta

O meta era entregar uma nova versão completa do produto Events Hub, propondo uma experiência significativa e de autoatendimento, abstraindo a complexidade e alinhando-a com indicadores, incluindo uma nova funcionalidade primária mapeada pelo negócio.

Roadmap

Quando iniciei no projeto um roadmap já havia sido definido com as fases detalhadas sobre o que deveria ser priorizado e os prazos. 

Exploração (Discovery)

O histórico do Events Hub no âmbito de design era um pouco escasso de materiais e dados. O produto atual não tinha configurado nenhuma plataforma de captura de dados, os arquivos de design não eram nossos (telas, componentes, fluxos e outros), mas tínhamos o protótipo navegável do As Is em Adobe XD, diversas áreas que atuavam próximo do cliente e acesso a plataforma atual.

O discovery foi realizado em duas frentes: design e negócio. De negócio já estava sendo conduzido pelo Product Manager com foco no core da plataforma e a nova proposta de valor, já a de Design eu fui responsável por conduzir com foco em alinhar os indicadores do negócio com a nova experiência. Um board unificado foi criado no Miro.

A condução do processo de descoberta provou ser instrumental para o nosso projeto, permitindo-nos validar e descartar hipóteses, mitigar vieses, melhorar nossa compreensão da proposta de valor, obter uma perspectiva mais clara sobre a colaboração com outras equipes, como consultoria, vendas e outros squads.

Pesquisa (Entrevistas, Surveys, Análise de Dados)

O EVH (Events Hub) tem uma característica bem interessante que refletia no seu redesenho. O EVH faz parte de um ecossistema de produtos SaaS e para propor uma experiência de autoatendimento abstraindo a complexidade, era necessário olhar para o todo, então busquei entender como que o EVH foi criado e rapidamente descobri que as páginas, componentes e estrutura utilizada no EVH pertencia a definições criadas para o produto líder do portfólio da empresa que utilizava da biblioteca Sensedia UI.

Logo me deparei com o desafio de redesenhar o produto e manter a coesão com os demais produtos, para que a entrega fosse bem-sucedida alinhamos, nós PDs e a Design Lead, sobre como mudanças que eram realizadas nos produtos que atendiam a alguns critérios precisavam ser levadas para o Chapter de Design.

Com o foco de criar a experiência de autoatendimento, abstraindo a complexidade, eu precisava entender como os usuários / clientes atuais usavam a plataforma, entendendo que suas necessidades, dores e preferências. Nesse aspecto coletei dados utilizando diversas técnicas em alinhamento com o Product Manager, primeiro inicie com os dados que estavam disponíveis e posteriormente houve a necessidade de implementar meios que nos permitisse tomar decisões de forma mais informada, baseada em dados.

Dados Quantitativos 

• User IQ (novo)
• Google Analytics (novo)
• Relatórios de performance

Dados Qualitativos

• Entrevistas com usuários/clientes
• Testes de usuário (novo)
• Pesquisas NPS
• Hotjar (novo)
• Alinhamento com consultores, sucesso do cliente e vendas 

Benchmarking

Como benchmarking, que foi realizado pelo Product Manager com apoio da Design Lead, estava avançando quando entrei no projeto, eu decidi criar uma matriz CSD (Certezas, Suposições, Dúvidas) para usar como ferramenta para conduzir e orientar os processos que precisavam ser realizados. A matriz serviu como um guia estratégico para priorizar atividades e esclarecer o foco das investigações e ações em conjunto com o time.

Matriz CSD

O benchmarking de produto, uma análise que engloba tanto a UX quanto a UI, apesar de ocorrer depois do benchmarking de negócio, executei com o mesmo objetivo, mas avaliando e comparando aspectos da experiência do usuário e visuais da interface, funcionalidades, de serviços concorrentes e líderes de mercado.

Para este processo foi importante lembrar que eu estava olhando para soluções complexas e extremamente técnicas, então fiz questão de procurar avaliações, feedbacks, reclamações e criticas dos usuários e clientes de concorrentes e líderes de mercado.

Ideação e Prototipagem

Problem Statement

Os usuários frequentemente recorrem ao suporte para expressar insatisfação com a usabilidade da plataforma, destacando sua dificuldade em localizar recursos essenciais.

Isso representa um desafio significativo, pois os clientes têm mais probabilidade de cancelar seu contrato (risco de rotatividade | churn), quando não têm confiança em sua capacidade de gerenciar efetivamente seus negócios usando a plataforma e não estão cientes de seu total potencial. Além disso, nossa incapacidade de mostrar efetivamente os recursos abrangentes de gerenciamento de eventos integrados à Plataforma API agrava esse problema.

Personas

Planejamento:

• Pesquisa por formulário
• Análise das respostas
• Análise de competidores
• Estudo de padrões
• Identificar fatores comuns

Duas personas foram criadas para agrupar dois perfis de usuários, que posteriormente se tornaram uma que representa o principal grupo-alvo, pois foi concluído qual perfil utilizava mais o produto e tinha relação mais próxima com a estratégia que estava sendo desenhada para a nova versão do EVH. Essas personas foram desenvolvidas com base em dados de clientes e pesquisa de mercado, nos levando um passo mais perto de entender as necessidades, desejos e comportamentos de nossos clientes-alvo.

Ao longo do processo de descoberta, as personas desempenharam um papel crucial. Elas serviram como referência, combinadas com dados, para elaborar o Value Proposition Canvas, mapear a Jornada do Usuário, gerar hipóteses, tomar novas decisões e outros.

Essas ferramentas nos permitiram tomar decisões mais informadas, garantindo que nosso produto seja centrado no usuário desde o início.

Diagrama de funcionalidades

Além do diagrama de funcionalidades que trazia detalhadamente as capacidades do sistema, mostrando como diferentes funcionalidades se relacionam, também foi disponibilizado diversas documentações de arquitetura, diagramas de contexto e user cases.

User flow & Tasks Flows

Uma vez que estava mais claro as funcionalidades do produto conforme o diagrama de funcionalidades e as documentações foram analisadas, foi possível avançar com o userflow que foi mapeado para comportar fluxos que seriam mantidos do usuário do produto atual. Para complementar mapeei os task flows de etapas específicas necessárias para completar uma única tarefa dentro do produto com base nos fluxos. 

Jornada do usuário

Segui para a jornada do usuário visando a identificação de momentos-chave, pontos de dor e oportunidades de encantamento. Através do estudo da jornada foi possível ter um entendimento mais holístico sobre a contribuição de áreas como sucesso do cliente, vendas, suporte e consultoria, também no sentido da pós venda sobre a documentação e como ela precisava ser construída de forma coesa com o redesenho (EVH 2.0).

Sitemap

Inicialmente criei o sitemap através da plataforma Mindmeister e posteriormente transferindo para o Miro.

Depois de detalhar o user flow para garantir que a navegação do usuário seja lógica e intuitiva, o sitemap veio para definir a estrutura de navegação, detalhando as páginas e suas funcionalidades, além de ajudar a identificar redundâncias e integrações no ecossistema da empresa.

Wireframes

Nesse projeto tivemos wireframes em algumas etapas, wireframes das páginas principais e wireframes dos fluxos, ambos em baixa fidelidade. Os wireframes passavam por uma análise, ajustes e só apenas quando aprovados eram evoluídos para protótipos ou versões em alta fidelidade, em alguns casos os wireframes passavam por um refinamento completo.

Conforme desenvolvia e analisava os wireframes, no meu design board eu registrava meus entendimentos, dúvidas e hipóteses:

• Product Goal
• Product Vision 
• É Não é faz não faz
• Matriz moscow
• Insights
• Hipoteses
• Dados do Events Hub As Is

Com essas informações em mãos eu levava para reuniões diárias com o Product Manager , Product Owner e Tech Lead, em alguns casos chegávamos ao entendimento de que era necessário refinar regras de negócio, requisitos ou funcionalidades , e então quando necessário realizávamos brainstorm convidando especialistas como profissionais de arquitetura de software, analistas de qualidade, front-end e Back-end.

Protótipo

Estrategicamente alinhamos de priorizar a entrega e implementação em alta da funcionalidade core, que estávamos construindo do zero, em um novo prazo. Eu precisava finalizar o desenho da experiência, testar, validar e realizar o handoff do fluxo da funcionalidade core para o desenvolvimento, mas para tornar isso possível considerando o prazo da entrega das demais partes do produto minha abordagem foi:

• Desenhar a estrutura base conforme definições do Chapter;
  • A estrutura consistia em : novo logo, novas cores, topo, hierarquia do menu, rodapé, interações, componentes básicos e outros;
• Finalizar o protótipo do fluxo do usuário em média fidelidade;
• Alinhar com a Product Owner e Tech Lead para solicitar a equipe de desenvolvedores a busca de componente que tornaria possível a nossa proposta de valor;

Teste de usuário

Realizei o teste de usuário do protótipo em média fidelidade com alguns voluntários da empresa, enquanto aguardávamos clientes voluntários, alguns dos participantes consistiam em pessoas do time e que estavam alinhados ao o perfil da nossa persona. Com apoio das áreas que tem o contato direto com os clientes conseguimos clientes voluntários e posteriormente também conseguimos voluntários através do evento Apix.

Roteiro de teste

• Objetivo
• Instruções / Introdução
• Perguntas
• Classificação
• Finalização

Primeira rodada de teste foi feita em média fidelidade com o user flow (To Be) completo com o caminho principal de cada página com suas principais ações que já estava sendo criada.

Dos testes em baixa fidelidade especificamente um que foi realizado com um grupo de usuários tivemos resultados e feedbacks muito interessante. Em destaque aprendemos uma dificuldade acentuada no uso botões que eram padrão em toda empresa, então logo registramos esse feedback e levamos para o Chapter de Design que resultou em uma mudança geral no Design System do qual pude estar a frente de seu desenvolvimento.

Aprendizado: O botão com ícone de disquete além de não ser reconhecido como opção de salvar por diferentes faixa etárias, também não foi aprovado quanto a sua interação, que neste caso era um tinha um comportamento de botão flutuante e que em algumas páginas expandia em mais botões.

Componente core

Para que a equipe de desenvolvimento pudesse buscar um componente que atendesse a funcionalidade core, com base nos testes eu pude levantar quais comportamentos, ações, interações eram necessárias para atender nossos usuários e evoluirmos para sua versão final (da primeira entrega).

A Product Owner também acrescentou e disponibilizou para o time de desenvolvimento a regras de negócio. O time de QA também participou de diversas fases do processo de desenho e realizamos alinhamentos para 

Documentação do usuário (cliente)

Para manter uma documentação coesa, procurei a Tech Writer do time para entender melhor sobre o seu fluxo de trabalho e ela se colocou a disposição para que em conjunto pudéssemos padronizar os textos e nomenclaturas.

Implementação (Entrega)

Não conseguimos executar uma rodada de teste com a versão em alta da funcionalidade core, mas disponibilizamos um protótipo em alta no evento Apix para colher feedbacks de clientes e clientes em potencial. Como resultados tivemos bons feedbacks, clientes curiosos e interessados em ver a versão 2.0 a todo vapor e follow ups para realizar.

Vale destacar que a funcionalidade core e os novos tokens do Design System foram entregue antes do prazo \o/

Handoff

Antes do handoff de design ser passado para equipe de desenvolvimento, através do Product Board e do Jira, a versão de entrega foi validada tecnicamente pelo time de desenvolvimento, aprovada pelo Product Manager e apresentada para a squad e área de produto da empresa.

O handoff consistia em uma documentação escrita com o que foi alinhado com o time sobre a versão aprovada da solução e informações pertinentes para que a implementação fosse um sucesso, protótipos, fluxos, telas, componentes definidos e links úteis. 

Também foi criado uma documentação no Confluence da squad e do time de design.

Quando funcionalidade core entrou em desenvolvimento, além de acompanhar o andamento através das atualizações da tarefa de desenvolvimento, tive a oportunidade de testar partes da entrega e a entrega como um todo enquanto atuava nas minhas próximas entregas.

Triple Diamond

À medida que o processo de design amadurecia, percebemos que estávamos operando algo semelhante ao Triple Diamond, pois era o que fazia mais sentido para o momento do produto. 

Nosso entendimento era que o framework do Triple Diamond estava alinhado com o andamento do projeto, que no caso do EVH 2.0 o processo foi adaptado para permitir que a implementação ocorresse em fases, mas com base em uma exploração e ideação que considerou o produto como um todo. Isso garantia que cada parte que fosse implementada já havia sido validada dentro do contexto do produto completo.

Usando o Triple Diamond como framework nos permitia revisitar etapas anteriores. Isso nos garantia que o processo de design fosse dinâmico às descobertas e necessidades que surgem ao longo do projeto, resultando em soluções mais robustas e bem adaptadas ao contexto real.

Referência

Why the double diamond isn’t enough – https://uxdesign.cc/why-the-double-diamond-isnt-enough-adaa48a8aec1