SAP Fiori Design Guidelines – A nova cara da SAP

SAP Fiori Design Guidelines - A nova cara da SAP
Blog Aliado / Blog Aliado / Blog do Diego

SAP Fiori Design Guidelines – A nova cara da SAP

Hoje vamos falar um pouco sobre o SAP Fiori Design Guidelines e o porque ele é importante para sua companhia.

O que é um Design Guideline

Vamos começar pelo básico: o que é um Design Guideline.
Basicamente, um guideline é um conjunto de recomendações. Um design guideline é, portanto, um conjunto de recomendações de design. Mas, o que isto significa na prática? E por que isto existe?
Se você ainda não leu dá uma olhada no meu artigo Design Thinking no processo de criação de aplicativos para conhecer um pouco mais sobre Design e entender a importância dele na construção de aplicativos. Recapitulando, um aplicativo bem desenhado atende alguns objetivos: intuitivididade, facilidade no aprendizado, eficiência e consistência.
A meta final é ter um aplicativo que não precise ser explicado como ele funciona, que se for preciso que o usuário aprenda algo ele consiga fazer isso sozinho (sendo o aplicativo o próprio professor), que com poucas ações o usuário consiga realizar a sua missão e que problemas semelhantes tenham soluções iguais dentro do aplicativo. Esse é o sonho!
Ocorre que atingir todos estes objetivos não é uma tarefa simples. Milhares de horas podem ser necessárias para refinar um aplicativo para que ele atinja o estado da arte. Não dá para fazer isto para cada novo aplicativo dentro da companhia. Precisamos otimizar os aprendizados. É aqui que surgem os designs guidelines.

Design Guidelines: Quem são? Onde vivem? Do que se alimentam? …

Como estes guidelines nos ajudam? Primeiro é importante entender que eles não são regras, mas guias. Sua função é aconselhar. Eles são frutos de muita pesquisa de design principles, e nos permitem seguir estes conselhos para criar regras de desenho para nossos aplicativos.
Traçamos então um caminho da origem um princípio (principle), um guia (guideline) e por fim uma regra (rule). Um exemplo seria: bons aplicativos são fáceis de aprender, logo, o aplicativo deve explicar ao usuário o que fazer (principle), se o usuário nunca fez algo, é preciso aparecer uma explicação de como fazer aquela ação (guideline), esta explicação será exibida em uma caixa suspensa, com um título de 24px e o texto em cinza claro (rule).
Parece óbvio, mas esta é a mágica do design bem feito: ele parece muito óbvio quando pronto, mas na verdade é bem complicado de se identificar.
Os principles e os guidelines, na verdade, são fruto de muita pesquisa em descobrir valores para os usuários. Novamente, dê uma olhada no meu artigo sobre Design Thinking para mais detalhes sobre o processo de levantamento de valor, mas o que precisamos saber aqui é: o processo de levantamento foi feito pelo criador do guideline. Sendo assim, todo o trabalho de observação e concepção já foi realizado. O que fazemos aqui é aproveitar todo este esforço simplesmente por seguir o guideline.
Existem vários designs guidelines por aí. A Apple tem o seu. O Google tem o seu. O Twitter tem o seu. E assim vamos. Perceba que estes guidelines trazem um efeito colateral de identificação. Você bate o olho em um APP e imediamente é capaz de dizer se ele é da Apple ou do Google.
Os princípios de design quando aplicados criam esta identidade. O Material Design do Google, por exemplo, parte do princípio de que as interfaces virtuais devem reproduzir a sensação de materiais físicos, isto significa que há sombras, perspectivas, texturas, etc. Nada disso é perceptível para um leigo, mas a sensação que esta decisão cria sim é percebida pelo usuário, e, inconscientemente, ele vincula este modo ao Google (que criou o Material Design). O mesmo se aplica à Apple, mas com sensações e decisões diferentes.

O SAP Fiori Guidelines

A SAP por sua vez, não se contentou em adotar um guideline de terceiros. Foi uma sábia decisão. As características de um usuário corporativo são diferentes daquelas de usuários de aplicativo em geral. Além disso, embora o uso em mobile devices devesse ser suportado, a verdade é que o aplicativo corporativo mostra todo seu potencial em um desktop.
Ao mesmo tempo, a SAP gostaria de criar uma identidade visual facilmente reconhecida. Isto agrega valor ao software e à companhia.
Sendo assim a SAP começou uma iniciativa para a construção do SAP Fiori UX. Isto ocorreu em 2013, com apenas alguns aplicativos que abrangiam uma pequena parte de funções de negócio do próprio SAP (as mais comuns).
Lá surgiram alguns dos pilares do Fiori (ou princípios como dissemos antes). A visão era que um aplicativo corporativo precisava: ser ligado ao papel do usuário (Role-Based), rodar em dispositivos móveis (responsive), ser simples (o que é muito mais fácil falar do que fazer), ser bonito (em oposição ao sentimento de ultrapassado que o SAP GUI transmitia) e coerente.
O próprio sistema de navegação era totalmente novo (o famoso Fiori Launchpad, em oposição aos menus e TCODES do SAP GUI).
E deu certo! A SAP foi inclusive premiada com Red Dot in the Interaction Category at the Red Dot Award: Design Concept 2015.
A SAP também lançou o SAP UI5 como uma versão Open Source (OpenUI5), de modo a aumentar o alcance da utilização do Fiori Guideline para fora do ecossistema SAP (competindo com o Material Design, por exemplo).

Não é só uma carinha bonita

Como você já deve ter percebido, um Design Guideline não é só sobre beleza (embora ela seja também importante). É especialmente sobre eficiência.
Ao adotar uma interface de usuário que é fruto de tantos estudos, o que se ganha é:

  1. Produtividade – O redesenho força o desenvolvedor a rever a organização da aplicação. As tarefas comuns (portanto, mais utilizadas) são organizadas em um fluxo mais eficiente. No caso do S/4 HANA, muito tempo foi gasto em pesquisa para identificar os gargalos no processo do SAP GUI e redesenhar a interação. O que não era essencial ficou em segundo plano e o fluxo comum é valorizado. Novos aplicativos que seguirem as diretivas do SAP Fiori Design Guideline trarão este ganho de produtividade em comparação com aplicativos desenvolvidos para o SAP GUI (ou mesmo externos ao SAP).
  2. Intuitividade – O SAP é um software construído por engenheiros (e bons), mas, muitas vezes, você precisava pensar como um engenheiro para entender o que fazer dentro de um fluxo de RH, por exemplo. O engenheiro tem sua forma de pensar moldada pela realidade de seus trabalhos e extremamente eficiente para lidar com ela. No entanto, quem opera os módulos de RH, Compras, Financeiro, etc., em geral, não são engenheiros. A SAP percebeu que este não era o melhor caminho, já que exigia que os usuários pensassem de uma forma que não era a natural para eles (usuários), era sim “o modo SAP” de fazer as coisas. O SAP Fiori muda isto ao adotar uma visão mais próxima da realidade diária do usuário.
  3. Atenuação da curva de aprendizado – A coerência significa que problemas semelhantes terão soluções semelhantes dentro do sistema. Um botão de “engrenagem” significa a mesma coisa em qualquer aplicativo (acesso às configurações). Isto está descrito no guideline. Parece bobo, mas é incrível o tempo que se perde tentando encontrar algo em uma nova tela. O fato de o guia direcionar como os problemas são enfrentados permite que um usuário facilmente possa desempenhar novas tarefas porque, no fundo, elas são apenas uma nova variação daquilo que ele já faz.
  4. Responsividade – O mundo é móvel, por que ficar preso ao desktop? A geração que está chegando ao mercado de trabalho agora foi apresentada aos smartphones muito nova, eles cresceram com isto. Parece ser impensável para este público não poder usar o seu dispositivo móvel para as tarefas do dia. O desktop ainda é insuperável em termos de produtividade, mas você ter que abrir o notebook durante a noite apenas para aprovar um pedido de compra, por exemplo, é absurdo. É apenas clicar em “Confirmar” ou “Rejeitar”. Isto tem que ser possível de ser feito no celular. E o Fiori UX defende isto.
  5. Ecossistema amplo e aberto – O ABAP é, sem dúvida, a linguagem com mais código SAP, mas o Fiori UX, na parte de interação com o usuário, não usa ABAP (apenas no backend). Isto traz novas possibilidades de interação, mas também amplia o leque de profissionais que podem trabalhar com softwares nativos SAP. O Fiori UX é HTML5 + Javascript, algo que é ensinado em todos os cursos de ciências da computação pelo mundo.

Para onde vamos?

Por óbvio, o caminho que a SAP decidiu trilhar quanto à interação com os usuários parece ser uma boa opção. Ela sai de um aplicativo totalmente desktop, que utiliza uma tecnologia proprietária (SAP GUI), para uma plataforma WEB, que roda em qualquer browser e qualquer dispositivo, em uma tecnologia aberta.
O S/4 HANA já é totalmente desenvolvido usando os princípios do SAP Fiori Design Guidelines, as funcionalidades que ainda não foram migradas são tratadas como “legado”.
Quanto aos parceiros SAP, é importante que entendam que a tarefa que há pela frente é longe de ser simples. Não é apenas uma mudança de tecnologia, trata-se de um redesenho da solução. Em termos de aspecto visual (e interação com o usuário) o S/4 é a nova versão do R/3, afinal nem o mySAP (de 2003) nem o ECC fizeram nenhuma mudança substancial (todos usavam o mesmo SAP GUI). A SAP demorou tanto porque não fazia sentido apenas fazer um facelift, ela só mudaria a interface com uma revolução das funcionalidades, e foi isso que S/4 HANA trouxe.
Para os clientes SAP, adotar uma interface homogênea traz todos os ganhos que eu enumerei neste artigo. Não faz sentido, em pleno 2021, adquirir um software SAP (sob medida ou de prateleira), que não siga as diretivas do SAP Fiori Design Guidelines.

Gostou desse artigo? Comente!
Artigo escrito por:

diego-yegros-perfil

Diego Yegros (Alliance Consultoria)

Com 22 anos de experiência, atua como Arquiteto de Soluções em empresas multinacionais do segmento de TI, definindo a arquitetura, gerenciamento e implementando inúmeros projetos de alta complexidade para SAP, SAP S4/ HANA.
Participa desde 2005 de inúmeras iniciativas tecnológicas envolvendo SAP e totalmente engajado nos projetos recentes do SAP S/4 HANA, com ênfase no desenho de soluções de aplicativos orientados para área fiscal e contábil. Desde 2013, integra e coopera com as equipes de tecnologia da SAP na solução fiscal TDF.
Sua experiência e conhecimento das mais modernas tecnologias para o desenvolvimento de aplicações, tem sido determinante na definição das estratégias de criação de soluções de software.
Formado em Análise de Sistemas e Direito, com diversos cursos de especialização em sua área de atuação.
Linkedin

Deixe seu comentário aqui!

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *