There, the word is out: design! It’s often used for objects in the real world, but nevertheless it’s equally applicable in the virtual world, where it’s often also referred to as “user experience”. The connotation a lot of people have in mind when they hear the word design is “…something good looking”, “…something fancy”, or “…eye-candy”, while design is actually much more than that.
Creating a well-designed product – whether in the real or in the virtual world – is all about making your product easy to understand, easy to use and attractive to your target population.
- Easy to understand: the users need very little to no explanation. I really like the following comparison: “good design is like a joke: if you have to explain it, it is not that good”.
- Easy to use: understanding something is not the same as using it. People may have a perfectly clear image of what they have to do, but when they start doing exactly that, the required actions might not feel natural. This underlines the important difference between theory and practice.
- Attractive: this is the desired result of the previous bullet points. If people have an emotional connection with a product, they will for sure use it more often. When you hear people say: “I really love my car, new backpack, smartphone,…” you know they are eager to use it, there is a bond between user and product.
- Target population: understanding your target population is the key to reach all the above mentioned targets. One product can be a perfect fit for a certain population while totally useless to another. A good example here is a cellphone: younger people are used to smartphones with touchscreens and apps, and using the phone to make a call couldn’t be easier for them. But if you give the same smartphone to elderly people and ask them to make a call, they might not be able to do it.
Maximising end-user adoption in the cloud or on-premise
More and more the aspect of design is becoming a primary demand in software development, while in the early days it was often a secondary demand. Developers would say “The application works, that’s the most important thing!” , but later they’d say “Why doesn’t anybody use the application?” or “How come we spend more time and money explaining the application than developing it?”.
With the launch of Fiori, and with the recently announced improved Fiori 2.0, SAP has opened a new world for business software in terms of design, which can be applied both on-premise as in the cloud. For customers hanging on to their on-premise system, it is even possible to combine best of both worlds; running key applications in the cloud which consume business data from an on-premise back-end system.
There is still a way to go, but at least the journey has begun. The big challenge now is to really use the power of it and to deliver state-of-the-art well-designed software. The technologies are in place now, but the danger lies within the almost unlimited possibilities. Luckily there are proven concepts which can be used in the process towards great design: personas, storyboards, mockups and test-and-iterate.
- Personas are fictional characters based on real data to represent user types. They are extremely useful when considering goals, desires, and limitations of the users, and they really help guide design decisions. Personas put a personal human face on otherwise abstract data about customers. So, as you consider the type of application you want to create and the problem you’re solving, ask yourself these questions: “What are the characteristics of the users who are going to use this app?” “What are their tasks on the job?” “What IT touchpoints do they have?”, “What are their goals in the context of this scenario?”, “What triggers them to even start the scenario?”. Persona definition is possible through so-called “Need finding”: via research on user data, listening to your target population and defining their points of view you will discover their needs. Points of view are the briefest way of explaining why the application is needed. They are comprised of one sentence with the following structure: persona X needs Y because Z.
- Storyboards are a great way to outline the path the user will take to reach his or her goal. It will also give you a clear idea of where the opportunities for your application lie. And it will help you to think through the end-to-end experience the user will have using your application. To be able to set-up and understand a storyboard, the user experience journey is key. This is a very pragmatic way of working with (virtual or real) sticky-notes, which you group in 3 categories: the mindsets, the actions and the touch points. The mindset is the needs and thoughts the persona has to obtain his goal: “I need to book a course”, “Are there any available sessions left?”, “What a large course catalogue we have, I can’t find anything…”… The actions are the steps the persona will actually take: open the application, enter login and password, search for a course, check the sessions, book the participant, close the application. And the touch points are the ways of interaction and communication, such as receiving a mail after the course is booked, using a desktop and/or tablet and/or smartphone, viewing the course catalogue, getting a popup to confirm booking. Once the mindset, actions and touch points are defined, you can indicate the crucial elements. If you hear from your target population that they are frustrated with always getting lost in the huge catalogue you will need to address this in your application.
- Mockups are the logical next step. Before typing one letter of code, you need to get visuals. Here you start drawing screens and defining transition between screens. One of the best tools to do this with is a utensil invented back in the 18th century: the pencil :-). But there are also great virtual tools out there to help you, such as SAP BUILD (link).
- Test-and-iterate your visualizations with future key users. This has several advantages: first of all you save a great amount of development time (and money) because in this phase still no coding is needed yet. In other words, if changes have to made, erasing a part of your visualization will be a lot easier, faster and cheaper than making changes halfway through the actual development. A second advantage is that you start creating a relationship between the users and the application right from the start. If the target population feels they are a vital part of the process and that their needs are being heard, they will feel much more connected to the final application. Keep iterating until the mockup is ready for the realization phase.
Redesigning the standard SAP Fiori Leave Request application
As an example, at bridgX we redesigned the standard Fiori Leave Request application applying the above concepts. Below you’ll find two screenshots: the first of the standard application, and next of the redesigned application. You’ll immediately notice a lot of differences.
Screenshot: SAP Fiori Leave Request (by SAP)
Screenshot: SAP Fiori Leave Request (by bridgX)
- The flow: in the standard version you start on the top center to select the type of absence via dropdown. Next you go to the center left to select the day(s), center right for more details and finally to the bottom to send. This was experienced as too complex for some users, especially on big screens since the button bar is always at the bottom. In the redesigned version there are 3 clear blocks defined: “1 What?”, “2 When?”, “3 Go!” which offers minimalistic guidance. We also created a diagonal process without scrolling: the employee works through the screen in a more natural way from top left to the bottom right.
- The dropdown to select the type of absence is replaced by tiles. In 95% of the cases “Holiday”, “Illness” or “Parental Leave” were used. So instead of having to search every single time in the dropdown, these options are literally one click away. The use of icons and big tiles significantly improved the user experience, especially for the use on smartphones and tablets.
- The calendar has been reduced to one month to make the screen lighter, and the used/remaining days are made more prominent. This was considered key information the user wants to know: how many days do I have left to take?
- Often people request a holiday for half a day. Instead of using the hours for that, a selectable button is used: full day, part 1 or part 2. Very easy to understand and again only one click away. Notice also the part 1 and part 2 button have half the width of the full day button; without any explanation the user immediately understands the purpose.
- The blue color indicates a selected item: holiday, part 2, 25th. At any moment in time it is clear what will be sent, it’s clear in the blink of an eye.
- Less is more: the approver has been removed from the initial screen. In most cases the approver is known to the user. But if not, it will be shown in the confirmation popup: “Your request will be sent to your manager xyz for approval. Are you sure?”
- The sending of the request is a “positive action”, so the button “Send” is shown in green and on icon gives an extra clarification of the functional use.