Processo de Design | Real Case

Criando uma solução digital do zero com abordagem MVP

Foto de Towfiqu barbhuiya em Unsplash

O que é MVP

Quem não é da área de produtos ou de design pode estranhar esta sigla, mas ela significa o mínimo produto viável (do inglês Minimum Viable Product), ou seja um conjunto de funcionalidades que atendem minimamente a uma necessidade; a razão de ser do MVP é disponibilidade rápida às pessoas usuárias para validação durante o uso, permitindo coleta de resultados reais, rápido aprendizado para equipes e evolução mais assertiva do produto.

Outros termos que serão abordados podem ser consultados neste breve Glossário 🤓

Considerações

• Por se tratar de uma solução real, para preservar a empresa e o produto, alguns dados foram omitidos, nomes modificados e alguns elementos visuais adaptados especialmente para divulgação deste artigo;
• O termo artefatos está sendo utilizado para se referir de forma genérica a diversos tipos de documentos e imagens virtuais;
• Este artigo tem por intenção apenas mostrar meu processo de design.

O desafio

Nesta experiência trabalhei lado a lado com o product owner (PO), e a nós foi lançado o desafio de criar uma solução nova, com escopo totalmente diferente do portfólio da organização em que atuamos — uma empresa de produtos B2B para fornecimento de dados — a partir de ideias e convicções de stakeholders de negócios. A demanda veio definida como:

Uma forma para organizar artefatos gerados pelas pessoas usuárias nos diversos aplicativos que compõem a plataforma da empresa.

O objetivo

Além de organizar artefatos, o objetivo da solução seria aumentar o engajamento na plataforma e integrar os aplicativos para que as pessoas visualizassem e acessassem os artefatos em um único local.

O processo de design

Como de costume, para uma apresentação didática do processo, eu o dividi em etapas: Entender, Definir, Desenhar, Validar e Desenvolver, mas considere que na prática as etapas se misturam e se complementam. Além disso, mesmo que o foco neste artigo seja o design, observe que tarefas também se misturam e como designer acho importante participar de trocas e definições estratégicas juntamente com PO e com a squad de desenvolvimento.

1. Entender

Participei apoiando o PO na sessão de kickoff com stakeholders, que no caso foram lideranças das áreas: tecnologia, produtos, marketing, sucesso de cliente, vendas e o próprio CEO. Nesta sessão o PO e eu recebemos o desafio e tiramos nossas dúvidas sobre a demanda do ponto de vista de expectativas de stakeholders, informações sobre solicitações de clientes e de pessoas usuárias que foram recebidas através de canais próprios e sobre histórico dos aplicativos da plataforma.

Em uma segunda sessão com stakeholders, facilitei a dinâmica “é, não é, faz, não faz” para que pudessem chegar a um consenso de visão da solução e juntos delinear com mais clareza a demanda e seus objetivos.

Quadro da dinâmica “é, não é, faz, não faz” utilizada para se obter uma visão de produto ou de solução, de forma colaborativa.

Como resultado desta etapa, foi obtida a seguinte visão:

A solução deverá ser um histórico indexado dos artefatos gerados em toda a plataforma de aplicativos, promovendo um fácil acesso a esses artefatos que serão organizados cronologicamente.

Ou seja, a ideia é que ao acessar uma lista os artefatos e cada item será um link para visualização rápida e/ou para acessar no aplicativo de origem do artefato.

2. Definir

Com todas as informações coletadas nas sessões anteriores juntamente ao objetivo de negócio, PO e eu começamos a:

• alimentar nossa Matriz CSD — expliquei mais sobre esta ferramenta neste artigo;

Matriz CSD

• definir um escopo inicial sem descartar ideias — costumo adotar um “estacionamento” para elas , falo disso no Glossário;
• desenhar um planejamento que, na parte de Design, incluiria não somente rabiscos e protótipos, mas principalmente entrevistas com pessoas clientes e usuárias da plataforma — uma vez que a demanda partiu de stakeholders precisamos ouvir as necessidades de quem está diariamente em contato com os produtos e serviços, como diria Don Norman “Você [designer] não é a pessoa usuária.”

Recorte do planejamento

3. Desenhar

Paralelamente à etapa “Definir”, pesquisei referências em soluções que tivessem a ver com nosso escopo inicial mesmo que em outras áreas de conhecimento ou de mercado: gestão de documentos (GED), produtos de armazenamento como Google Drive…

Semanalmente tínhamos uma sessão de acompanhamento com stakeholders onde o PO e eu apresentávamos nossas evoluções. Da minha parte, mostrei até mesmo rabiscos iniciais (alguns feitos à mão).

Quadro de rabiscos e ideias

E, assim, fui idealizando o protótipo; como já trabalho de forma a padronizar e organizar elementos de interface no Figma (atualmente minha ferramenta favorita de prototipação) em pouco tempo consegui fazer um protótipo navegável; nesta etapa do trabalho foi importante ter bastante flexibilidade de ideias mas também argumentar com stakeholders a importância de uma validação com as pessoas usuárias.

Protótipo idealizado

4. Validar

A validação junto a pessoas usuárias foi feita remotamente via Google Meet, o recrutamento se deu com auxílio do PO via e-mail; para guiar as conversas com as pessoas usuárias, defini um breve roteiro e disponibilizei o protótipo navegável e considerei os seguintes objetivos:

• Descobrir a área de atuação da pessoa;
• Entender o fluxo de trabalho — como a pessoa utiliza a plataforma, quais os principais aplicativos, demandas por gerar e revisitar artefatos, sazonalidade dessas demandas;
• Analisar a interação com o protótipo — facilidade em encontrar e usar funcionalidades como busca, filtros, lista de resultados, distribuição cronológica…
• Coletar impressões gerais e validar a hipótese principal: “a solução resolve uma necessidade real das pessoas usuárias?”

O PO me auxiliou anotando pontos interessantes — a fim de facilitar as anotações e posterior tabulação destas conversas, criei uma tabela contendo as perguntas ideais e objetivos.

Recorte da tabela para anotações

Nesta parte da validação obtivemos 12 entrevistas, das quais os principais insights e suas respectivas oportunidades de negócio que identificamos foram:

• as pessoas salvam os artefatos da plataforma em seus próprios repositórios/ dispositivos — espaço e armazenamento;
• muitas vezes, ao invés de apenas revisitar esses dados já salvos, as pessoas geravam novos artefatos para comparação — notificar/ sugerir atualização por período pré definido;
• as pessoas geram artefatos por aplicativos e também fontes diferentes — acompanhamento por dashboard;
• a informação visual agrega valor para as pessoas devido à rapidez e praticidade ao consultar algum artefato no histórico — permitir visualização rápida ou de resumo de deixar as funcionalidades abrir/ fazer download do artefato inteiro como opcionais.

Ainda na etapa de validação gostaria de citar a sessão de Análise Heurística feita juntamente com a equipe de designers; esta sessão teve como objetivo refinar o protótipo do MVP e garantir padronização visual de acordo com: aplicativos que cada designer era responsável, melhorias e a plataforma como um todo.

5. Desenvolver

Decisões de design devem estar aliadas às possibilidades técnicas e por isso, o PO e eu fizemos sessões de viabilidade junto à squad de desenvolvimento. Eu poderia ter colocado esta parte na validação, mas dela surgem mais adaptações e re-priorização de itens de MVP do que efetivamente um corte no escopo — o que pode ocorrer em validações com pessoas usuárias quando a solução não condiz com desejos e necessidades, de nada adianta um produto super inovador se ninguém vai utilizar.

Sobre a priorização de itens de MVP, o PO fez de acordo com resultados obtidos das validações de Design. Isso foi possível pois todas as etapas acabam gerando algum entregável que serve de apoio e de documentação.

Falando em documentação, nesta etapa criei e apresentei todo o arquivo de design específico e facilitado para o handoff* à equipe de desenvolvimento.

Demonstração de parte do arquivo para handoff

*Sei que atualmente o próprio Figma lançou uma funcionalidade que propõe o handoff mais fluido para times de desenvolvimento. Sugiro aderir a forma que funciona em sua equipe; à época funcionou desta forma apresentada aqui ;)

Próximos passos

Por se tratar de uma solução com abordagem MVP, alguns insights obtidos e até mesmo funcionalidades definidas no processo acabam ficando para outro momento — o que é normal.

E para não perder de vista é interessante que esses insights estejam acessíveis seja em um “estacionamento de ideias”, em um radar, ou até mesmo dividir em ondas para validação e/ou de desenvolvimento de funcionalidades pois a evolução já é uma expectativa inerente ao MVP.

Confira abaixo alguns itens que cheguei a desenhar em protótipo mas não foram contemplados no MVP:

E algumas ideias e insights que ficaram para outro momento da solução:

• Exportar artefatos sem precisar acessar o aplicativo de origem;
• Configurar tempo de validade de artefatos;
• Notificações para a pessoa usuária poder atualizar um artefato quando este estiver obsoleto;
• Possibilitar à pessoa usuária armazenar e gerenciar os próprios artefatos e não somente os links .

Bom, minha participação se deu até aqui. Até a próxima!