openSAP

SAP Fiori UX Design Challenge

HISTORY AND OVERVIEW
00:00:13

Welcome to the SAP Fiori UX Design Challenge.

00:00:18

My name is Bob Caswell and I'm a Product Owner focused on the user experience topic at
SAP.

00:00:23

You might remember me from Unit 5 in Week 1, where I talked about rapid deployment
solutions.

00:00:29

My goal with this video is to give you an overview of SAP Fiori UX Design and its History. UX,
of course, standing for user experience.

00:00:38

So, this is going to be a quick crash course into the fundamentals of Fiori UX Design.

00:00:44

And it's meant to be watched along with the other optional video called SAP Fiori UX Design
Challenge Tips and Tricks.

00:00:53

In that video we'll go into more detail about the design challenge specifics, the resources
available to you, and how best for you to get started.

00:01:02

Both videos are here for you as preparation for your participation in the SAP Fiori UX Design
Challenge.

00:01:09

You can watch them in whichever order you prefer and neither one is required for you to
participate in the challenge.

00:01:16

But I'd strongly recommend you to watch both of them and perhaps start with this one, SAP
Fiori UX Design History and Overview

00:01:26

because it provides a much needed context for the concepts and reasoning behind SAP Fiori
UX Design.

00:01:33

Both videos together are designed to give you enough understanding to feel comfortable
submitting something for this challenge even if you have no previous design experience.

00:01:45

So, let's get started by reviewing the Fiori UX design principles covered in Week 1.

00:01:53

First, let me call out the two principles that we are going to focus on the least on the purposes
of the challenge: responsive and coherent.

00:02:01

Now, the reason for this is because responsive which means that all Fiori apps work equally
well across all input devices or form factors and dynamically adjust,

00:02:13

so regardless, if you're using a desktop computer or a mobile device, a keyboard and a

mouse, or touch input.

00:02:21

Regardless of all that, all Fiori apps respond and adjust automatically to fit the paradigm, the
input paradigm that you are using.

00:02:31

But for the purposes of this challenge, just assume that's a given and don't worry too much
about figuring out how to make that happen.

00:02:40

So, what that means is pick the scenario that you want to cover, that you want to showcase

with your own design, your own user experience

00:02:49

and just choose a starting point of either desktop or mobile and focus on that one version of
your experience

00:02:55

and just keep in the back of your mind how you might also design it to work with the other type
of environment.

00:03:03

Next is coherent. Now, this means that the user doesn't have to learn anything new or see a
new set of icons, or commands, or graphics when navigating between screens or between
Fiori apps.

00:03:16

Generally speaking, all Fiori apps adhere to a similar look and feel such that users are
comfortable using most all Fiori apps soon after they've used just one.

00:03:27

But since you're creating a new experience for your own Fiori-like scenario

00:03:31

and we want to give you the flexibility to show us how you think a user experience should or
could be

00:03:39

just focus on coherence within the scope of your own project. So that means that you can
make your experience look like a Fiori app but it doesn't necessarily have to.

00:03:49

It doesn't have to adhere to the Fiori look and feel. It just needs to be coherent in and of itself

00:03:55

So inside of whatever you submit there has to be some consistency and a fluent seamless
intuitive experience

00:04:02

but it doesn't necessarily have to match the way Fiori looks and feels. It can but it's up to you.

00:04:11

Now for delightfulness, this is how to quantify concretely but think of your favorite consumer
app that you use frequently.

00:04:19

Why do you enjoy it? What connects you to it?

00:04:23

Try to reply that delightfulness and connect to the experience to how you'd want to design an
enterprise app or experience to be enjoyable.

00:04:31

And that should be the basis for what influences how you might consider some of the thinking
that goes into the user experience that you create for your submission.

00:04:41

The next two topics I am going to combine and cover in more detail, those are role-based and
simple.

00:04:49

There is actually a lot to cover here and this is where the history comes into play to really
understand why Fiori is what it is today.

00:04:57

So let's take a closer look.

00:05:00

At the heart of the design principle 'simple' is the idea of shifting from a transaction-based
approach to an app-based approach.

00:05:09

We no longer build huge transactions but instead break down required functionalities into
simple and user-centric apps.

00:05:19

So now the question is what exactly is the difference between apps and transactions.

00:05:24

What exactly can we do during the design process to simplify our applications but also make
them viable enough to meet user and business requirements.

00:05:35

So let's talk about this transformation process of going from transactions to apps.

00:05:41

Many years ago when key SAP systems were initially designed they were primarily architected
from a system perspective.

00:05:51

That is, there were a bunch of objects and on top of these objects a bunch of transactions
were created

00:05:56

so that basically any user could operate these objects with functions like create or delete or
view and so on and so forth.

00:06:05

For example, we have a sales order object and then we have a create sales order transaction.

00:06:12

This transaction allows a sales order to be created by someone.

00:06:18

And it can be a sales rep, a sales operation person, a customer service agent, or possibly
anyone else in another role.

00:06:27

But the user interface is not optimized for any particular role even though their user
requirements can be dramatically different between roles, companies, or industries.

00:06:38

So as a result, the information architecture of the system was largely influenced by the
backend architecture.

00:06:47

And what happens is this often doesn't match up well with any user's real-world tasks,

00:06:54

of course, the UI of SAP's Business Suite has been improved a lot over the years.

00:06:59

However, this transaction-based information architecture has remained somewhat unchanged.

00:07:08

So what this can cause is a lot of people complaining that business IT systems are way too
complex.

00:07:16

So let's try to be specific. What exactly is the complexity?

00:07:20

We generally hear of two types of complexity. Sometimes, when people say complexity they
mean information overload on a specific transaction

00:07:30

because the transaction is designed to be used by a lot of people, and each person might have
a different set of information needs, different objectives, or different use contexts.

00:07:42

We often end up with what I am going to call a mega-transaction meaning that there are
hundreds if not thousands of fields on the screen

00:07:52

trying to satisfy everyone's needs but in the end frustrating everyone.

00:07:57

So taking the create sales order transaction again as an example, in realty sales reps don't
want to use this transaction today to create a sales order

00:08:06

because it's just too complex. They want to spend their time on sales, on building relationships
with their customers rather than figuring out how to enter data into the system.

00:08:17

Well, at the same time, the transaction might work pretty well for the back-office sales
operation guy who perhaps has received a lot of system training.

00:08:26

But for a sales representative in the field who, for example, travels to retail stores or talks with
customers on a daily basis

00:08:34

would he or she use the transaction you see on the screen to order stuff for his or her
customers?

00:08:40

Probably not. Or at least probably not willingly.

00:08:45

So the second type of complexity is when the system offers too many similar transactions to a
single user

00:08:53

who gets lost with so many very similar yet somehow different ways to accomplish the same
task.

00:09:00

The user quickly can get lost in the sea of options. Let's look at an example.

00:09:05

When the Fiori Design team originally started the design for a new app for the stock overview
scenario,

00:09:11

they themselves were actually really confused by so many similar transactions available for the
same task.

00:09:18

The codes that you maybe are not familiar with are MD04, MD05, or 06, or 07 ...

00:09:25

All of these transactions for the stock overview scenario look quite the same with only slight
differences.

00:09:33

In the end, the user task behind each transaction is pretty much the same:

00:09:38

Understand my stock situation, identify exceptions, and then react to them.

00:09:43

Users eventually learn the differences between all of these scenarios or transactions

00:09:49

but why should we provide them so many different transaction UIs and let the users be
confused by which one to use.

00:09:58

There's actually a good answer for this and reasoning behind it.

00:10:02

It all comes back to system performance. Now, without going into too much detail let me just
share for context:

00:10:10

This scenario and many other scenarios like it, historically, this scenario can take a lot of time

00:10:16

and is often made to be done as a batch job because it can be costly to show real-time stock
information which otherwise would be the preferred view.

00:10:25

So what that means is there's a transaction to show us a snapshot of the data, and another
transaction to show the real-time view of the data,

00:10:32

and another transaction to show the single material situation, and yet another transaction to
show a multiple material situations, and on and on.

00:10:39

Again, from a system design perspective this makes sense but it really doesn't make a lot of
sense from an end-user perspective.

00:10:48

Nowadays with better systems in place, we really have an opportunity to get rid of all of these
performance constraints

00:11:54

and refactor information architecture to match and map to the real end-user's tasks.

00:11:03

So, there you go, the history of SAP transactions in a nutshell. Now let's look at the new
paradigm - apps.

00:11:13

An app is not just a set of features. It's a purpose-built tool to support a persona to complete a
task.

00:11:22

Now just think of persona as another way of saying user type or user group.

00:11:27

This purpose-built tool or app, as we're going to call it,

00:11:31

can also be used by multiple personas if the user requirements and use contexts are similar or
very similar.

00:11:43

An app is designed purely from the consumption perspective and should be agnostic to the
backend model.

00:11:51

Once the design is done the backend should do data mapping to the design not the other way
around.

00:11:58

So unlike the past where the system architecture dictates the user experience with the design,
in this new paradigm it's the other way around.

00:12:08

The design perspective, the user experience, that is what we start with

00:12:15

and then we map the backend data to that design that works beautifully for the user
experience.

00:12:23

So, now we are ready to cover the Fiori UX design principles of role-based and simple what
we've been leading up to this whole time.

00:12:35

And put another way, you have to ask the question how granular should your app be.

00:12:42

Now, which features, what should it accomplish, how detailed or simple should it be.

00:12:47

And the answer is that really depends. For the same transaction, if different personas - that is
different users - have different information needs,

00:12:58

then you should create multiple apps so that each user gets a tailored experience.

00:13:03

We call this the decomposition process because we are breaking down complex megatransactions into simplified apps.

00:13:13

Remember the create sales order example. There are tons of people who use that in different
ways and so ...

00:13:18

Well, it's just one transaction, it could be several apps. And we'll talk more about that.

00:13:24

So in some other cases, for a single continuous task we may combine multiple transactions
and present them in a single app to support the user

00:13:34

to achieve a final outcome that's only possible by combining two experiences otherwise found
in separate transactions.

00:13:42

So what we call this is the composition process. So sometime it's best for an app to combine
multiple similar and related transactions into one single integrated app.

00:13:54

So, the granularity of each app has to be defined case by case and must be based on the user
task analysis.

00:14:03

What exactly is the user trying to accomplish in their day-to-day work life?

00:14:09

You should try to forget about the concept of transactions and start the design process based
on a deep understanding of your users and their needs,

00:14:18

not based on the system architecture.

00:14:21

You can see how both of these approaches, decomposition and composition, they're both valid
based on the context and outcome hoped for.

00:14:30

And both approaches need to keep in mind the simple Fiori UX design principle.

00:14:37

That is, generally speaking, you want to try and get your scenario to be for one use case of
one user that can be accomplished in three screens or less.

00:14:48

This isn't a hard and fast rule but it's strongly recommended especially when you're designing
your first Fiori-like app.

00:14:54

So unlike, you know, traditional software there aren't two or more or dozens or hundreds even
of different scenarios accomplished when the app is started by the user.

00:15:05

You know, when the user first goes into an app they're not going to pick from a complex set of
menus and navigate to the buried fields and screens they need.

00:15:15

Rather it is going to be extremely focused and simple but still accomplish exactly what the user
is trying to accomplish for that particular use case.

00:15:25

So, let's take a quick look at the process SAP used for defining and designing SAP Fiori UX
apps.

00:15:37

First, you need to start by defining the market focus.

00:15:42

For example, the sales process of an insurance company will be completely different when
compared to the sales process of a manufacturing company.

00:15:51

So you can't necessarily design one thing that fits every industry's requirements.

00:15:57

Second, when you have the industry focus defined what you're going to need to do is engage
with end-users

00:16:03

to understand their business realty, need to document or understand the organizational

structure, who are the stakeholders,

00:16:10

how do they collaborate with each other, what do they want to achieve, what are the tools they
use ...

00:16:15

And then, based on these insights, you capture insights and create personas.

00:16:22

Third, you create storyboards or a process model to show at a high level the end-to-end
process that the particular persona or user you're focusing on

00:16:32

will go through to accomplish their task easily and effectively.

00:16:38

Fourth, from these storyboards then, you can start what's called the app abstraction process
for defining the app.

00:16:48

What this refers to is that every scenario relies on certain tasks requiring human input and
other tasks that are automated by the system being leveraged.

00:16:57

So, as part of defining the app and what it accomplishes, you have to determine which parts of
the experience are covered by human interaction

00:17:07

and which parts are covered by the app or the system automatically.

00:17:12

Fifth, you need to prioritize. Now, this is easier said than done.

00:17:20

So, you have to prioritize what is to be included in the app or in each app if there's more than
one being considered, and it needs to be based on the impact.

00:17:29

So you want to make sure not to recreate the same problem of the mega-transaction.

00:17:35

Prioritize those tasks or outcomes which are most valuable for a particular outcome well
avoiding otherwise less important features from being in the same app.

00:17:46

Sometimes we refer to this as feature creep. You don't want to have bells and whistles and lots
of extra cool things that something can do

00:17:53

if really 80 per cent of the time the user who's using the app really only needs to do something
very specific and there should not be any noise or other stuff in the app.

00:18:06

Sixth, once the app or apps are identified, then it's best for each app to create a statement like
an elevator pitch for a start-up.

00:18:16

What's the purpose of the app? Who's the target audience? Why are you going to be
successful? What are the differentiators?

00:18:22

And then this is where it really gets fun. If you wait to this point this is where you get to start
playing with mock-ups and making it look and feel how you want it to look and feel.

00:18:33

But you kind of have to do your homework and go through some of these steps before you can
get to that final step of actually worrying about the look and feel.

00:18:43

So, I want to make a final point on this section before we close out this video.

00:18:48

So from the process outlined here, please don't get the wrong impression that this is long and
linear and really complicated.

00:18:54

It really doesn't have to be, especially for the purposes of this challenge.

00:18:59

In the SAP Fiori UX Challenge Tips and Tricks video, the other video, we're going to cover the
best way or approach this process

00:19:06

within the context of how to, you know, get results very quickly and be able to submit
something for this design challenge.

00:19:15

So remember it's not meant to be... This whole approach is not meant to be comprehensive or
tailored towards designers only.

00:19:23

Really anybody can take advantage of this, it's pretty easy to grasp once you get the hang of it.

00:19:30

So, that brings us to the end of this video, SAP Fiori UX Design History and Overview.

00:19:37

And now you know more about not only what makes up SAP Fiori UX as a concept, but how
and why it came to be the approach used by SAP to create Fiori apps.

00:19:49

So be sure to check out the SAP Fiori UX Design Challenge Tips and Tricks video next

00:19:54

for more specifics on the challenge and how best to leverage what you've just learnt here in
this video to get started on your submission.

00:20:01

We promise we'll help you through the whole process. It'll be fun and breezy and thanks for
listening. Good luck on the challenge.

TIPS AND TRICKS

00:00:13

Welcome to the SAP Fiori UX Design challenge. My name is Bob Caswell and I'm a product
owner focused on the user experience topic at SAP.

00:00:23

My goal with this video is to walk you through the SAP Fiori UX Design challenge details,

00:00:28

and show how best to leverage the resources made available to you as part of your
participation in this challenge.

00:00:35

This video is meant to be watched along with the other optional video SAP Fiori UX Design
History and Overview.

00:00:43

Both videos are here for you as preparation for your participation in the SAP Fiori UX Design
challenge.

00:00:50

You can watch them in whichever order you prefer, and neither one is required for you to
participate,

00:00:56

but it's strongly recommended that you watch them both, starting perhaps with the other one
first the SAP Fiori UX Design History and Overview

00:01:05

because it provides helpful context into the how and the why SAP Fiori came to be.

00:01:12

In the first place with an overview of the design approach that SAP used to create SAP Fiori.

00:01:18

Both videos together are designed to give you enough understanding for you to feel
comfortable submitting something for this challenge even if you have no previous design
experience.

00:01:27

This is meant to be open for anyone interested.

00:01:30

So, let's talk about the challenge just a bit more before we dive in.

00:01:35

What is the SAP Fiori UX Design challenge, and why exactly are we doing it?

00:01:40

Well, as you can see, we've put together a great openSAP course on Fiori UX, and it covers
more of the deployment and configuration side.

00:01:50

But actually, there's a whole design team at SAP that focuses on making sure that SAP Fiori
UX is and continues to be a great best-in-class user experience.

00:02:02

And SAP is increasingly interested in sharing how we do this, so that anyone interested can
get involved in this new and fresh approach to user experience for SAP products.

00:02:14

So while SAP provides hundreds of Fiori apps for deployment and configuration and that's
the main focus of the openSAP course here

00:02:23

many of you may just be curious or have a need to understand also the design side,

00:02:29

so that you can also think about how you might adapt with SAP provides you,

00:02:34

or maybe create your own SAP Fiori-like apps for your own unique scenarios not covered by
the apps that SAP gives you to start with.

00:02:43

So here is how it's going to work.

00:02:45

You can watch this video and the other video, they're both meant to be informational but also
helpful for the context of the challenge.

00:02:54

And also, we're going to provide additional resources that you should check out, they'll be in

the SAP Fiori UX Design challenge section of the openSAP course.

00:03:04

And you're also be given an SAP Fiori prototyping kit, among other resources.

00:03:10

And this kit is a nice and easy way for you to be able to drag and drop Fiori-like graphics to
mock-up or design apps.

00:03:18

It comes in a PowerPoint format, we'll look into it a little bit later in this video.

00:03:22

So I'm going to spend the rest of this video showing you some of those resources and
highlighting briefly an example of how SAP went through

00:03:31

this same design process to create one of the original Fiori apps. And once you understand the
context and philosophy behind Fiori, which is covered in the other video,

00:03:41

and then you see some of these resources in action in an example, which is covered in this
video,

00:03:47

then you'll be ready to give a go at playing around with Fiori design

00:03:51

picking a scenario, any scenario you're interested in involving SAP transactions, and creating
your own mock-up or description of what you think would be a great user experience.

00:04:03

So I recommend you start with a transactional scenario when you do this exercise.

00:04:09

Something that's like submitting or managing or viewing an approval or a leave request or a

sales order.

00:04:17

If you're watching this, you're probably at least somewhat familiar with some SAP system. So,
just think of something that's task-driven.

00:04:24

And maybe think of a process you know everyone at work or that you personally

00:04:29

require to do daily or regularly, and that you kind of hate doing, because of how cumbersome
or difficult it can be to accomplish.

00:04:38

Once you have that in your head or you take some time to think about it, then disregard all of
the systems, the coding, the back-end structure, and all those complexities,

00:04:48

and just focusing your mind on the design, the experience, how you think it could be improved
in terms of its look and feel.

00:04:56

And what the front end should look like, what the end user perspective should be in an ideal
world.

00:05:02

So that's where we want to start, and we want to see if you can design and mock-up
something friendly and delightful for that otherwise hated and dreaded task that you might
have thought up.

00:05:15

So, let's first review something covered in week 1 and in the other video these are the five
SAP Fiori UX Design principles.

00:05:25

And for the purposes of this design challenge specifically, as covered in the other video, don't
focus too much on responsive and coherent.

00:05:34

And what I mean by that is all SAP Fiori apps are responsive, which means they work equally
well on desktop computers or mobile devices.

00:05:43

But whatever you come up with, your submission doesn't have to show that. You can just, you
know, pick one or the other desktop or mobile scenario and not worry about showing it in

multiple formats.
00:05:54

And as for coherent, that means providing a fluent, seamless experience, and all SAP Fiori
apps adhere to that principle.

00:06:05

Your mock-up or description of your experience that you want to highlight just needs to be
coherent relative to itself, so consistent and coherent with whatever you present.

00:06:18

You'll see later as I demo the Fiori, the kit, the prototyping kit. You're welcome to use the look
and feel of Fiori,

00:06:26

but if you want to show something on your own that you've done,

00:06:31

you're welcome to do that too, but just try to make sure that it's intuitive and it's consistent with
itself, and it makes sense.

00:06:38

The choice is yours however you want to leverage whichever resources.

00:06:43

And of course, delightful is another pillar here, and it's all about connecting with the end user,
and creating this enterprise app-like experience that

00:06:55

could be or should be considered just as friendly and enjoyable as a consumer app would be.

00:07:00

And last but not least, role-based and simple are covered in detail in the other video the
Design History and Overview of Fiori.

00:07:09

And they require some more focus. And you should check out the other video, specifically for

00:07:16

how you go about determining how to make your experience more role-based and simple.

00:07:22

It's basically showing what exactly a specific user or a use case for that specific user would be
like

00:07:30

without showing any other noise or extra features that otherwise sometimes show up in
traditional software.

00:07:39

So, one more review slide from the other video.

00:07:43

Shown here is the process we recommend for deriving and designing apps.

00:07:49

And I'm not going to go through all of these steps in detail again, but rather just wanted to call
out some of the areas that might help you as you go through the process for your own
submission.

00:08:00

So, what that means is for each of these steps, do what you can to research and validate the
approach you're taking,

00:08:08

but it's also absolutely fine if you don't follow these steps exactly, or if you make some
assumptions and

00:08:16

do your best to come up with the scenario that you're wanting to showcase.

00:08:21

So the first step is to start by explaining or showing which market you're targeting, so which
industry is your app designed for or your experience.

00:08:31

And explain how that might influence the design.

00:08:35

The second step is, once you have the market defined, it's best if you can engage with your
end users.

00:08:41

Maybe you're the user, you have experience with this scenario or experience you want to

10

showcase to make better.

00:08:48

You want to engage with end users to understand what their business reality is, and what you
can do to help from a user experience perspective.

00:08:56

So try to explain or show how the organizational structure, the stakeholders, the tools, the work
environment,

00:09:05

how all these factors influence what this user either yourself or whomever wants to do with
this particular task you've chosen.

00:09:16

And based on these findings or assumptions, you can capture insights, and then create what
we call personas,

00:09:23

which can help tell the story about your user and use case. A persona is just another term for...

00:09:30

a placeholder for a user that represents a particular type of user or group of users.

00:09:36

And we have a template for you that you can use for this part. You don't have to, again, but if
you want to explain how you do this differently.

00:09:45

In fact, let's take a look at this template.

00:09:48

So this is an example persona, filled out so you can see the key aspects of a particular user.

00:09:55

So this is, his name is Jack. You see his background: He's 34 years old, he has a Bachelor of
Accounting, some experience, manages a team.

00:10:03

And this just helps tell the story, you know, it explains his job responsibilities. The needs what
he is focused on.

00:10:13

There's a section for pain points, what, where he struggles or where systems really break
down and don't do what they could do for him.

00:10:21

What his goals are in his career or job. And then who his stakeholders are, who he works with.

00:10:27

And then you see in the bottom right kind of this cool little slider spectrum that just helps you
contextualize what kind of user this persona is.

00:10:37

Is Jack more of a casual user or is he a power user? Is he proactive or reactive? Does he work
as part of a team or is he more of a lone fighter_

00:10:46

No, none of this is required or mandatory for going through the design process necessarily,

00:10:53

so you don't, you can be as detailed or not as you seem fit for your case.

00:10:59

This is just to help you frame the character, if you will, in the story you're telling with the
experience that you want to highlight and show how it can be improved.

00:11:10

It's always good to know up front who the person is that would use the app you're designing or
the experience you're going to improve.

00:11:19

And why and what are all the factors involved in their average work life day so that you can
show that.

00:11:28

So here's the template not filled out, and you can feel free to use this template or capture this
information in the process whichever way is best for you.

00:11:39

So let's go back to this recommended process.

00:11:44

So step number three is creating storyboards or a process model to show the end-to-end

11

process
00:11:52

that this particular persona will go through to accomplish their task easily and effectively.

00:11:58

And as we just saw, there's no right or wrong way to show it or explain it.

00:12:05

The persona template helps you show the persona. You can simply describe in more detail.
You can write it out with text, or you can graphically show with cartoon/comic strip characters.

00:12:18

But however you feel comfortable, there's nothing fancy required. The important thing is that
you just need to think about how this user

00:12:26

goes about interacting with this experience or this task you have chosen.

00:12:31

And just tell or show the story, the steps in the process that are covered end to end for this
particular task that you try to accomplish.

00:12:39

The fourth step is what we call the tasks and an app abstraction process for defining the app.

00:12:45

Now it's not nearly as complicated as it sounds. Basically, this is where you explain or show

00:12:51

which tasks or parts of the process defined should be automated, or will be automated by the
system

00:12:58

versus which part of the experience require human interaction or inputs.

00:13:03

The fifth step is to organize all of these different tasks that are part of the experience you're
documenting.

00:13:14

So you need to prioritize which are to be the main focus of our app. Which features are
relevant for the particular task in hand_

00:13:22

Why does...how is this made simple and more delightful by, you know,

00:13:28

getting rid of all of the noise that's not associated with the task that you're trying to create a
new better experience for.

00:13:35

And then finally step 6. Once you've nailed down the focus of your app, you should create a
statement like an elevator pitch for start-up.

00:13:44

What's the purpose of the app? What's the target audience? Why or how is it going to be
successful, and what are its differentiators?

00:13:50

And this is where the real fun begins. At this point, you're ready to start marking it up and
making...playing around with what it could look like.

00:13:59

So now we're ready to look at the additional resources you have for the mock-up process.

00:14:04

And by the way, a mock-up isn't even necessarily required. If you are a little shy when it comes
to drawing pictures or using graphics,

00:14:12

we're going to try to make it easy for you, so you can drag and drop objects you'll see.

00:14:17

Or if you so choose, you could just write it out and tell a story with words, but sometimes
pictures can often convey more and

00:14:27

show more, but I just want to point out that's not the only way to tell your SAP Fiori UX story as
part of the submission.

00:14:35

Also, there's no requirement that you have to focus or describe your approach for each of
these six steps equally.

12

00:14:43

It's really up to you to highlight as part of the user experience design story that you submit,

00:14:49

it's up to you to highlight what you want to showcase and what you want to show as in terms of
the improvement you're making.

00:14:57

So now let's go into a demo of some of the resources that are going to be available to you as
part of this exercise.

00:15:06

So first let's take a look at the...rapid-deployment solution, that SAP Fiori Design rapiddeployment solution.

00:15:19

Now, this is an excerpt from that rapid-deployment solution, which was covered in week 1

00:15:24

where to find it and what exactly it is. But essentially, this is a set of best practices for Fiori UX
design.

00:15:31

Customers, SAP customers have access to this on the SAP Service Marketplace, but we'll
also provide a link to that,

00:15:38

but we're also providing this excerpt directly inside of the openSAP course for your easy
access so that you can get started right away.

00:15:46

So let's look at a quick preview of what's included in this guide.

00:15:51

You can see it's organized here based on the principles to start, which we've already covered.

00:15:58

Then there's a little bit on the App Framework, they're a very common terms in SAP with SAP
Fiori apps.

00:16:04

Most apps are either a full-screen app or a master/detail app. I'm not going to go into that level
of detail here,

00:16:12

but it's documented based on whatever task or scenario you choose to highlight.

00:16:18

You can determine which type of approach is most appropriate, and there's even a section in
here that says when to use which template.

00:16:28

And then there are different application types that are documented throughout this set of best
practices.

00:16:32

And if you look like at the self-service app, it explains what type of scenarios or tasks a user
typically does

00:16:43

via this type of app, via the self-service app, and shows a screenshot.

00:16:47

So you can review what these different app types are, and figure out where your task or
scenario best fits in this paradigm.

00:16:57

And then there's also some other sections, you know, in the Patterns, you can see here in the
About, Settings, and Logout.

00:17:04

You get an idea of how there's this coherent and consistent approach all Fiori apps: You go to
the same place to log in or log out of an app, or go to, you know, Settings or whatever.

00:17:15

Things are very logically organized, so you want to review some of how that's put together.

00:17:24

Again, you don't need to worry too much about making it perfect. This is just to show you how
SAP went about this process,

00:17:33

and how you would go about this process yourself if you were wanting to make sure that your

13

experience is delightful and usable by users in a consistent and coherent way.

00:17:42

So, enough on this particular guide. This will be for your reference, this set of best practices.

00:17:48

The other component I want to give you a quick overview of is the prototyping kit.

00:17:54

Now what the prototyping kit is is nearly a hundred slides inside of a PowerPoint file, which

00:18:02

are a bunch of graphics that you can use freely to mock-up your own Fiori-like experience
based on the task and scenario you've chosen.

00:18:15

So, as you scroll through here, you'll see things that look very much like a Fiori app. And they
almost look like a screenshot,

00:18:22

but if you actually click on any of these items, you'll notice that each of these graphics are
independent objects.

00:18:28

And you can move them around, mix and match them, put in different text very specifically.

00:18:34

It gives you some starting points. And from these starting points, you can really make it your
own

00:18:40

without having to start, you know, with a blank canvas. That's why this prototyping kit is so
useful is it really gives you a nice playground to sort of

00:18:50

mix and match some of these Fiori components that otherwise would be very difficult if you
started with a blank piece of paper.

00:18:59

So, you have some of these examples of different types of Fiori apps, and sometimes there's a
list view.

00:19:08

Sometimes, you'll see here based on the type of task being accomplished, this is like a
process view that shows you

00:19:18

some icons that show how you would click on each of these different icons to show a different
stage in the flow of this particular task that a user would be doing.

00:19:30

And so I'm just highlighting this, so that you're aware of why this is here and how best you can
leverage it.

00:19:36

You should just do a quick perusal of these slides and pick out the ones that seem

00:19:42

most relevant and applicable to the task or scenario you're interested in, improving in your own
business environment or interactions with SAP systems,

00:19:52

and then sort of start from these examples to get ideas for how you would showcase how your
scenario could be improved.

00:20:02

Here's one for filling out contact information. I mean pretty much for creating forms so many
different scenarios are covered to get you started with creating your own mock-up.

00:20:16

So with that, let's jump back to the presentation.

00:20:23

And I want to give you a quick example of how SAP went about

00:20:33

creating one of the original Fiori apps using a very similar process that we're showing you here
in these videos.

00:20:42

So, first the decision was made to focus on the manufacturing industry for this particular app.

00:20:52

And it's no secret, it's the Create Sales Order app. This is the example I'm going to show you

14

here.
00:20:56

So it was decided that SAP would first focus on the manufacturing industry and the B2B
business model.

00:21:03

And this is because it reflects the most common business requirements for the SAP instal
base.

00:21:09

Later, there are a lot of phone interviews done and meetings with end users and customers.

00:21:14

And there is a brainstorming meeting where the entire process was written out.

00:21:19

And in this example, there were several roles involved including the customer buyer, the sales
rep, sales operations,

00:21:27

warehouse clerk, accounts receivable agent, and many others.

00:21:31

So this was mapped out, yours doesn't have to be this complex. This is just an example.

00:21:37

And other experts for leverage, to validate, and double-check these scenarios.

00:21:43

And it was then determined that some tasks would be performed by human being,

00:21:51

and some others would be automated. So all the human tasks, as we discussed earlier, had to
be identified and given a brief description.

00:21:59

What's the purpose of the task? What is the primary persona or user for this task? Who are the
other stakeholders? What's the trigger point of the task?

00:22:08

Those sorts of questions. What's the context for the user when they're performing the task
cause sometimes the user might be in an office environment or sometimes they might be
traveling.

00:22:18

The next thing done was grouping of these tasks based on the similarity of the different user
requirements.

00:22:27

The conclusion was that multiple apps with different designs would be needed for different
personas who are otherwise interacting with the same transaction.

00:22:36

So it ended up becoming three apps identified for five different personas.

00:22:41

Of course, all three apps were developed at once. Some prioritization was required to
determine which would make the most impact additionally.

00:22:48

So questions were asked like: How many users does this impact and how often?. Can we
significantly improve the user experience by creating this app?.

00:22:57

It was decided that the sales rep app would be the top priority in the initial release, and the
other apps were to follow soon after.

00:23:04

And then lastly, the elevator pitch or value proposition was written out for this first app.

00:23:10

So, now when you go and play with any of the Sales Order Fiori apps, you'll have a deep
appreciation for how they came to be.

00:23:17

And with that, I wanted to end with a quick overview of this design challenge and the
expectations.

00:23:24

So each submission is going to be reviewed with the following rubrics:

00:23:29

It's going to be reviewed on creativity, simplicity, and delightfulness.

15

00:23:34

So, by creativity I mean how effective are the submitted materials in telling the story of the
scenario chosen,

00:23:45

and then showing how Fiori UX design and these principles could improve that scenario.

00:23:51

For simplicity, the question is going to be asked: Does the proposed solution follow the Fiori
UX philosophy of focusing on what's important with one fluent, seamless experience?.

00:24:03

And then for delightfulness, how much does the new experience shown create a connection
with you?

00:24:10

That is with whoever is reviewing this. Does it seem like it could be as delightful as your
favorite consumer app experience?

00:24:19

So as explained on the challenge page on the openSAP course landing page,

00:24:25

all submissions need to be five pages or less, or they can be five minutes of video or less,

00:24:31

or some combination of the two where one page of submission equals one minute of video
submission.

00:24:37

So what that means is you could submit three pages with a two-minute video or one page with
a four-minute video,

00:24:42

as long as it adds up to five or less. So you could submit all pages or all video. The choice is
yours, you don't have to use one format or the other.

00:24:50

And also don't feel like your submission needs to be longer, you know, five pages
automatically means it's going to be better.

00:24:58

It could be that you need to use all five pages or five minutes, but it's a maximum, it's not a
minimum. You can tell your story

00:25:04

in as little or as much time or space as you need in that five-page window or five-minute
window.

00:25:11

The other choice that's yours is how much you want to leverage the prototyping kit.

00:25:16

As I already mentioned, it's here for your benefit, but this challenge isn't about,

00:25:23

you know, who of you can show how well you adhere very specifically to SAP's, you know,
fonts or colors for Fiori.

00:25:33

Rather the challenge is more about how you show and tell a story about how you used the
SAP Fiori UX design principles outlined throughout these videos.

00:25:42

You don't have to use the prototyping kit at all if you prefer not to.

00:25:46

And really, the submission requirements are ambiguous on purpose, because we want you to
be creative and show us how you interpret this design philosophy,

00:25:54

and how can help you create a more simple and delightful experience with whichever task or
experience you want to highlight that is in need of this kind of renovation.

00:26:05

So you choose which parts of the process, which parts of the story and which parts of the
outcome you want to share as part of your submission.

00:26:14

And you also choose how you want to share them in terms of video versus text versus
graphics and mock-ups.

16

00:26:22

Please be sure to upload your work by the deadline of October 20th. And in the next phase,
three peers are going to rate you anonymously.

00:26:32

And you'll also be asked to rate the work of three of your peers based on the rubrics that I
previously covered.

00:26:40

And then based on these ratings, you'll get additional bonus points. And then lastly, SAP
experts will review the best submissions, and define and announce the three winners.

00:26:50

If you have questions or want more details on this process, check out the SAP Fiori UX Design
challenge page.

00:26:56

And if you still have questions after that, we have a dedicated discussion forum in the design
challenge section, where you can feel free to ask follow-up questions.

00:27:05

For now, if you've gotten this far, let me just say thank you for listening and good luck with the
challenge.

00:27:12

I'm looking forward to seeing what you are able to come up with.

17

www.sap.com

2014 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form
or for any purpose without the express permission of SAP SE or an SAP
affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an
SAP affiliate company) in Germany and other countries. Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for
additional trademark information and notices. Some software products
marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in
the express warranty statements accompanying such products and services,
if any. Nothing herein should be construed as constituting an additional
warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue
any course of business outlined in this document or any related presentation,
or to develop or release any functionality mentioned therein. This document,
or any related presentation, and SAP SEs or its affiliated companies
strategy and possible future developments, products, and/or platform
directions and functionality are all subject to change and may be changed by
SAP SE or its affiliated companies at any time for any reason without notice.
The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking
statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which
speak only as of their dates, and they should not be relied upon in making
purchasing decisions.