Product Discovery Framework: o Design Centrado no Usuário como estratégia
Como gerar um ciclo de qualidade e engajamento na equipe de produto, tecnologia, comercial e CS, colocando UX Strategy na prática?
Em 2018 eu recebi um desafio que se transformou em um grande aprendizado contínuo e que gerou um framework, onde agreguei vários desses aprendizados e boas práticas no processo de discovery. Esse framework já foi apresentado no TDC (BH e POA, 2019) e com os feedbacks fui evoluindo cada vez mais.
Um breve histórico
Desde que iniciei na vida profissional (na época era analista de sistemas), sempre tive a preocupação de entender cenários e identificar os participantes. Depois de entender o cenário, ai sim eu ia analisar as necessidades e bater com os requisitos solicitados pelo cliente. Isso fez com que os projetos fossem mais enxutos e com uma aceitação boa pelos envolvidos.
No processo de evolução e aprendizado contínuo, passei pelas áreas de marketing, publicidade, comunicação e design. Isso trouxe uma visão maior sobre o que os stakeholders e suas aspirações acerca de um projeto.
Quando iniciei no projeto que atenderia a construção civil (2018), me deparei com um cenário totalmente desconhecido por mim, onde não conhecia os termos técnicos da área, os fluxos e nem o cenário de tecnologia envolvida.
O grande diferencial para que tudo acontecesse foi ter um time coeso e uma gestão que acreditava nos profissionais envolvidos. Isso faz total diferença, pois quando você confia que o P.O sabe o que está fazendo, o Designer tem controle sobre seus métodos e que os Devs têm a expertise de resolver o que se propõem, o fluxo de trabalho sempre vai a favor do melhor resultado possível para todos os envolvidos.
No momento ZERO nos reunimos para entender o cronograma do projeto e as expectativas do nosso cliente primário (a empresa que nos contratou 😎). Nesses encontros nós colocamos na mesa os métodos, recursos e ferramentas necessárias e as disponíveis. Foi daí que iniciou a criação do framework que vou detalhar abaixo.
O Product Discovery Framework
Depois foi que me liguei que ia acabar tendo a sigla de PDF, o que eu poderia inventar uma historinha feliz para falar sobre adaptação e blablabla… Mas foi coincidência mesmo 😒
Tudo parte de um grande problema, sendo que ele deve ser grande o suficiente para demandar um discovery e pequeno o suficiente para não se tratar de um produto completo. Assim, vamos passando pelas etapas de Entendimento, Definições, Protótipo e Documentação.
A semelhança com outras metodologias, técnicas, métodos e frameworks não é mera coincidência. São várias técnicas emprestadas de diversas formas de guiar um processo criativo como Design Thinking, Sprint, métodos do Spotify e engenharia de software.
Big Problem (BG)
Esse é o início de tudo e o que deveria guiar os profissionais envolvidos, buscando validar ou invalidar as hipóteses de negócio, fluxo de trabalho e usabilidade que permeiam o tema.
O recorte do BG é bem conhecido pelos engenheiros como escopo do projeto, sendo realmente um recorte e não o problema geral de todo o projeto. Isso porque temos, por definição, que nesse framework o PM, PO, Lead (ou seja lá quem coordena as análises de negócio) já possui dados e indícios de mercado que sustentem a necessidade de trabalhar no tema.
Para exemplificar como delimitar o BG:
Errado: Existe algum problema em gerenciar o financeiro de uma pequena empresa?
Certo: Como ajudar no registro de contas e fluxo de caixa de uma pequena empresa.
Certo: Quais os passo essenciais e um fluxo otimizado para gerenciar a contratação de serviços.
Errado: Existem empresas que precisam da gestão de saldo em compras?
Certo: Qual o perfil e o fluxo de trabalho das empresas que controlam saldo de compras? Existem, em nossa base de clientes, esse perfil?
Know and Learning (Aprendizado)
Essa é a etapa inicial, onde reúne-se TODAS as informações possíveis sobre o escopo do BG. Aqui vale usar conhecimento interno e é primordial ter uma exploração de cenário com stakeholders, clientes e especialistas na área estudada.
Algumas das formas que usamos para essa etapa é a Pergunta aos Especialistas. Nesse momento estressamos o assunto com alguém de mercado que entenda sobre o escopo do projeto, trazendo uma visão geral dos fluxos, necessidades e ferramentas já utilizadas para trabalhar naquele problema.
Como o objetivo aqui é aprender, é bom ter uma forma de documentar que todos consigam revisitar depois e lembrar do que foi aprendido. Além de servir de base para novos participantes do projeto.
Em nosso projeto eu já utilizei várias formas, desde planilhas, Doc em Word, Mapa mental, Mapeamento de Fluxo (BPMN), vídeospowerpointnt… enfim, o melhor método de armazenar é aquele que você conseguir apresentar aos participantes do projeto e que todos consigam entender. Já fiz fluxo de telas + processo para documentar as descobertas, assim como também já utilizei apenas um Board no Power BI para discutir sobre os indícios do discovery.
A saída esperada nesse momento é o estresse do assunto, então para isso vale fazer grupo focal, visita a clientes, roteiro de entrevista, pesquisa quantitativa, análise de BI, etc. O final dessa fase você deve ser capaz de responder as principais dúvidas da gestão sobre as principais descobertas que sustentam o desenvolvimento daquelas features e qual é a forma atual do seu cliente resolver esse problema.
Define (Definição ou Refinamento)
Quando já se entendeu sobre o cenário e já possuímos os indícios dos problemas desse fluxo de trabalho, chegou a hora de alinhamento entre a estratégia do produto, a gestão do projeto e o time técnico.
Nesse momento é importante estabelecer uma agenda de alinhamento, setando as expectativas logo no início do discovery. Até porque envolver os outros times no processo de discovery não é algo fácil e natural, porém necessário para ter apoio e a visão complementar que, lá na frente, vai fazer toda a diferença porque você já vai ter adiantado as discussões de viabilidade técnica, critérios de sucesso e entrega de valor esperado para vendas.
Aqui os resultados da etapa Learning são apresentados para o PM, alinhando se as descobertas dão um “Go” ou não para o BP. Também são setadas as prioridades para as hipóteses vindas da etapa inicial de discovery, sendo as que vão para a etapa de protótipo e testes.
O alinhamento com o time de tecnologia trará insights sobre formas de abordar o problema, abrindo para possibilidades e deixando claro as dificuldades envolvidas. Esse alinhamento com o time de tecnologia também tará uma aproximação, fazendo com que os Devs sejam parte da solução e não apenas jogando o problema no colo deles no final do discovery (waterfall).
Em um outro momento posto métodos e dinâmicas de alinhamento com os diferentes times em torno de um projeto de produto.
Prototype (Protótipo ou Criação)
Quando falo de protótipo, aqui, não é estritamente um desenho feito em ferramenta de design (Figma, Sketch, etc) e sim sobre simulação da ideação. Isso significa que simulações em planilha de Excel, recortes de papel, desenho à mão livre ou apenas uma simulação de entrega de serviço é parte dessa etapa de prototipação.
Guiado pelas explicações feitas em Design Thinking, por Tim Brown, podemos expandir o que se conhece em design digital por protótipo. Podemos até chamar de MVP, se estivermos falando de algum produto de baixa complexidade, como um PDF ou um sistema de cadastro. Em resumo, consideramos aqui válida qualquer simulação que atinja o objetivo final da tarefa do usuário: cadastrar um item, consultar uma informação, enviar uma mensagem, contratar um serviço e etc.
Nessa etapa de simulação é importante envolver a equipe técnica pois as ideias são concretizadas aqui, assim sendo é um momento de “ver” como a coisa seria na prática. Desenhe/rabisque as ideias, crie planilhas, prototipe em ferramentas de design ou apenas utilize um Google Forms, desde que ao final dessa sessão os participantes tenham algo para testar a ideia.
Uma observação importante aqui é que tudo precisa ser com baixo custo de implementação, necessite de pouca instrução para quem vai testar (público-alvo / grupo de controle) e que, provavelmente, tanto poderá ser modificada para ser expandida durante os feedbacks quanto poderá ser descartada ao final da fase de testes. Então, a dica aqui é não se apegar a ideia e tentar deixar com todos os detalhes de alta fidelidade, pois pode ser que a simulação seja invalidada e você perdeu tempo prototipando onde deveria investir testando.
Documentation (documentação final ou de entrega)
Durante todas as etapas de um discovery você está gerando — ou deveria estar — documentação de pesquisa, sendo factível de resumo para entrega no delivery. Pois aqui é o momento de fazer isso e um pouco mais.
A fase de documentação é entendida nesse framework como um momento de compilação e arquivamento das decisões do produto. Isso significa que os entregáveis aqui devem ir além dos protótipos feitos, expandindo para informações de CS, critérios de aceite e regras de tecnologia envolvida.
Saídas esperadas:
- Critérios de aceite (PO);
- Job to be Done das personas envolvidas (PO e PD);
- Critérios de sucesso (CS);
- Regras de negócio (PO);
- Regras de interface e protótipos digitais para inspeção(PD); e
- Tecnologias envolvidas (Tech).
A forma de reunir essa documentação é que gera bastante discussão, pois cada time e cada empresa pode ter ferramentas diferentes e estar adaptadas a essa. Porém, o bom e velho Powerpoint, Excel e um Doc de Word cumprem bem o papel. Isso não significa que um Trello, Asana ou outro software de documentação de tarefas não possa fazer as vezes de documentação também.
A preocupação aqui é mais com o alinhamento do time sobre as definições do produto após o discovery, não com o texto ou com a ferramenta que está armazenando essas informações — embora seja necessário se preocupar com a busca dessas informações futuramente.
Conclusão
Esse é um formato criado através de aplicação, erro, feedback e ajustes. Está em constante evolução e você também pode dar sua colaboração, comentando sobre as informações aqui.
A preocupação de criar um framework foi para delimitar uma agenda de tarefas e dar visibilidade ao processo do Product Designer e os stakeholders do projeto. O trabalho do designer aqui é coordenar a participação desses stakeholders, monitorar o desempenho do projeto e documentar de uma forma que seja útil para os envolvidos e para si, futuramente.
Cada etapa não é isolada e fechada em um método, porém tem um objetivo: Aprender, Definir, Experimentar e Documentar. Podendo voltar para a etapa anterior ou recomeçar todo o ciclo, no caso de necessidade de mais informações e definições.
