General rules of good interface
You probably heard about general concept of FIORI: role-based, simple, adaptive, coherent and delightful. To achieve delightfulness FIORI design guidelines were created and published (experience.sap.com/fiori-design/). So when UX designer is creating a new Fiori application he always follows these guidelines alongside customer requirements.
But following our design guidelines is not enough. Here are my 4 general rules for creating good interface.
Always pay attention to controls placement. General rule – the easier the better. Try to avoid complex constructions, different alignments and content overload.
You don’t have to be an expert in Russian or UX to see the actual difference between these 2 interfaces of the same app.
And there was no loss of information, just “cleaning” of the interface. The alignment was corrected, excess labels were excluded, form with unstructured fields was replaced with a table. And it made a huge difference already.
Also keep in mind the proximity principle. Label should be closer to its field than to another label or field. Here comes an example:
looks like a girl is a convinced felon and being escorted
looks like a guy looking at a happy couple
Words are the very big part of the interface. Even if interface is designed very good, but texts are written very poorly, there won’t be a great user experience. I defined 2 general rules regarding texts:
- Always review interfaces like you’ve never seen them before. And I mean always, even on intermediate steps – user might work with your application, then get distracted by urgent e-mail and then return and still should understand what he is doing, which step he is on. So review interfaces on each step separately and maybe even in different order.
What software exactly was installed?
- Edit all your content. Avoid words like “General”, “Additional”, “Data”, “Useful” etc. They don’t give any information to user, so try to replace them with something meaningful. Also do not overload him with technical information – he doesn’t need to know technical numbers and random codes to use application. There is a great post about texts, check it out, really useful: https://jam4.sapjam.com/blogs/show/JJWKY0oTV4ARTTRAfswfP8?_lightbox=true
3. System response
When you click on a button and don’t see any reaction you click it again. And again. And again. And that what normal person does. If you can’t see the reaction on your actions you think there is none. System response should be instant and continuous and then users will be happy and won’t click on buttons like crazy. BTW this is not only about buttons, system response is also required for clicks on links, tabs, table row and anything clickable.
I tend to use toasts messages and popups a lot in my applications as a response to button clicks. But this is probably not the best way to give response. Users tend not to read any warning popups and to forget that there was a toast couple of seconds later. If you have better solutions please share it in the comments below.
Modality is the quality or state of being modal. Interface is modal if it has different states and user doesn’t know which state he uses. For example, the home screen of your iPhone is modal – you have to actually pay attention to the icons to start the right application. There are different applications in the same places on different pages of your home screen, so you might start Shazam instead of App Store for example.
I know 4 different ways to solve this.
- Use a different gesture for each control. Like when you use a map in your interface scrolling affects different areas differently depending of cursor placement – zooming in/out while cursor is on the map and regular scrolling when it’s not. It could be solved by changing gesture for zooming in/out – adding CTRL button with scrolling, for example. Or using 2 fingers instead of 1 on touch devices.
- Show user what state the interface is. Great example of that is Fiori Launchpad in edit/display modes. You won’t be able not to see what state you are cause it was made so obvious (even in unknown language):
- Use quasi-mode. Make user pay attention to what he does. Good example of this is using SHIFT for uppercase instead of CAPS LOCK. CAPS LOCK creates modality, and using SHIFT creates a quasi-mode.
- Change the sequence of steps. This is a more complex decision that you probably should discuss with end users of your interface first cause it might change your interface exceedingly.
This is a missing competence in our ecosystem. Usability and Interface design is a required topic that should be more exploration. Thanks for sharing.
For all non-SAP employees, you might want to change the URL for the Fiori Design Guidelines from the "SAP internal"-URL to the General URL which is experience.sap.com/fiori-design/ I believe ...
Thanks for noticing, you are absolutely right. I'll change it =)
Regarding point one: I tried really hard to find a difference between the first and the second image (before and after: 2-3 and 2-4 png), but I found none. Was there some mix-up with the image upload? If the changes are very subtle it may be useful if you somehow highlight them on the second image.
Yep, my bad. I changed it now, so you can check it out and compare
Thank you, now I think that I understand what you meant by rearranging the information in the header, although the second image may be a bit confusing, because the header implies flight information, it has a list of products for purchasing in the detail list.
If I understood correctly the idea for restructuring the information at the bottom we will have a few categories on each tab with an option to navigate to detailed information.
My guess is that one category will be passenger details, another - aircraft details, not sure if additional items are needed - is this how the redesigned app should look like?
It is a strange choice not to show the information for the terminal at the header - is this meant to be in item detail? Probably I did not get the categories right, because I cannot decide to what item this should be allocated - my choice would be to show this in the header right below борт прилета/вылета (if available), but then it is a tough decision, because information overload is subjective. Apologies for the swarm of questions, but I am curious how you would handle this as once you start adding things in the header it is difficult to stop. 🙂
Unfortunately I only have semi-finished version of that interface, but you got the idea almost right.
The app was created for aircompany employees to monitor their aircrafts. They had to know data of the flights aircraft perfomed, have information about passengers that were transfered, maintenance service aircraft received and any comments that were left about that plane.
Redesign in the header area included deletion of excess information (couple of fields) and restructurazing remaining data. Redesign in body mostly was a transfer from form to table. Sadly I don't have a screenshot of final result, but I hope the idea is more clear now 🙂
You are absolutely correct, information overload is subjective, so is sense of beuty. So any redesign will be more effecient after talking to end users and finding their needs. This case is only one of the cases that could have happened and was mentioned to support my "the easier the better" principle 🙂