Split Hub: do vibe coding à governança no backoffice do AppSpace

Como auditei um backoffice construído sem design, encontrei 18 rotas que ninguém tinha desenhado e levei as 27 para 3 protótipos navegáveis e 103 telas no Figma, com regras de negócio, estados e governança documentados.

Etapas do Processo

CLIENTE

Housi · AppSpace · Split Hub

Período

Setembro – Outubro de 2026

Função

Product Designer, responsável pelo Splithub · auditoria, arquitetura da informação, prototipação e handoff

Equipe

Beatriz Koller (Product Manager), Vinícius Falcão (líder de Product Design), engenharia de backend, operação do AppSpace

escopo

Auditoria das 27 rotas de produção, redesign do fluxo condominial, 3 protótipos navegáveis, feature de anúncios por tela, 103 telas no Figma em 5 fluxos

Cenário & Problema

O prédio como serviço

No AppSpace, o condomínio vira um lugar de consumo: o morador compra no mercado autônomo, reserva a lavanderia, aluga um item no armário inteligente e agenda massagem ou limpeza, tudo no app e com cashback. Por trás disso há marcas e operadores parceiros, como OMO, Red Bull, Lupo e Bacio di Latte.

Isso cria uma pergunta de governança: quem opera esses serviços no dia a dia? O síndico cuida de áreas comuns, segurança e moradores. Ele não conserta lavadora, não confere estoque de armário e não fecha repasse de seller.

Split Hub é o backoffice onde a operação do AppSpace configura condomínios e módulos, divide cada venda entre sellers e plataforma, acompanha armários e lavanderias e publica anúncios. Parceiros externos entram com papéis limitados a um condomínio.

Onde o processo quebrava

1. O sistema existia, mas ninguém tinha desenhado.
O backend construiu o Splithub rápido, sem design system e sem documentação de produto (vibe coding). Funcionava, mas era um emaranhado de tabelas cruas, IDs no lugar de nomes e ações destrutivas sem confirmação.

2. O Figma não contava a história real.
O arquivo oficial tinha uma seção “V2” com 17 frames, e ninguém sabia quanto do produto ela cobria.

3. Regras de negócio só o código sabia.
Quanto fica com a Appspace quando o PDV não tem regra? O que acontece com a reserva paga quando a máquina é bloqueada? Ninguém tinha isso escrito.

O Desafio

Como transformar um backoffice construído sem design numa plataforma documentada, navegável e governável, sem jogar fora o que já funcionava?

Meu Papel

Sou o designer responsável pelo Splithub.

Redesenhei o fluxo condominial
(Armários, Lavanderia, hCondo e Pagamentos) em setembro, a partir dos prints de produção.

Auditei a produção em modo só de leitura e mapeei as 27 rotas reais contra o Figma.

Construí 3 protótipos navegáveis cobrindo todas as rotas, com regras, estados e dados fictícios.

Propus e prototipei a feature de anúncios por tela (celular e totem), revisada com o Vinícius Falcão, líder de Product Design.

Levei o Backspace inteiro de volta para o Figma: 103 telas a 2100 px, em 5 fluxos, com componentes e variáveis do tema.

02. Descoberta: a auditoria de produção

16 telas no Figma V2, 27 rotas em produção

Li o Figma e depois naveguei por splithub só para ver, sem salvar, ativar ou excluir nada. As rotas saíram do código da própria página.

O resultado: os 17 frames do Figma (16 únicos e uma cópia) cobriam 8 rotas. Banners eu trouxe de prints de produção. 18 rotas nunca tinham passado por design.

O que o vibe coding entregou

O que não aparece na tela

A auditoria levantou também o que as telas escondiam: estados escritos de jeitos diferentes e cadastros de teste misturados à base real, indicadores do dashboard que não batiam com as listas, ações destrutivas sem confirmação e dados pessoais em telas de exemplo, que troquei por fictícios.

Três descobertas de campo

1. Hardware precisa de hierarquia física

O operador da lavanderia caía numa lista de máquinas sem saber de qual prédio. Quem cuida de cinco condomínios caçava a própria lavadora.

Insight: não existe máquina solta. A âncora mental do operador é física: prédio (PDV) → máquinas → agendamentos.

2. Bloqueio não é falha

Bloquear uma máquina é decisão do operador. Quando o status misturava bloqueio e falha, prédios saudáveis apareciam “com falha” e nenhum ficava “Ativo”.

Insight: separar Ativo, Bloqueio operacional e Falha de liberação. “Com falha” conta só falha real.

3. O anúncio vive em duas telas

Os anúncios aparecem no app do morador e no totem do hall, mas o formulário não perguntava em qual tela. A arte do celular ficava cortada no totem.

Insight: o operador precisa escolher as telas e ver a prévia das duas antes de publicar.

03. Arquitetura & Decisões

Um menu por contexto

O Backspace foi organizado em 5 contextos: hCondo, Pagamentos & Taxas, Comunicação, Integrações e Governança & Acessos. Cada contexto troca o menu lateral e mostra só as funções daquele trabalho.

hCondo

Condomínios, módulos e saldo

Operação

Pagamentos & Taxas

PDVs, split e notas fiscais

Financeiro

Comunicação

Anúncios no app e no totem

Marketing

Integrações

Bazzar, armários e lavanderia

Ops e Tech

Governança & Acessos

Papéis, permissões e auditoria

Admin

Decisão 2: tabela densa pede tela larga

Problema: o operador entrava direto na lista de máquinas de todos os prédios

Solução:um passo a mais, de propósito: PDV → máquinas → agendamentos. A lista de PDVs mostra prédio, condomínio, endereço, número de máquinas, status (Ativo, Sem máquinas, Com falha) e ações. “Ver máquinas” já leva filtrado.

Trade-off: um clique a mais na entrada, em troca de contexto físico em toda a navegação.

Decisão 2: tabela densa pede tela larga

Problema: em 1440 px a tabela de agendamentos cortava na lateral. Na primeira versão do Figma, em 1536 px, os filtros quebravam em duas linhas e as datas viravam três.

Solução: os artboards das tabelas operacionais passaram a 1680 px, e as 103 telas no Figma foram para 2100 px. Modais e gavetas mostram o conteúdo inteiro, sem scroll escondido.

Impacto: o operador lê status, período e telas de cada anúncio numa linha só.

Decisão 3: uma campanha, duas telas

Problema: não havia como dizer se o anúncio ia para o celular, para o totem ou para os dois, e a arte do celular era cortada no totem.

Solução: no passo “Quem vê”, o bloco “Em quais telas” com Celular e Tablet (os dois marcados, para anúncio antigo não perder alcance). A prévia alterna entre os aparelhos, mostra a “área segura” e tem o modo lado a lado. Cada tela confere proporção, corte e resolução e avisa sem bloquear. O switch “Usar outra arte no tablet” abre um segundo envio, de 1920 × 1100.

Na revisão de design: o Vinícius tirou o QR code do totem e a opção “Usar link”. Ficou só o upload de arquivo.

04. Telas, estados e governança

1. Regra de split e simulador

A regra mostra quanto vai para cada seller e quanto fica com a Appspace, numa barra segmentada, com o valor em R$ 100 ao lado de cada percentual. O que não é alocado vai para a Appspace sozinho. “Salvar” só habilita quando algo mudou e a soma não passa de 100%. Antes de valer, a regra pode ser testada no simulador.

2. Governança & Acessos

São 11 papéis, com permissões no formato `recurso.ação` em 13 recursos. As permissões sensíveis levam alerta. Papel externo só vale dentro de um escopo, como um condomínio. Dá para conceder ou bloquear uma permissão por pessoa, e cada evento da auditoria mostra quem fez, onde e o payload, com nome no lugar do ID cru.

3. Os estados que o Figma V2 não tinha

Carregando, erro, vazio, sucesso e confirmação em toda ação de alto impacto: excluir anúncio, inativar condomínio, remover e excluir papel, bloquear máquina, cancelar reserva.

4. Design system e handoff

O Splithub manteve a identidade do Figma (menu vinho #382328, rosa #CC657A, pink nos toggles) num único arquivo de tema, sobre o kit RETRIEVER: fonte Montserrat e espaçamentos do DS 3.0. Uma tabela no mapeamento registra o que muda quando o Backspace migrar de vez para o DS.

Depois dos protótipos, levei o Backspace inteiro de volta para o Figma: 103 telas a 2100 px em 5 fluxos (hCondo 29, Integrações 34, Pagamentos & Taxas 18, Governança 11 e Comunicação 11). Cada fluxo tem os próprios componentes e ícones, num total de 101 componentes de interface e 58 ícones, todos ligados à coleção de variáveis “Backspace · DS 3.0”, que nasceu com 122 cores. Os estados que o Figma V2 não tinha (carregando, erro, busca sem resultado e confirmações) agora também estão lá.

5. Como trabalhei com IA

Usei IA agêntica no fluxo inteiro, com a decisão sempre do meu lado:

Auditoria: navegação automatizada e só de leitura em produção, sem clicar em nada que gravasse dados.

Prototipação: 3 protótipos e 73 telas e estados em 2 dias, revisados tela por tela contra o Figma e os prints.

Figma:as telas foram recriadas a partir do protótipo, com componentes e variáveis.

Onde o meu olho corrigiu a máquina: a tabela cortada em 1440 px, os filtros quebrados em 1536 px e um bug de cache do Figma que escondia modais em 8 telas.

05. Resultados & Aprendizados

O que dá para medir hoje

27/27

rotas de produção auditadas e prototipadas

Auditoria de produção

rotas que nunca tinham passado por design

Auditoria de produção

telas e estados navegáveis em 3 protótipos

Protótipos

2 dias

do link do Figma ao backoffice completo

05 a 07/10/2026

perguntas de produto documentadas para a PM

Mapeamentos

erros em 297 cliques de teste automatizado

Teste de fumaça

erros na auditoria do design system

3 protótipos

103

telas no Figma a 2100 px, em 5 fluxos

Handoff

Ainda não medido: tempo para configurar um PDV novo, tickets indevidos ao síndico e erros de repasse. Isso depende da implementação, e é o próximo passo que quero acompanhar.

Aprendizados

1. Plataforma complexa é sobre fronteiras de domínio

O valor deste projeto não está na beleza dos botões, e sim no modelo: o síndico cuida da moradia, a operação cuida do serviço parceiro e a Housi cuida da tecnologia e do repasse. Com isso claro, cada tela sabe para quem existe.

2. O antídoto para o vibe coding é a arqueologia do produto

Em vez de descartar o que o backend construiu e pedir meses para redesenhar do zero, mapeei o que existia de verdade, escrevi as regras que só o código sabia e levei as dúvidas para quem decide. O sistema funcionava; faltava ser desenhado e documentado.

3. Densidade não é o oposto de usabilidade

Operador de backoffice não quer uma tela com um número gigante. Quer contexto, filtros numa linha e status confiável para decidir rápido. Por isso a largura, a hierarquia física e a separação entre bloqueio e falha.

4. A IA acelera, o critério continua sendo do designer

A IA me deu velocidade para auditar e prototipar 27 rotas em 2 dias. Mas foi o meu olho que pegou a tabela cortada, os filtros quebrados e o bug de cache no Figma. A ferramenta faz rápido; quem decide o que está certo sou eu.