Plataforma de Gestão Clínica
Evolução contínua de um SaaS para gestão de clínicas, utilizado por diferentes perfis de usuários.
Em evolução- Papel
- Product Owner · UX/UI Design
- Segmento
- SaaS Healthcare
- Entregas
- Discovery contínuo · Priorização · UX/UI · Requisitos · Backlog
- Status
- Em evolução
Visão geral
Atuei na evolução do principal produto da empresa, utilizado por mais de 2.500 usuários ativos, conectando o feedback dos clientes, as necessidades de negócio, UX/UI e a documentação funcional para o desenvolvimento.
Visão operacionalUnidade Aurora · Quinta-feira, 16 jul
Dados fictícios Unidade ativa
Agenda da unidadePróximos atendimentos
HojePaciente 204Consulta · Sala 02
Em atendimentoPaciente 318Retorno · Sala 01
ConfirmadoPaciente 076Avaliação · Sala 03
ConfirmadoPaciente 451Procedimento · Sala 02
A confirmarFluxo da equipePendências prioritárias
5 itensRevisar cadastro incompletoPaciente 091 · Recepção
Confirmar disponibilidadeSala 03 · Operação
Validar fechamento do diaFinanceiro · Até 18h
Capacidade por período
82% da agenda utilizada
O produto
A Plataforma de Gestão Clínica era o principal produto da empresa, desenvolvido para apoiar a gestão clínica, administrativa e operacional de clínicas e profissionais de saúde.
A plataforma reunia diferentes módulos e fluxos do dia a dia das clínicas. Meu primeiro trabalho no produto foi o redesign da plataforma; posteriormente, passei a atuar principalmente em sua evolução contínua.
O problema
Por ser um produto consolidado e usado diariamente por diferentes perfis, cada evolução precisava considerar regras de negócio existentes, impactos entre módulos, necessidades diversas e limitações técnicas. O desafio era transformar sinais dispersos em problemas claros, soluções consistentes e itens executáveis para o desenvolvimento.
Minha atuação
Atuei no ciclo contínuo de descoberta, definição e entrega de melhorias, aproximando clientes, áreas internas e a equipe de desenvolvimento.
- Conversas com Customer Success e clientes estratégicos
- Alinhamento com suporte, implantação, comercial e stakeholders internos
- Análise de sugestões, recorrência e cenários de uso
- Definição de escopo e prioridades
- Estruturação de fluxos, wireframes e protótipos
- Documentação de requisitos e regras de negócio
- Escrita de PBIs e critérios de aceite
- Refinamento com a equipe de desenvolvimento e acompanhamento do backlog
Como as oportunidades eram identificadas
A evolução do produto combinava sinais qualitativos e operacionais de diferentes pontos de contato com a base de clientes.
- 01
Customer Success
Dificuldades recorrentes, dúvidas operacionais e necessidades observadas no acompanhamento dos clientes.
- 02
Clientes estratégicos
Conversas para aprofundar problemas, compreender cenários de uso e validar oportunidades.
- 03
Stakeholders internos
Impactos operacionais, comerciais e técnicos discutidos com suporte, implantação, comercial e a equipe de desenvolvimento.
- 04
Módulo de sugestões
Ideias publicadas e apoiadas pelos usuários ajudavam a identificar necessidades compartilhadas pela base.
Processo de evolução
7 etapas
O processo criava uma linha clara entre o feedback recebido e aquilo que entrava no backlog para o desenvolvimento.
- 01
Feedback e sugestões
- 02
Análise do problema
- 03
Entendimento com clientes e áreas internas
- 04
Definição e priorização da oportunidade
- 05
Fluxos e protótipos
- 06
Requisitos, regras e critérios de aceite
- 07
Refinamento e evolução do produto
Decisões de produto
4 decisões
As decisões protegiam a consistência de um produto consolidado enquanto mantinham a evolução conectada a problemas reais.
- 01
Investigar antes de definir a solução
Pedidos de clientes não eram transformados diretamente em funcionalidades. Primeiro, eu investigava a necessidade por trás da sugestão, o contexto de uso e o impacto esperado.
- 02
Consolidar diferentes fontes de feedback
Sinais vindos de clientes, CS, suporte e stakeholders eram reunidos para identificar recorrência, impacto e prioridade — evitando decisões baseadas em uma única percepção.
- 03
Preservar consistência entre módulos
As melhorias precisavam respeitar os padrões de navegação, comportamento e organização já conhecidos pelos usuários. Fluxos e protótipos eram usados para alinhar a solução antes do desenvolvimento.
- 04
Traduzir decisões em backlog executável
As definições eram documentadas em requisitos, regras de negócio, PBIs e critérios de aceite, reduzindo ambiguidades e criando uma referência clara para o refinamento com o time técnico.
Resultado
Minha atuação contribuiu para manter um processo estruturado de evolução contínua, aproximando usuários, áreas de negócio e a equipe de desenvolvimento. O trabalho aumentava a clareza das demandas, reduzia ambiguidades durante o refinamento e ajudava a garantir que as melhorias partissem de problemas reais dos clientes.