Caso C-01 · Facilia Fiducial · France

Do caos herdado a uma plataforma B2B em produção

A Facilia é uma plataforma de faturação e gestão para pequenas empresas. Entrei num projeto que tinha perdido o seu designer e nunca tivera uma direção, e fiquei para desenhar o produto de ponta a ponta, hoje usado por dezenas de milhares de empresas em toda a França.

Função

Responsável pelo design de produto, ponta a ponta

Cronologia

2021–presente · líder de UX + QA 2024–2026

Competências

UX/UI · Estratégia de produto · Arquitetura de informação · Gestão de stakeholders

Ferramentas

Figma · ZeroHeight · Jira · PrimeNG (com eng.)

Dashboard do módulo de Vendas da Facilia em produção
Fig. 01 O dashboard do módulo de Vendas, ao vivo em produção: o produto de que trata este caso.
01

Contexto

A Fiducial é um grupo francês multissetorial. Um dos seus pilares é a Fiducial Comptabilité: uma rede de escritórios de contabilidade espalhados por França, que gerem as contas de pequenas empresas locais: a padaria, o consultório médico, a empresa de jardinagem.

A Facilia nasceu para servir esses clientes finais: uma plataforma SaaS para orçamentos, faturas e pagamentos, pensada para donos de pequenas empresas, gente que não domina nem contabilidade nem software. A particularidade estrutural do projeto moldou todo o meu trabalho: a estratégia estava em França (Lyon), a execução em Portugal (Braga), com os requisitos a chegar através de gestores intermédios, muitas vezes vagos e sem documentação.

02

O que herdei

Entrei cerca de seis meses depois de o projeto ter arrancado, e não encontrei um início, encontrei um problema. O designer anterior tinha saído, esgotado. Dezenas de ecrãs, desenhados mas desligados, sem documentação, sem critérios definidos. E o mais crítico: o desenvolvimento já estava a decorrer, a construir sobre essa base indefinida.

A tensão que define este caso: dar direção a um produto sem poder parar um comboio já em andamento.

03

Diagnosticar antes de desenhar

A minha primeira decisão foi não desenhar nada. Antes de produzir um único ecrã, precisava de perceber o que existia e porquê, e a resposta, depois de interrogar os responsáveis, foi que praticamente não havia um "porquê" documentado. Por isso comecei pela infraestrutura de conhecimento que faltava.

Esse mapeamento revelou o padrão mais perigoso do projeto: funcionalidades herdadas com uma ambição desproporcionada face à capacidade de entrega, e sem retorno de usabilidade que justificasse o custo.

Base de conhecimento

Cada funcionalidade do produto documentada, construída com a gestão de projeto.

Percurso do utilizador

Quem é realmente o utilizador e o que precisa de fazer.

Fluxos de utilizador

Os percursos reais mapeados, estrangulamentos localizados.

Auditoria de design

O que valia a pena manter, separado do que precisava de ser repensado.

04

Decisão 01: Simplificar a importação sem perder o valor de negócio

O caso mais claro era o onboarding de importação de dados. O fluxo herdado era praticamente um produto dentro do produto: o Excel importado tornava-se uma tabela editável no sistema, com múltiplos passos antes da importação final. Impossível de construir dentro do prazo, desproporcionado face ao problema.

Cortei a ambição, não o valor.

Modelo padrão

Descarregar uma folha de cálculo modelo que o sistema reconhece, colocar lá os dados, importar.

Reduzir ao essencial

O editor de folha de cálculo embutido desapareceu. A organização vive nas próprias secções do produto.

O valor mantido

Desduplicação por SIREN, deteção de artigos ativos/inativos, validação de campos obrigatórios.

Antes: o fluxo herdado
Fluxo de importação antigo, passo de boas-vindas
Fluxo de importação antigo, ecrã de edição de tabela embutida
Fig. 02 O fluxo de importação herdado, um editor de folha de cálculo embutido num onboarding.
Depois: em produção hoje
Nova importação: um único modal com descarga do modelo e arrastar-e-largar
Fig. 03 O mesmo trabalho, hoje, em produção: um modal (descarga do modelo, arrastar-e-largar, deteção automática).
O modelo de importação padrão da Facilia aberto no LibreOffice, preenchido com dados de cliente de exemplo
Fig. 04 O modelo padrão da Facilia, o contrato entre os dados do utilizador e o sistema.
05

Decisão 02: Um formulário é um formulário; um documento é outra coisa

No conceito original o formulário do orçamento era mostrado no ecrã como uma folha A4, e o PDF espelhava-o exatamente: um documento visualmente pobre, e uma interface de edição refém do formato de papel.

O lado da edição

Um formulário guiado: passos obrigatórios visíveis, progresso claro. Feito para preencher.

O lado do documento

Desenhado como um documento: limpo, imprimível, profissional. Feito para ler.

Um ganho de negócio

Desacoplar os dois abriu uma biblioteca de modelos de documento: modelos diferentes para perfis de cliente diferentes.

Formulário de criação de orçamento com passos obrigatórios visíveis e progresso
Fig. 05 O lado da edição: um formulário guiado, com passos obrigatórios visíveis e progresso claro.
Pré-visualização do documento final: limpo, imprimível, profissional
Fig. 06 O lado do documento: desenhado como um documento (limpo, imprimível, profissional).
06

O método, amadurecido: o módulo Achat

As Vendas nasceram no caos da fase inicial. Quando chegou o módulo de Compras (Achat), o processo foi diferente: comecei pelo mapa: a arquitetura completa desenhada antes de um único ecrã.

Secções e módulos

Cada secção e módulo interno mapeado de raiz.

Funcionalidades

Cada capacidade definida por secção, antes da UI.

O fluxo de estados

à traiter → à valider → acceptée / refusée → à payer → payée, o percurso de cada fatura pelo sistema.

Mapa completo de arquitetura do módulo Achat: secções, funcionalidades e fluxos de estados de fatura
Fig. 07 O mapa de arquitetura do Achat: cada secção, funcionalidade e estado de fatura, desenhado antes de um único ecrã.

O que foi mapeado é o que foi construído. O plano corresponde, um a um, ao que está em produção.

Dashboard do Achat com faixas de faturas vencidas
Fig. 08 O dashboard do Achat, com faixas de vencidos, diretamente do nível de topo do mapa.
Secção de validação a mostrar estados de fatura
Fig. 09 A secção de validação: os estados de fatura mapeados, ao vivo.
Ecrã de tratamento de fatura: documento lado a lado com metadados editáveis extraídos por OCR
Fig. 10 O ecrã de tratamento de fatura: o documento ao lado dos metadados editáveis extraídos. O motor de extração veio de outra equipa; o meu trabalho foi desenhar a interface que torna o seu resultado revisível, e corrigível quando erra.
Ecrã da ficha de fornecedor (fiche fournisseur)
Fig. 11 A ficha de fornecedor (fiche fournisseur), uma das secções mapeadas, em produção.
07

Resultado

Início de 2025

Em produção desde então, em expansão contínua da base

~40k

Clientes ativos só no módulo de Compras

~25k

Clientes ativos no módulo de Vendas

3.º módulo

Tesouraria, com integração bancária, em desenvolvimento

Dezenas de milhares de clientes ativos no total, a caminho da meta de negócio de 100k.

Modelo de receita por módulo (Vendas, Compras, Tesouraria) mais créditos de emissão de documentos.

08

O que este projeto me ensinou

Que o trabalho de design mais importante nem sempre é visual. A esta escala, as decisões que geraram mais valor foram estruturais: criar a infraestrutura de conhecimento que não existia, filtrar a ambição para algo entregável, separar conceitos que estavam colados (formulário/documento), e construir o processo que permite à próxima funcionalidade nascer mapeada em vez de improvisada.

Num ambiente multi-país, multi-stakeholder e sob pressão, a competência que sustenta todas as outras é o discernimento: saber o que defender, o que negociar e o que deixar ir.

Fronteira atual: estou a trabalhar para levar o produto à sua próxima maturidade: das métricas de adoção (quantos o usam) às métricas de comportamento (como o usam), para que o próximo ciclo de decisões de UX seja guiado por dados de uso reais.