Skip to Content

What is SAP Fiori? Maybe it’s more than you think

I was fortunate enough to be invited to participate in the Bloggers Program at SAP TechEd in Las Vegas last week.

Among lots of interesting topics Fiori was one of the most discussed and debated. In fact a repeat of a 2 hour hands-on session scheduled on the Friday morning was filled to overflowing – quite an achievement when you consider many delegates choose to start their trip home on Thursday evening or Friday morning.

When the term “Fiori” comes up most people think about the 25 apps that were delivered as part of  what is now called “Fiori Wave 1” or of the distinctive look and feel of these Fiori apps themselves. *Fiori Wave 2 will arrive soon to be followed by Wave 3, etc.


But Fiori means more than that. It is a fundamental change to the way SAP are looking at delivering user experiences across much of the SAP product portfolio and it is also more than a few CSS style sheets and some Javascript.

Along with the Fiori look and feel comes something I have heard described as the “Fiori style” or “Fiori approach”.

In a recent discussion with Sam Yen, the global head of design and user experience at SAP, and Adi Kavaler, the SAP Product Manager responsible for Fiori, they referred to the “Fiori Design Principles”. These principles are being applied to all the new Fiori apps that are currently under development – look for announcements soon.

Screen Shot 2013-10-29 at 7.26.35 pm.png

The above slide I lifted from the SAP TechEd handouts comes close to capturing the details of this discussion – or at least most closely relates to my notes.

Not surprisingly the first of these design principles is that the screens should support all device types, screen sizes, form factors, versions and channels. Of course implicit in this is a “mobile first” principle as well. This means “responsive” design where a single code base produces a client experience that adjusts to best support the device characteristics. For example a tabular display should not be wider than the device width so the user does not have to scroll horizontally. So using responsive design techniques less important columns can be suppressed or rendered across multiple lines based upon the available screen width. This is a feature that is delivered as part of the mobile controls delivered in the SAPUI5 library. For a SAPUI5 working example go here and start resizing your browser window to see how the layout adjusts in response to the changing screen width.

Another design principle is to break a business function down into small independent pieces and build a UX for each piece. That is in stark contrast to how SAP have traditionally built Dynpro transaction screens – and Web Dynpro screen as well for that matter.

Take the example of the transactions for working with purchase orders in ERP. Sure there are different transaction codes for create, display and change of a PO – but they are really the same program with different entry points. SAP built a monolithic program for everyone who might need to touch a purchase order – a classic example of code reuse contributing to end user confusion. Because the PO transaction screens allow you to do absolutely anything you ever wanted to do with a PO it is a mass of different navigation areas, toolbars, menus, tab strips, drop downs, tables, etc. It is a screen that no one could navigate without at least some training – probably quite a lot.

Screen Shot 2013-10-29 at 7.18.46 pm.png

The Fiori Design Principles call for a much more focused user experience targeted at a single role and user. This means that each app is designed with much more conservative and practical goals and does not aim to be all things to all people.

SAP advocate a design principle known as 1-1-3 (“one one three”). This means each screen should be designed with a single user (or role) in mind, a single task that this user wants to accomplish, and a maximum of three levels of navigation to perform this task.

Another design principle is that the apps should all have consistent look and feel, navigation principles, etc. So, for example, if we decide that clicking on a header record should navigate directly to the item records then we implement this feature identically everywhere so the users intuitively know how to drill down to item level in every app. This is what is described in the above slide as “coherence”.

And finally the apps should be able to be delivered quickly and easily to provide instant value and the lowest possible barriers to adoption. SAP primarily achieve this by using NetWeaver Gateway to publish lightweight web services at the backend and the SAPUI5 libraries to build the user interfaces that consume these services. Both these technologies are readily available for the vast majority of existing SAP customers. I don’t know how far back the SAP Fiori apps will successfully run on older versions of Business Suite, but the SAPUI5 library and NetWeaver Gateway technology are available to all customers.

I can’t argue with any of these design principles – after all they are pretty close to the same UI design principles I have been advocating and implementing for many years. On top of that I can take the SAPUI5 libraries and construct my own apps using the Fiori look and feel and add them to the Fiori Launchpad.

IMO – all good stuff.

You must be Logged on to comment or reply to a post.
  • How do you deal with the app clutter or the large number of apps and finding the right one to use. To break up SAP’s vast functionality using 1-1-3 would require a very large number of apps. Are we counting on role based assignment to make the app selection feasible, or would this be only for casual users with limited needs.

    • Hi Vineet,

      thanks for your comments. Yes role-based assignment of apps is part of the plan. Watch out for more on this over the coming months.


      Graham Robbo

    • Hi Vineet,

      from what I saw of the “Wave 2” Fiori apps last week at TechEd, the new Launchpad will be crucial to dealing with this exploding number of ‘apps’. The Wave 1 approach of just bookmarking a couple of apps as icons on your phone’s home screen starts to break down when there are hundreds of apps out there of which you might want 20%. This is where the Launchpad comes in and provides a “portal-like” (or should that be ‘portal-lite’?) functionality, including app-to-app navigation based on semantic object linkages and user context. Dick Hirsch has also written a bit of a teaser blog about the launchpad which you might find interesting.

      Definitely a space to watch, and for my money a great move by SAP.


      • Hi Sascha, The other option for those already with SAP Enterprise Portal is to use the Mobile Portal to provide role based organization of apps for mobile.  But the launchpad is there if you don’t want to deploy Mobile Portal and of course not everyone will.



  • What’s interesting is the “mobile first” or screens fitting all applications.  I described back in 2011 how for CRM that mobile enablement was the wrong strategy, but rather especially for SFA that the applications needed to be true mobile applications instead of squeezing a destkop application into a mobile design.

    Believe it or not people rejected the concept that this was necessary.  Still I’m holding out on Fiori until a good replacement for VA01 that only requires configuration(not new coding) that can support all verticals and covers all traditional roles.  I really think the “infrequent” SAP user cases are not the real UI problem(self-service and work-flow approvals) but rather making people who sit in front of the old SAP GUI for eight to ten hours a day more productive! 

    Take care,


    • Thanks for your comments Stephen, missed you at TechEd too BTW.

      You touch on a very important point about the Fiori initiative. SAP have identified the most commonly used scenarios across the SAP customer base and these are the ones that they are building Fiori apps for first. While many of these apps are quite simple processes, workflow approval being a dominant one that is in Fiori Wave 1, that does not mean they are for “casual” users or “infrequent” use. In fact I would argue exactly the opposite.

      As for VA01 – I am so pleased that I don’t have to solve that problem for all SAP customers. However, it is a problem I can solve for individual user groups within my customer base with a bespoke solution. 😉


      Graham Robbo

      • Graham,

        I think I used the wrong terminology and instead should have said those processes that you don’t want to require training.  It’s not that they are frequently or even a casual user, but they are the ones that get most bang for the buck.  I think things like expense reporting, leave approvals, etc where you don’t do those 8 hours a day on a repeating basis, but are more frequrent. However many of us don’t do those enough to “remember” what we need to do when we have to do those and waste time if the system is unfriendly. That’s what I view most of the initial apps that I have seen addressing.  Nothing wrong with that and there is a ton of value.  If we can make the app design reduce the training overhead needed to learn it, then I’m all in favor for that.

        You are right that we are both lucky that we don’t have to come up with a general VA01 replacement.

        Yeah I wished Teched would have been possible this year, but it was too close to a GoLive and I spent my travel/education time elsewhere this year(CRM2013).  I need to get back but probably won’t if keeps being scheduled around my daughter’s birthday(family is first and why I work not the other way around).

        Take care,


  • I have to agree strongly with you Graham Robinson, SAP needs a new look and feel for their GUI applications, and I believe Fiori will do just that. So best to get’s the hands on it as there will be a lot more demand coming down the pipeline for UI changes using Fiori!

  • I am still wondering how this will help business users on the ground. Or is it more intended for casual users who update single peace of information.

    • Hi Udaya,

      Fiori is not just for “casual” users – but it is probably true that currently the best use case for a Fiori style app is for relatively straight forward processes where, as you say, we don’t need to capture large amounts of information.

      That will be one of the design challenges going forward – how to rethink the way we have done things like Sales Order entry in the past to meet both the needs of the user and the business. Of course Amazon, Staples, Apple, Walmart & Dell have managed to solve this problem pretty well so maybe the first step is to take off our enterprise user goggles and look at these problems with a fresh set of eyes? 😏


      Graham Robbo

  • Hi Graham,

    Thanks for sharing the design principles behind SAP Fiori with the community. Those principles, together with the new (for SAP at least) architecture of lightweight services with client side UX, form the most important aspects of the umbrella term Fiori IMHO.

    I hope this blog will guide SAP-partners who are going to design (and market) Fiori-style applications to implement these apps properly, instead of abusing the Fiori buzzword for their own SAPUI5 applications. I’m not optimistic about it though…

    Cheers, Fred

    • Hi Vivek,

      The Fiori apps delivered by SAP are currently only targeted at connected users. But there is no reason you couldn’t use the underlying technologies, NW Gateway & SAPUI5, in combination with other offerings to build apps capable of working offline.

      It’s just a question of time, money and people. 😏

    • The offline usage of Fiori-styled apps is an interesting point.

      I’ve already experimented a bit with a custom fiori-styled app and offline usage, and it works. SAP has even added the local storage API’s under their own namespace to make it extra easy.

      But I don’t think that SAP is going to provide offline usage in the standard Fiori apps, because that would mean that they cannibalize on their SMP (SAP Mobile Platform) which is supposed to provide a solution for offline scenario’s.

  • Hi Graham,

    Very valuable thoughts.

    In case you have a chance to be at TechEd Amsterdam stop by at the UX booth / Technology Showcase. You can see the latest Fiori Wave 2 demos like the MRP demo Sam Yen was giving at Vishal’s key note.

    One last thought on this: The more interest we see in deploying the growing # of standard Fiori apps the more interest I expect from customers asking their partners or SAP to “fiorize” their custom add-ons and integrate them in the launchpad as well. This could be a great opportunity.



    • Hi Oliver

      Looking forward to coming to see you also next week.

      BTW, one of the bones of contention (or at least confusion) is that Fiori was originally billed as the answer to the “Renew” part of the UX strategy, and by inference, not the “New” part.

      This is a shot from a series of slides from SAP that cover UX, and in my mind, the question of whether “new” apps can be called “Fiori” stems has the answer inferred as “no”, in the diagram.

      But having the privilege of working in Walldorf for the past couple of months on the SAPUI5 team, with exposure to the Fiori activities, has given me a good enough perspective to know that this is not necessarily the right answer 🙂

  • We have a huge technical debt in terms of User Experience …. and if SAP does not provide solutions for people who can work without SAP (the non professional users) then SAP is loosing market.

    That´s why easy to adopt and easy to introduce are key attributes not to be forgotten by SAP in the roadmap.

    How in the earth could we have still approval out of the box like the ones we receive from SAP ?

    So I am hearing some strong HANA dependency as of wave 2 ….. if it is the case easy to introduce will not be met.

    My users do not want fancy stuff (requiring new functionality enabled by HANA) …. we need the basic Great User Experience that the current FIORI design enables.

    May I ask SAP to stay focus on the FIORI principles and to resolve the technical debt ?

    No need to say tht for a couple of years we have seen a lack of adoption of SAP UI technologies ….

    Here I believe we have a lot of potential …. but SAP does not need to make it more fancy than needed.

    • Hi Patrick,

      thanks for your comments – and you raise a very good point.

      I have chosen to ignore mentions of “Business Suite on HANA” when associated with Fiori Wave 2. My personal view is that this is another example of marketing n00bs getting involved in product naming. In this case perpetuating SAP’s current naming standard that required use of the term “HANA” in everything. 😛

      I will be waiting until the Fiori Wave 2 apps are officially announced before rushing to judgement on this.


      Graham Robbo

  • It is interesting how SAP “repositioned” Fiori around the time TechEd came up. Many folks know Fiori as “those 25 apps” simply because that is all it was. I think SAP was testing the waters….amount of interest and adoption….for Fiori before re-branding/positioning it as their new go-forward design strategy. Matt Harding and I shared some similar thoughts on this.

    I like the idea of making things more simplistic and focused for the users, but I am guessing this might get taken and bastardized at some point with “exceptions” (where we suddenly see the 1-1-12 apps hahaha) simply so SAP can say they are still “in theory” staying with the Fiori principles. haha

    • Agree with you Christopher, that SAP plans position Fiori paradigm as new-generation UX across Business Suite (and others).

      And SAP have definitely change price model when it becomes “default” interface.

      By the way, do (and how) you see Fiori in HR P&F, (e.g. Approval app, that can be partially leveraged already)?

      • Don’t be misunderstood on SAP’s UX direction. Fiori is but one piece in 3 approaches they have….look at the TechEd presentation covering “new, renew, and enable”….new being of course all “new” solutions coming out, “renew” being ways they are re-doing UX where possible on existing solutions (like the process lanes UI you can see in the NetWeaver Business Client) and “enable” being ways to handle “older” solutions that can’t easily be brought “up to speed” (such as using screen “personas” for old GUI transactions and such).

        In the HR P&F world, you can see that it fits in the “renew” category (hence the “HR Renewal” releases.

        • Hi Christopher and Vasilliy,

          Agree with your comments above. My interpretation of the slides I have seen is that SAP are not looking to replace ESS/MSS roles fully via Fiori, rather supplement some of the key transactions for these users to the Fiori UI.  HR Renewal aims to improve the full ESS/MSS/HR Admin roles whereas Fiori is targeted at high volume services and casual user interaction. I personally don’t see a full HR P&F transaction in near future.

        • In the HR P&F world, you can see that it fits in the “renew” category

          Yes, it is.

          But SAP UX strategy changes fast.

          In April 2013 version:

          The preferred technology for renewal of key transactions in these enhancement packages is the Web Dynpro development environment and the ABAP® programming language, using the “floor plan manager” framework and the UI development toolkit for HTML5 for landing pages.

          But from the slide above Fiori is single option for “renew” direction – without WDA.

        • UPDATE:

          From the October 2013 SAP UX Strategy


          The technology used by SAP to decompose and apply the design directions, as done with SAP Fiori, is SAP’s UI development toolkit for HTML5, accessing SAP’s backend through SAP NetWeaver Gateway. For the renewal of current complex transactions, SAP is using WebDynpro ABAP with the Floorplan Manager.

          So, the WDA is the option still.


          Renew direction divided into two parts: SAP Fiori and Renovation (with WDA) with emphasis on SAP Fiori

          From this great presentation by Sam Yen

          Pay attention on Unified Shell Concept!

  • Hi,

    Fantastic stuff.I like the 1-1-3 Principle.

    we are using ESS/MSS for long now and moved from WDJ to WDA.

    With Fiori some apps like Leave Request have been made available on UI5.

    I am hoping other services are also made available with Fiori.

    that will certainly win the end users.



  • Hello Graham,

    Excellant summary. However, I did have a couple of specific questions.

    Firstly, there was a lot of talk on the approach for disconnected/off-grid users, is SAPUI5 now robust to handle the same? Has this been incorporated in Fiori?

    Secondly, is FIORI’s roadmap going to target non-casual users? Where can I get an actual list of the targetted wave 2 Fiori apps



    • Hi Karthik,

      SAPUI5 per se, does not provide support for offline use. This does not mean, however, that the SAPUI5 libraries couldn’t be part of such a solution if you wanted to built one.

      From my perspective Fiori has always targeted the great majority of SAP users – not just the casual users. The whole premise of Fiori was to take the most commonly used transactions and rebuild them to be more easily consumed. IMHO if anyone suggests to you that Fiori is for casual users only they are probably trying to sell you an alternative. 😏

      As for what is actually in “Wave 2” and beyond pay close attention to the information coming out of SAP TechEd Bangalore this week.


      Graham Robbo