OdiN Docs:

Visão geral do produto

O OdiN Docs é um sistema de gestão e assinatura de documentos projetado para os setores de RH e Financeiro de médias e grandes empresas. Este projeto de redesign não foi motivado por estética, mas por uma crise de eficiência: a interface legada havia se tornado o maior gargalo operacional da OdiNetwork, sobrecarregando o time de atendimento com chamados de suporte para tarefas triviais.

O discovery e o sintoma do negócio

A diretoria enfrentava uma dificuldade crônica em escalar o suporte ao cliente. O volume de chamados de nível 1 (dúvidas básicas) era insustentável. Usuários não conseguiam executar atividades primárias, como criar pastas, armazenar arquivos ou preparar o terreno para integrações futuras. A hipótese inicial era clara: a complexidade desnecessária da interface estava custando caro para a empresa.

Pesquisa qualitativa e diagnóstico

Para entender a raiz do problema, conduzi entrevistas em profundidade com os profissionais de RH e Financeiro que utilizavam a ferramenta diariamente. O diagnóstico de UX revelou três falhas estruturais graves:

• A arquitetura do caos: A taxonomia e a nomenclatura dos menus não conversavam com o modelo mental do mundo corporativo.
• Carga cognitiva extrema: O momento mais sensível do sistema — a assinatura de um documento — gerava insegurança e paralisia no usuário.
• O fenômeno do "workaround" (gambiarra): O atrito para enviar documentos era tão alto que os usuários criavam pastas locais em seus computadores para organizar tudo externamente, utilizando o sistema apenas no último segundo. O software falhava em seu propósito central de gestão.

A metodologia: desconstruindo o caos operacional

Para resolver um problema de escala Enterprise, a intuição foi substituída por um rigoroso processo de pesquisa de métodos mistos (Mixed Methods), dividido em 10 etapas fundamentais de diagnóstico, síntese e validação.

1. Alinhamento de negócios

O ponto de partida não foi a interface, mas a dor do negócio. Entrevistas conduzidas com a diretoria revelaram que o suporte técnico dedicava cerca de 40% de sua capacidade operacional apenas para resolver dúvidas de "Nível 1" (como criação de pastas e envio básico de contratos).

"Nosso suporte está apagando incêndios de navegação ao invés de resolver problemas técnicos." — Stakeholder/Diretoria.

2. Auditoria de Dados (Web Analytics)

Para quantificar o problema relatado pela diretoria, mergulhei nos logs de uso do sistema. Os dados revelaram uma taxa de abandono (drop-off rate) de 68% no meio do fluxo de envio de documentos. Os usuários iniciavam o processo, mas a complexidade os impedia de concluir a tarefa.

3. Avaliação Heurística

Antes de conversar com os usuários, realizei uma auditoria técnica baseada nas 10 Heurísticas de Jakob Nielsen. Identifiquei 24 violações de usabilidade no sistema legado, sendo a mais crítica a falta de "Visibilidade do Status do Sistema": os usuários enviavam lotes de contratos e o sistema não retornava nenhum feedback visual de sucesso.

4. Observação contextual (shadowing)

Acompanhei silenciosamente a rotina de profissionais de RH operando o sistema. Esta etapa revelou o fenômeno do "Workaround" (Gambiarra): o atrito era tão alto que os usuários perdiam até 15 minutos organizando contratos em pastas locais do Windows antes de fazer o upload para o SaaS em uma única tacada, anulando o propósito de gestão da ferramenta.

5. Entrevistas em profundidade

Conduzi sessões de conversas semiestruturadas com gestores financeiros e de RH. A descoberta principal foi emocional e técnica: havia um medo real de cometer infrações jurídicas ou enviar contratos para destinatários errados devido à nomenclatura confusa e ambígua dos botões de compartilhamento.

6. Síntese e Diagrama de Afinidade

Compilei mais de 150 insights soltos coletados nas observações e entrevistas. Ao agrupá-los tematicamente, o diagnóstico tornou-se inegável: a raiz da crise não era a falta de funcionalidades, mas uma carga cognitiva extrema e uma arquitetura de informação caótica.

7. Card sorting aberto

Para reconstruir a taxonomia (nomes dos menus) do zero, recrutei 15 profissionais de RH para organizarem as funcionalidades como fizesse sentido para eles. Os resultados provaram que 82% dos usuários agrupavam as permissões e envios de uma forma radicalmente diferente da estrutura original desenhada pelos desenvolvedores.

8. Validação de estrutura (Tree Testing)

Com a nova Arquitetura de Informação desenhada, validei a estrutura da árvore de menus antes de desenhar qualquer tela. A taxa de sucesso dos usuários ao tentarem localizar a função "Criar lote de assinatura" saltou de apenas 34% (no menu antigo) para contundentes 89% na nova proposta.

9. Teste de usabilidade moderado

Protótipos de alta fidelidade foram submetidos a testes práticos baseados em tarefas. Durante o teste do fluxo de "Envio de Documentos", uma falha valiosa foi identificada: os usuários navegavam com fluidez, mas ainda pausavam no final, ansiosos, esperando uma confirmação do sistema de que a tarefa estava finalizada.

10. Teste A/B de microinteração

Para mitigar a ansiedade descoberta no teste de usabilidade, elaborei um Teste A/B com duas soluções de feedback: um "Toast" (notificação lateral efêmera) versus um "Modal" central contendo o resumo da ação. O Modal venceu de forma absoluta, proporcionando 100% de clareza, eliminando a insegurança jurídica da operação e marcando a entrega de um fluxo finalmente à prova de erros.

Ideação, validação e a falha necessária

Com os dados em mãos, estruturei os protótipos do novo sistema e parti para os testes de usabilidade, focando no fluxo crítico de envio de documentos.

É na fase de testes que o design prova seu valor: a primeira iteração revelou gargalos importantes. Os usuários ainda apresentavam dificuldade para sair do painel principal e iniciar o fluxo, e a ausência de indicativos visuais deixava-os sem saber se a ação havia sido concluída com sucesso.

Esses insights rápidos permitiram pivotar a navegação global e desenhar microinterações de feedback (visibilidade do status do sistema) antes de repassar o escopo final para a equipe de desenvolvimento, economizando horas de refatoração de código.