Preciso saber ABAP pra criar um mockup Fiori?

Não pra desenhar a tela. Mas entender os floorplans do Fiori elements e como eles viram CDS View e annotations ajuda a produzir um mockup que o desenvolvedor consiga implementar sem surpresas.

Qual a diferença entre mockup e protótipo funcional?

O mockup é estático e foca em layout e fluxo, sem dados reais do backend. O protótipo funcional já tem comportamento e binding de OData. O mockup vem antes e é bem mais barato de alterar.

Mockup Fiori serve pra projetos S/4HANA Cloud?

Sim. Em S/4HANA, apps Fiori elements sobre RAP são o padrão, e prototipar aderente a List Report e Object Page acelera tanto on-premise quanto cloud. A lógica de floorplans é a mesma.

O mockup substitui a Especificação Funcional?

Não. Ele complementa a FS como anexo visual, tornando o requisito inequívoco. A Especificação Funcional continua descrevendo regras de negócio, integrações e critérios de aceite.

Mockup Fiori: Como Prototipar Telas SAP Antes de Codar 2026

Mockup Fiori é a prototipagem visual de telas SAP Fiori antes de qualquer linha de ABAP, CDS ou RAP ser escrita. Em vez de descobrir só no UAT que consultor funcional e usuário-chave imaginaram telas diferentes, você valida layout, campos, ações e navegação ainda na fase de design. O resultado é menos retrabalho de desenvolvimento, Especificações Funcionais mais precisas e estimativas RICEFW mais confiáveis. Neste guia prático mostro como prototipar telas Fiori do zero, quais padrões do Fiori Horizon e dos SAP Fiori elements respeitar e como transformar o mockup aprovado em artefatos técnicos — CDS View e Behavior Definition — sem queimar horas em ferramentas genéricas de desenho.

O que é um mockup Fiori (e o que não é)

Um mockup Fiori é a representação visual de uma ou mais telas de um app SAP Fiori — campos, colunas, filtros, ações, abas e fluxo de navegação — produzida antes do desenvolvimento. Ele serve pra alinhar expectativa entre o consultor funcional, o time ABAP/UI5 e o usuário-chave.

O que um mockup Fiori não é:

Não é um protótipo funcional com dados reais vindos do backend.
Não é o app final em UI5 com binding de OData.
Não é um desenho solto no slide que ignora os padrões da SAP.

A diferença importa porque um bom mockup já nasce aderente aos floorplans (os templates oficiais do Fiori elements). Quando o protótipo respeita List Report, Object Page ou Overview Page desde o início, a conversa com o desenvolvedor vira "implemente este padrão" em vez de "invente uma tela do zero".

Por que prototipar telas SAP antes de desenvolver

Em projetos de implementação SAP, boa parte do retrabalho de front-end nasce de um mesmo ponto: o requisito foi escrito em texto, mas cada pessoa imaginou uma tela diferente. O mockup remove essa ambiguidade.

Prototipar antes traz ganhos concretos:

Validação de UX com o negócio — o usuário-chave aprova o que vê, não o que lê numa FS de doze páginas.
Especificação Funcional mais forte — o mockup vira anexo visual da FS, reduzindo idas e voltas.
Estimativa RICEFW mais honesta — ao ver campos e ações, o time dimensiona esforço de CDS, annotations e extensões com menos chute.
Menos GAPs tardios — divergências entre standard Fiori e necessidade do cliente aparecem no design, não no UAT. Se você ainda está mapeando isso, vale revisar seu processo de GAP Analysis em projetos SAP.

O custo de mudar uma tela no protótipo é de minutos. O custo de mudar depois que já existe CDS View, Behavior Definition, Metadata Extension e teste escrito é de ordens de grandeza maior.

Floorplans Fiori: os templates que seu mockup deve seguir

Prototipar Fiori não é desenho livre. A SAP padroniza layouts chamados floorplans, e seu mockup deve escolher um deles antes de posicionar qualquer campo. Os principais:

List Report — lista filtrável de instâncias (ex: lista de Freight Orders). Barra de filtros + tabela + ações.
Object Page — detalhe de um objeto de negócio, com seções, abas e facets.
Overview Page (OVP) — dashboard de cards, bom pra visão gerencial.
Analytical List Page (ALP) — combina análise visual (gráfico) com lista detalhada.
Worklist — lista de itens que exigem ação do usuário, sem barra de filtro pesada.

A escolha do floorplan determina o resto. Um app de monitoramento de Freight Order tipicamente combina List Report (visão do conjunto de ordens) com Object Page (detalhe de uma ordem, itens, estágios e documentos como o CT-e). Definir isso no mockup evita que o desenvolvedor comece com o template errado.

Vale consultar as SAP Fiori Design Guidelines pra garantir que seu protótipo respeita espaçamento, tipografia e comportamento responsivo do tema Horizon. É a referência oficial de como um app Fiori deve se parecer e se comportar.

Passo a passo: do requisito ao mockup aprovado

Um fluxo enxuto pra sair do requisito à tela aprovada:

Leia o requisito e identifique o objeto de negócio. Qual entidade principal? Uma Freight Order? Um pedido de venda (VBAK/VBAP)? Uma remessa (LIKP)?
Escolha o floorplan. Lista + detalhe? List Report + Object Page. Dashboard gerencial? Overview Page.
Mapeie os campos. Quais atributos aparecem na lista, quais vão pra Object Page, quais são só de filtro. Marque o que é obrigatório e o que é somente leitura.
Defina as ações. Criação, aprovação, cancelamento. No RAP isso vira actions e determinations — já pensar nisso no mockup adianta a modelagem.
Desenhe a navegação. Como o usuário vai da lista ao detalhe, e do detalhe a objetos relacionados.
Valide com o usuário-chave. Apresente o mockup, colha ajustes e itere rápido.
Anexe à Especificação Funcional. O mockup aprovado vira parte formal da FS e entra como insumo do desenvolvimento.

Esse fluxo conversa diretamente com a fase de Explore do SAP Activate. Se quiser entender onde o mockup entra no método, veja a comparação entre SAP Activate e ASAP.

Do mockup ao código: CDS, RAP e ABAP

O pulo do gato é o mockup não morrer como imagem. Num projeto SAP moderno sobre RAP, a tela Fiori elements é dirigida por UI annotations em cima de um CDS View. Ou seja, boa parte do que você desenhou tem equivalente direto em código:

Colunas da lista → @UI.lineItem no CDS View.
Seções e abas da Object Page → @UI.facet.
Campos de filtro → @UI.selectionField.
Ações de negócio → actions na Behavior Definition (RAP).
Rascunho antes de salvar → draft handling do RAP.

Quando o mockup já é pensado nesses termos, o desenvolvedor ABAP (hoje muitas vezes atuando como fullstack Fiori) recebe um mapa claro do que anotar. A documentação oficial do modelo de programação está no SAP Help Portal, e a comunidade discute padrões reais no SAP Community — vale os dois como referência ao traduzir mockup em annotations.

É aqui que uma ferramenta com domínio SAP se diferencia de um editor de wireframe: ela não só desenha a tela, como sugere o CDS View e as annotations correspondentes, encurtando o caminho entre design e build.

Mockup Fiori vs ferramentas genéricas de desenho

Dá pra prototipar Fiori em qualquer ferramenta de wireframe, mas o custo escondido é alto: você reconstrói manualmente o que a SAP já padronizou e ainda corre o risco de desenhar algo que não existe no standard. Comparando:

Critério	Ferramenta genérica de wireframe	Mockup Fiori com IA SAP
Aderência aos floorplans	Manual, fácil de errar	Nativa (List Report, Object Page, OVP)
Tema Horizon	Precisa recriar do zero	Já aplicado
Terminologia	Genérica	VBAK, LIKP, /SCMTMS/, Freight Order
Saída técnica	Só imagem	Sugestão de CDS View e annotations
Risco de GAP	Alto (desenha fora do standard)	Baixo (respeita o que o Fiori entrega)
Reaproveitamento na FS	Copiar e colar imagem	Integrado à Especificação Funcional

Nenhuma ferramenta substitui o critério do consultor. Mas quando o protótipo já nasce aderente ao standard, sobra tempo pra discutir o que realmente importa: a regra de negócio.

Erros comuns ao prototipar telas Fiori

Ignorar o floorplan e desenhar uma tela custom que o Fiori elements não entrega — vira GAP de desenvolvimento caro.
Esquecer os estados de vazio, erro, carregamento e sem permissão. O usuário-chave precisa ver o que acontece quando não há dados.
Poluir a Object Page com campos demais. Use facets e seções; nem tudo precisa estar na primeira dobra.
Não pensar em responsividade. Fiori roda em desktop e tablet; o mockup tem que considerar os dois.
Prototipar sem o usuário-chave na sala. Mockup aprovado só por e-mail costuma voltar como mudança no UAT.

Como a IA do OrkestraFlow acelera o mockup Fiori

O OrkestraFlow foi feito pra arquitetos e consultores SAP, não pra designers genéricos. O Designer Fiori da plataforma entende a diferença entre um List Report e uma Object Page, conhece a terminologia de tabelas SAP e gera, a partir do mockup aprovado, o esqueleto de CDS View e as UI annotations correspondentes.

Na prática, o fluxo vira: você descreve o requisito, a IA propõe o floorplan e a tela aderente ao Horizon, você ajusta com o usuário-chave e exporta tanto o visual pra Especificação Funcional quanto a base técnica pro time ABAP. E como o mockup já está ligado ao resto da documentação, ele conversa com o BPD, o catálogo RICEFW e os casos de teste gerados a partir do fluxo.

Quer consultar valores e planos? Veja a página de Pricing. O objetivo é simples: encurtar o caminho entre "entendi o requisito" e "o desenvolvedor sabe exatamente o que construir".

Conclusão

Mockup Fiori não é luxo de projeto grande — é higiene de qualquer implementação SAP que use Fiori elements. Prototipar antes de desenvolver alinha expectativa, fortalece a Especificação Funcional, melhora a estimativa RICEFW e corta retrabalho. O segredo é respeitar os floorplans desde o primeiro rascunho e tratar o mockup como ponte pro código — CDS, annotations e RAP — e não como figura solta. Com a ferramenta certa, essa ponte deixa de ser trabalho manual e vira parte orquestrada da documentação do projeto.

Pare de desenhar telas SAP em ferramentas que não entendem o standard e passe a prototipar com uma IA que fala a língua do consultor. Começar 30 dias grátis e transforme seu próximo requisito em mockup Fiori aprovado — e já pronto pra virar CDS e annotations.