Automo - Ecxus 🔒
Projetar sistema de gestão para móteis e hóteis, baseado em um sistema legado da própria Ecxus.
Visão Geral do Projeto
O Automo é um sistema de gestão para motéis — controle de quartos, reservas, financeiro e operacional. Um produto robusto, com anos de uso, que cresceu sem uma arquitetura de design planejada.
A Ecxus me contratou como único UX/UI Designer para modernizar o Automo: transformar um sistema instalável em uma plataforma web e mobile, responsiva para tablet (dispositivo principal), smartphone e desktop, com tema claro e escuro. E ainda expandir para atender hotéis — um mercado novo para a empresa, com regras e fluxos completamente diferentes.
O time era enxuto: Tech Lead, PO, um representante da diretoria e eu (UX). Decisões em comitê, com validações semanais. Havia um prazo real: a Feira de Hotelaria de setembro de 2025.
Processo de Colaboração e Discovery
Quando entrei, já havia um trabalho iniciado por outro designer. Ao analisar o projeto no Figma, ficou claro que não seria possível dar continuidade: sem auto-layout, sem componentização, com indícios de template pronto sem adaptação real ao produto. A decisão foi recomeçar do zero.
Como não havia tempo nem orçamento para pesquisa formal, as decisões de UX foram baseadas em feedbacks dos clientes da Ecxus, observações do suporte da PO e benchmark com concorrentes — majoritariamente focados em hotelaria, o que exigiu adaptação constante dos insights para o contexto híbrido motel/hotel.
A falta de requisitos definidos foi o maior gerador de retrabalho. Passei a estabelecer uma condição mínima antes de iniciar cada jornada: precisava saber o que ela faz, o que o usuário fornece e o que o sistema devolve. Sem isso, não iniciava a prototipação. Essa postura reduziu significativamente os ciclos de revisão nas etapas mais avançadas.
Identidade Visual e Design System
Uma das primeiras reclamações sobre o trabalho anterior era que as cores estavam apagadas. A nova paleta precisava ser mais viva — e funcional, já que as cores têm papel semântico real no sistema (status de quartos, alertas, categorias).
Comecei pela paleta e tipografia, construindo o design system de forma iterativa conforme as jornadas avançavam. Cada componente foi criado já com suporte a tema claro e escuro — o que evitou retrabalho posterior.
Por que comecei pelo tema escuro: o sistema anterior já o utilizava amplamente. Era mais orgânico para o cliente validar a nova identidade a partir de algo familiar. Após aprovação, adaptei para o tema claro com ajustes pontuais de tonalidade. A organização dos estilos no Figma tornou essa migração muito menos trabalhosa do que poderia ser.
A expansão para hotéis foi o maior desafio de escopo: motéis e hotéis têm lógicas de operação distintas, e a Ecxus ainda não tinha vivência no novo segmento. O benchmark com concorrentes ajudou — mas como a maioria atende apenas hotéis, muitos insights eram inviáveis no contexto híbrido do Automo, que precisava ser mais versátil do que qualquer concorrente analisado.
Elementos Visuais e Direção de Arte
Nenhuma ilustração foi criada. Em um sistema de gestão com essa densidade de informação, ilustração seria decoração — não design.
A energia criativa foi para onde tinha impacto real: arquitetura da navegação, hierarquia visual, semântica das cores de status e adaptabilidade dos componentes entre plataformas.
Decisões de Design e Iterações
| Antes | Depois |
|---|---|
![]() |
![]() |
Visão compacta do quadro de quartos
A tela principal da recepcionista mostra todos os quartos com cores por status. O cliente aprovou o conceito, mas pediu uma opção de visualização compacta — para empreendimentos com mais quartos. A solução foi um toggle de “Visão compacta” que reduz o card mantendo status e identificação legíveis. As duas versões convivem na mesma tela, com o usuário escolhendo conforme o contexto.
Jornada de Tarifa e Tabela de preços
Refeita múltiplas vezes — não por questões visuais, mas pelo conceito da jornada. O cliente propunha algo baseado no sistema anterior: termos semelhantes para situações distintas e muitas etapas para uma configuração simples. Refiz até encontrar uma estrutura que eu mesmo conseguia explicar em 30 segundos para alguém que nunca tinha visto o sistema.
Smartphone — a decisão que se confirmou
Desde o início levantei em reunião que adaptar jornadas complexas para smartphone resultaria em interfaces poluídas. Nas primeiras jornadas — quadro de quartos e CRUDs simples — a abordagem responsiva funcionou. Quando chegamos a Tabelas e Tarifas, o que eu havia previsto se confirmou: não era mais possível ser apenas responsivo. Componentes como tabelas precisaram de comportamento específico para mobile, aumentando a complexidade de prototipação e desenvolvimento.
Solução Final
Design system próprio desenvolvido no Figma, cobrindo:
- Tablet vertical — dispositivo principal de operação
- Web / Desktop — acesso administrativo e gerencial
- Smartphone — versão adaptativa com componentes de comportamento específico
![]() |
![]() |
|---|
A navegação foi reestruturada: os 11 menus com subníveis de até três camadas foram reorganizados em quatro áreas (Operacional, Administrativo, Cadastros Gerais e Configurações). O terceiro nível de submenus foi eliminado. Com controle de permissões, cada usuário visualiza apenas o que compete à sua função.
O lançamento oficial está previsto para a Feira de Hotelaria de 2026, com alguns clientes já em acesso antecipado na etapa de homologação.
Aprendizados e Reflexões
O aprendizado mais caro desse projeto não veio do design — veio do contrato. Deixei a urgência do cliente guiar a definição do escopo, e o projeto se estendeu muito além do previsto. Assumo essa estimativa como minha responsabilidade — e como o aprendizado mais concreto que levo para qualquer projeto freelance.
Quando o comitê começou a me responsabilizar pela lentidão, mostrei que o gargalo era a ausência de requisitos definidos antes de cada jornada — e que incluir novas pessoas nas reuniões estava reabrindo decisões já fechadas. O comitê ajustou: parou de incluir pessoas externas e passou a alinhar internamente antes de cada validação.
Duas lições que ficaram: não documentar versões descartadas é um custo que você paga no futuro. E defender o usuário em comitê exige argumentos de negócio — não só de usabilidade. “Isso vai confundir o usuário” é fraco. “Isso vai gerar chamados de suporte no onboarding” é o que move uma decisão.
Galeria












