Design de Produto na Resultados Digitais

Publicado por Rodrigo Quaresma no dia agile, design

A Resultados Digitais é a empresa que desenvolve o RD Station, uma ferramenta web-based de Marketing Digital que, durante os últimos dois anos, saltou de 80 para 1600 clientes e de 15 funcionários para mais de 100. Durante esses dois anos em que acompanhei o crescimento da empresa e do produto, aplicamos e testamos diversas maneiras de desenvolver novas funcionalidades.

Kanban da área de produtos da Resultados Digitais

A lista de tópicos abaixo não é uma receita de bolo, mas o compartilhamento de nossas experiências. São 11 etapas que resumem o processo que utilizamos na construção das grandes funcionalidades do RD Station lançadas em 2014. O processo, que está em constante evolução, nos ajudou muito na fase inicial de crescimento acelerado. O objetivo das etapas a seguir - que fazem parte do nosso Kanban de Produto - é trazer a visão do designer dentro do ciclo completo de desenvolvimento de novas features.

Sandbox

De forma bastante simples: qualquer ideia pode se tornar um projeto para a área de produto e o lugar onde guardamos essas ideias é o que chamamos de Sandbox. Feedback de clientes, tickets no suporte, conversas de corredor, estratégias de mercado, seminários internos e externos - todos esses acontecimentos são excelentes geradores de ideias.

Backlog de Projetos

A cada trimestre, a empresa inteira promove um alinhamento de prioridades que define os KPIs (Indicador Chave de Desempenho) de todas as áreas a curto e médio prazo. São estes indicadores que ajudam a definir quais projetos serão puxados do Sandbox para o Backlog além de definir a prioridade de cada um.

Estudo do problema

Antes de pensar qualquer solução, buscamos primeiro entender o problema real enfrentado pelo nosso usuário. Mais importante que criar hipóteses da nossa cabeça, é validá-las com nossa base. É quando entramos em contato com os clientes em suas diferentes personas e validamos se estamos todos falando do mesmo problema.

Estudo de benchmarking

Somos uma Startup Lean, é algo que está no nosso DNA (e Culture Code também!). Por isso, procuramos quais produtos ou serviços já passaram pelo mesmo problema. Não queremos - e nem temos tempo para - reinventar a roda. Buscamos descobrir como essas empresas solucionaram o problema que estamos enfrentando e, durante a investigação, evitamos presumir se a solução encontrada de fora é boa ou ruim. No benchmarking, o importante é colher diferentes perspectivas. Novamente podemos entrar em contato com alguns clientes e descobrir como eles estão tratando o mesmo tópico.

Proposta da solução

Problema identificado e benchmarking feito: é hora de montar uma proposta de solução. As alternativas levantadas no estudo de benchmarking são úteis - mas nenhuma delas resolverá de forma satisfatória o problema do nosso cliente/usuário. São apenas referências.

Nesta fase, eu, enquanto designer, começo com um esboço da solução e, a partir dela, realizo uma série de testes para entender se esta proposta consegue resolver de forma consistente o problema levantado. Um ponto importante aqui é não se contentar com os primeiros resultados, mesmo que eles já tenham sido satisfatórios. Dessa forma, estamos sempre buscando a excelência naquilo que nos propomos a fazer. Somente após analisar diversas abordagens da solução eu avanço para algo mais estruturado e apresento novamente aos stakeholders.

Uma técnica que venho treinando é evitar a utilização de slides durante esse tipo de apresentação. Se eu realmente entender o problema e a solução em que estou trabalhando, não precisarei de slides. Tudo o que eu preciso já tenho dentro da cabeça (uso no máximo um quadro branco). Os dados que não são importantes serão esquecidos contudo, aqueles que realmente importam, estarão intactos na memória e serão lembrados quando requisitados. Tenho consciência que essa dinâmica só é possível em poucas empresas e/ou projetos. Mesmo assim, treinar apresentações sem slides pode valer a pena em qualquer situação.

Outro ponto muito importante nessa “conversa” com os stakeholders é escutar com bastante atenção seus feedbacks. Estamos em um ponto no qual a solução ainda pode mudar de rumo radicalmente sem grandes custos ao projeto. Assim como no estudo do problema, a proposta de solução também deve ser bem compreendida por todos - não podem restar dúvidas quanto ao conceito. Esta é a hora que todos compram a mesma ideia.

É também nesta fase que estabelecemos, de forma mais precisa, as metas que a solução, após implementada, deve atingir. Alguns exemplos dessas métricas de sucesso: aumentar o número de acessos em 3%, aumentar o engajamento em 10%, atingir 0.95 no Apdex, diminuir tickets no suporte, etc.

MVP

A fase de MVP é quando precisamos de pistas concretas para identificar se nossa hipótese está no caminho certo. A ideia dele é desenhar uma solução rápida, aplicá-la e entender se ela tem potencial para sucesso. Para essa validação não é preciso desenvolver o produto da forma tradicional e completa. Podemos testar algumas hipóteses menores utilizando pesquisas com os usuários/clientes, extrair números de uso ou engajamento do produto, pesquisar outros produtos (concorrentes), etc.

Descobrir se as métricas de sucesso serão atendidas é o que pode definir o “go / no go” da solução - e até mesmo do projeto. Até este ponto, ele pode ser facilmente abortado. Alguns fatores podem colocar a proposta em standby ou mudar radicalmente o rumo do projeto. Entre eles estão a coleta de resultados não esperados e mudanças de prioridades da área.

Desenvolvimento: design

Neste ponto começamos a visualizar os conceitos das etapas anteriores. No início, utilizo o lápis e papel para desenhar a marcação de alguns pontos que serão úteis mais adiante e o flow de uso da nova funcionalidade. O lápis e papel não avançam para além disso. No caso do RD Station, já temos um framework robusto de HTML, CSS e JS instalado no produto - o que facilita em muito a criação de protótipos em HTML de forma rápida. Vou aprofundar esse assunto em um próximo post.

Mesmo sendo designer, avançar nos estudos de front-end trouxe uma série de vantagens para a etapa de desenho das interações. Prototipando em HTML, é possível executar alguns testes da interface ainda com a proposta em desenvolvimento. O processo é iniciado pelo próprio designer testando o flow da funcionalidade. Depois, chama-se outros designers, desenvolvedores, colegas de outras áreas da empresa ou até mesmo amigos e parentes. No caso da Resultados Digitais, ainda temos os clientes internos que estão disponíveis para testes a qualquer momento. Quando necessário, ainda recrutamos alguns clientes e testamos remotamente (utilizando o Skype).

A ordem nesse estágio é experimentar e testar diversas abordagens até estarmos seguros para avançar no desenvolvimento.

Desenvolvimento: código

A presença de um desenvolvedor é importante em todas as etapas, mas é nesta fase que ele vai ter uma participação mais ativa. É na integração com o software que as engrenagens começam a rodar e os verdadeiros problemas aparecem.

É possível - e até provável - que algumas alterações no design de interação sejam necessárias. É quando você percebe que o esforço para discutir o problema e a solução fazem a diferença, pois serão esses argumentos que manterão a evolução do desenvolvimento no rumo certo. O perigo é acabar focando em problemas de interface e esquecer o verdadeiro problema do cliente.

Mais uma vez, o conhecimento de front-end se torna uma vantagem, pois é possível que o designer efetue as alterações diretamente no código. Isso torna o processo bastante ágil e evita o engessamento na solução dos erros. Além de garantir a qualidade visual daquilo que foi planejado.

Alpha

No alpha, além de assistirmos à usuários reais utilizando os novos recursos, testamos o lançamento da feature e como será feita sua comunicação. Essa não é a versão final do projeto e geralmente é lançada na reta final de desenvolvimento.

Para o design, o principal objetivo do alpha é testar uma solução e colher feedbacks. Nesta etapa, selecionamos uma amostra de clientes e liberamos um versão preliminar da nova funcionalidade. É quando conseguimos lapidar o produto com maior precisão e ainda há a possibilidade de executar alterações sem grandes prejuízos ao planejamento do projeto.

Lançamento

Um dos grandes segredos da fase de lançamento é ter o critério de sucesso da nova funcionalidade em mente. Alguns exemplos desses critérios são: melhorar os números de vendas, aumentar o ticket médio dos clientes da base ou diminuir o número de cancelamentos. E o lançamento tem que ter estratégias e ações claras para atingir estes critérios. Engajar e Ativar os clientes é uma causa para consequentemente e ativamente atingir o objetivo do projeto.

Resultados

Voltando ao início do projeto, lembramos que nossa busca era solucionar um problema. Para isso, desenvolvemos uma solução com a expectativa de atingir determinadas métricas. É na fase de resultados que avaliamos o sucesso - ou não - da proposta. Independente se o resultado esperado foi atingido, este é o momento em que aprendemos e efetivamente melhoramos nossos processos e repertórios.

Sandbox (de novo)

Muitas vezes, os resultados do projeto que acabou recentemente já começam a abastecer nossa Sandbox e, consequentemente, nosso Backlog.

Como escrevi anteriormente, tudo isso é um processo em evolução e que nos serviu muito bem enquanto o time e nossa base de clientes cresciam de forma acelerada. É bem provável que durante os próximos desafios da Resultados Digitais, esse processo volte a sofrer adaptações para continuar ágil e evitando desperdícios de esforço do time.

Por último, gostaria de reforçar dois pontos que foram bastante repetidos em quase todas as etapas e que servem para melhorar até mesmo o próprio processo:

  1. Teste de forma constante e consistente. Sempre.
  2. Colha feedbacks. Sempre.

Rodrigo Quaresma

Rodrigo Quaresma

Designer

Comentários