UX/UI Strategic Design for SaaS

Em SaaS, a venda não termina na assinatura. Ela recomeça todo mês.

Produto vendido uma vez pode se dar ao luxo de ser difícil no começo. SaaS não: o cliente reavalia a decisão a cada ciclo de cobrança, e quem não chegou ao valor prometido nas primeiras semanas cancela muitas vezes sem nunca ter reclamado.

É por isso que design de SaaS é diferente de design de aplicação. O trabalho não é só reduzir fricção de ecrã; é encurtar o caminho entre entrar no produto e ter o primeiro resultado concreto, e depois tornar visível o que a pessoa ainda não está a usar e que justificaria pagar mais.

Os três momentos que decidem a receita

Cada um puxa uma métrica diferente, e tratá-los como o mesmo problema é o erro mais comum.

• Ativação. O caminho da conta criada até o primeiro resultado real. Não é o tour da interface: é a pessoa conseguir fazer, no seu produto, a coisa que a fez assinar. Quanto mais longe esse momento, maior o cancelamento no primeiro ciclo.
• Retenção. O produto entrando na rotina. Envolve o que aparece no ecrã inicial, quando o produto avisa algo e principalmente quando ele fica quieto. Notificação em excesso é causa de churn, não remédio.
• Expansão. Tornar visível o recurso do plano superior no momento em que ele resolveria um problema que a pessoa está a ter. Expansão bem desenhada parece ajuda; mal desenhada parece cobrança.

Arquitetura da informação

É a camada que mais pesa em SaaS e a que menos aparece numa avaliação superficial.

• Modelo mental do utilizador. Como as pessoas organizam o trabalho delas que quase nunca é como o banco de dados organiza. Interface que espelha a estrutura interna do sistema obriga o cliente a aprender a sua engenharia.
• Navegação que aguenta crescer. O menu que funciona com doze funcionalidades e quebra com quarenta. Vale desenhar para o produto que vem, não só para o de hoje.
• Permissões e equipas. Quem vê e quem edita o quê. Em SaaS de contrato empresarial, isso deixa de ser detalhe técnico e vira requisito de compra.
• Estados de carregamento, erro e vazio. O ecrã vazia do primeiro dia é a mais importante do produto e a mais negligenciada: é ela que ensina o que fazer em seguida.

O que fica com você no fim

• O sistema de design. Componentizado e documentado, desenhado para escalar com o produto.
• O mapa dos fluxos críticos. Ativação, uso recorrente e expansão, com o comportamento especificado.
• A especificação de handoff. Pronta para o desenvolvimento implementar sem interpretar.
• As métricas de partida. Registadas antes da mudança, para o ganho ser comparável depois.

Como conduzimos

Começamos pelos dados de produto que você já tem: onde as contas param na ativação, quais recursos a base usa e quais nunca foram abertos, e o que os cancelamentos têm em comum. Esse levantamento define a prioridade. A entrega acontece em ciclos curtos, começando pelo fluxo que puxa a métrica de maior valor no seu momento normalmente ativação, porque ela é a que mais rápido aparece na receita.

Como medimos o resultado

As métricas são de receita, não de ecrã: tempo até o primeiro resultado, taxa de ativação, churn no primeiro ciclo e receita de expansão dentro da base. Registamos o ponto de partida antes de mexer em qualquer coisa.