Aprenda com erros de UX e design.

Finalmente atingimos a marca de 500.000 usuários em Tampãoum produto que ajuda você a compartilhar em suas redes sociais com mais eficiência. Cerca de dois anos atrás, quando iniciamos nosso caminho para construir o Buffer, sabíamos que encontraríamos obstáculos e cometeríamos erros ao longo do caminho. Uma das principais coisas que temos em mente é que cometer erros é inevitável e que, se decidirmos aprender com eles, eles serão úteis para nos dar uma boa orientação sobre como avançar de forma mais eficaz. E acredito que foi em parte por causa desses erros que conseguimos chegar onde estamos hoje.

A experiência que moldou a forma como construímos nosso produto

Antes de discutir as maiores lições que aprendemos com alguns de nossos erros de UX e design, quero falar sobre um de nossos principais princípios de desenvolvimento de produto:

“Validar primeiro, código mais tarde”

Deixe-me contar como isso aconteceu. Quando surgiu a ideia do Buffer para construir uma maneira mais inteligente de postar no Twitter e outras redes sociais, nosso fundador Joel Gascoigne imediatamente começou a codificar em vez de primeiro validar sua ideia (que é como ele costumava abordar as coisas). Após alguns minutos de sessão de codificação, ele percebeu que esse não era o caminho a seguir. Então ele tentou outra coisa. O que ele fez foi colocar uma landing page como se seu produto já existisse, mesmo ainda não tendo finalizado tudo. Ele então foi em frente e divulgou o link de seu site no Twitter. As pessoas cujo interesse fosse despertado clicariam em um botão na página de destino para se inscrever em uma conta. Eles foram então apresentados a outra página da web que dizia que o Buffer ainda não estava concluído e pedia ao usuário interessado que deixasse seu endereço de e-mail para que pudesse receber um e-mail assim que o Buffer fosse lançado. Essa estratégia funcionou muito bem e conseguimos nosso primeiro cliente pagante dentro 7 semanas para ter a ideia. Três princípios-chave de desenvolvimento de produtos foram criados a partir desta experiência:

1. Mantenha a primeira versão de um recurso ou produto o mais mínima possível.
2. Esteja preparado para uma longa jornada com muitos redirecionamentos de curso.
3. Transforme qualquer ideia de recurso em uma hipótese que primeiro precisa de validação do usuário.

Agora que você conhece um pouco sobre nossos princípios de desenvolvimento de produtos, as lições que aprendemos a seguir farão um pouco mais de sentido.

Lição 1: Os fluxos de usuários devem se concentrar na retenção, não na receita

Uma lição importante (UX) que descobrimos logo no início foi que precisávamos nos concentrar em mantendo nossos clientes em vez de gerando receita. A experiência do usuário é vital porque tem impacto direto na reputação. Foi assim que aprendemos esta lição. O fluxo de usuários da nossa landing page inicial foi o seguinte:

1. Quando você vir nossa página inicial pela primeira vez e clicar no botão de inscrição, mostraremos uma página de “planos de assinatura e preços”.
2. A partir daí, você deverá escolher o plano “Gratuito” ou um de nossos planos pagos.
3. Depois de escolher o plano certo para você, você poderá se inscrever fornecendo seus dados (por exemplo, seu nome, endereço de e-mail e assim por diante).

Com esse fluxo de usuários, o índice de pessoas que escolhem um dos planos pagos no momento da assinatura é alto, o que nos permite gerar receita desde o início. No entanto, aprendemos rapidamente que os usuários que optaram por pagar pelo produto antes de terem a chance de usá-lo aumentaram nossa taxa de rotatividade. Por que isso aconteceu? Descobrimos que as pessoas pagavam, mas nem sequer começavam a usar o Buffer e, eventualmente, cancelavam a assinatura. Por isso, mudamos nosso fluxo de inscrição de usuários e nossa filosofia de aquisição de usuários. Decidimos dizer a nós mesmos: “Vamos fazer com que a pessoa comece a usar o produto primeiro, para que possa experimentar em primeira mão o valor do nosso produto, o que, esperamos, irá encorajá-la a atualizar para um dos planos de assinatura pagos”. Isso funcionou muito melhor para nós. Como resultado, o fluxo do usuário em nosso site é incrivelmente mais contínuo agora: Como resultado dessa reformulação do fluxo de usuários, duas coisas importantes aconteceram:

1. Mais pessoas se inscreveram porque não diluímos o funil com uma página de preços como intersticial.
2. Mais pessoas atualizaram ao longo do tempo porque eles começaram a realmente usar o produto, encontrar valor nele e ficar conosco.

Desde então, fizemos muitas outras alterações no produto que oferecem mais recursos gratuitos, e nossos principais recursos do produto ainda são gratuitos. Somente depois de termos certeza de que você realmente obteve muito valor no uso do Buffer é que o encorajaremos a atualizar para um plano pago. Criar fluxos de usuários com foco na retenção de usuários foi uma descoberta importante para nós.

Lição 2: O login social é melhor do que o login por e-mail

Depois de dezenas de testes A/B fracassados ​​para melhorar as taxas de conversão de nossa landing page, tivemos a ideia de habilitar login social (ou seja, inscrevendo-se em uma conta Buffer e fazendo login usando sua conta do Twitter, Facebook ou LinkedIn). Afinal, o Buffer serve para postar no Twitter, Facebook e LinkedIn, então parecia lógico que nossos usuários em potencial pudessem se inscrever de forma rápida e conveniente usando uma de suas contas existentes. Para fins comparativos, abaixo está nossa página inicial que permite que você se inscreva com seu e-mail e uma senha: Nossa mudança do login por e-mail para login social é um dos nossos maiores hacks de crescimento, permitindo-nos eventualmente aumentar as inscrições em 50%. E na época dessa mudança de login, passamos de 500 inscrições diárias para 800 inscrições diárias praticamente durante a noite.

Lição 3: Teste todas as suas suposições antecipadamente

Deixe-me contar uma história sobre como falhamos miseravelmente com uma nova ideia de redesenho de extensão do navegador. Uma das partes essenciais do Buffer é nossa extensão do navegador para Chrome, Firefox e todos os outros navegadores principais. Sabemos que se você for usuário e usar a extensão, terá a melhor experiência com o produto. Compartilhar a partir de qualquer página da web e adicionar facilmente tudo ao seu “buffer” para compartilhar no Twitter, Facebook e LinkedIn emergiu como o caso de uso mais poderoso. Por isso, foi natural que nos concentrássemos neste elemento do produto e tentássemos o nosso melhor para o melhorar, pois tínhamos claramente algumas ideias sobre como o poderíamos melhorar. Mas quando começamos a produção de uma extensão de navegador melhor, parecia que voltamos aos nossos velhos hábitos e cometemos os mesmos erros que sabíamos que deveríamos evitar. Aqui está a sequência de como nós (incorretamente) abordou a construção de nossa nova extensão:

1. Identificamos alguns problemas com nossa extensão de navegador existente e então discutimos o que queríamos mudar.
2. Gastamos muito tempo e recursos para projetar e desenvolver uma primeira versão totalmente funcional.
3. Testamos a primeira versão no final do processo e percebemos que as pessoas estavam ficando extremamente confusas ao usá-la.
4. Descartamos a nova ideia e nunca a lançamos.

Este foi o novo layout da extensão do navegador que nunca colocamos em produção: Adquirindo o hábito de testando cada suposição que você tem o mais cedo possível é algo que agora está gravado profundamente em nossos cérebros desde aquele fracasso. Para consertar as coisas, é assim que abordamos a construção de novos produtos e recursos:

1. Identifique problemas com o produto existente e pense no que você pode querer mudar.
2. Converse com os usuários sobre se eles realmente têm os mesmos problemas.
3. Depois de validá-lo em uma discussão com nossos usuários, construa rapidamente wireframes ou um protótipo simples que não leve mais do que 1-2 dias para ser produzido.
4. Fale novamente com os usuários e veja como eles interagem com seu protótipo.
5. Itere ainda mais para um recurso/produto utilizável que você possa mostrar a mais usuários.
6. Acompanhe as métricas de engajamento/crescimento/receita e converse novamente com os usuários sobre sua experiência.

Lição 4: Seja claro com os rótulos da interface do usuário

A última lição que quero compartilhar com vocês é algo em que venho pensando há algum tempo: é a questão de ser claro com seus rótulos, botões, texto de ajuda, etc. em vez de ser esperto com eles. Des Traynor da Intercom definiu esse problema incrivelmente bem em um artigo:

Situação: você criou um ótimo recurso que resolve um problema real que você sabe que seus usuários têm. Eles não estão usando isso. Geralmente é porque não viram, ou viram e não sabiam o que fazia.

Essa situação é algo que continuamos a enfrentar. O exemplo principal que gostaria de descrever aqui é o seguinte: Dentro do Buffer, você pode conectar várias contas sociais para poder postar em todas elas de um único local, por exemplo, você se inscreve ou faz login com sua conta do Twitter, mas também deseja conectar sua conta do Facebook e LinkedIn ao Buffer para facilitar a postagem de um lugar. O que costumava ser era isto: Pensamos que ter um ícone de sinal de “mais” (+) inteligente indicaria às pessoas que essa é a maneira de adicionar suas outras contas de redes sociais. Mesmo assim, recebemos repetidamente e-mails de nossos usuários perguntando se havia uma maneira de conectar suas contas do Facebook ou LinkedIn no Buffer. Então o que fizemos foi alterar vários aspectos do botão “conectar”, tornando-o um ícone de espaço reservado, usando um sinal de mais maior e muitos outros ajustes de design. Qual foi a solução de design final? A solução foi simples: usar o texto “conectar mais contas” em palavras simples e escritas, o que é muito mais claro e eficaz do que ter (o que pensávamos ser) um ícone inteligentemente concebido para representar essa tarefa da interface do usuário. Aprendemos que escolher o claro solução ao longo do esperto A solução – mesmo que a primeira possa não ser tão bonita, única ou legal – é sempre a melhor para o usuário.

Conclusão: tudo é uma hipótese que precisa ser validada

Acreditamos que nossa empresa e nosso aplicativo ainda estão em seus estágios iniciais, portanto, muitos dos processos e métodos de design que temos ainda são muito experimentais. O conceito de não estar apegado a uma única ideia e tratar cada iteração de design ou recurso como uma hipótese que precisa de validação é a maior coisa que aprendemos. A experiência do usuário é vital em setores como golfe e restaurantes, porque as pessoas precisam poder usar seu site com facilidade ou simplesmente irão para outro lugar. É por isso que os testes são tão vitais. Planejamos construir muitos outros recursos que as pessoas irão adorar. E também esperamos construir muitos mais que teremos de deitar fora. Acreditamos que esta forma de pensar nos dará o maior potencial para construir algo que nossos usuários realmente desejam.

Conteúdo relacionado