Creating the Zebra Technologies component library
As a designer, I love the Material design guidelines and use them regularly on my work. It is very well structured and easy to follow, but here at Zebra Technologies, we have seen some special use cases and requests where material components needed to be optimised.
For daily consumer use, the material design guidelines is comprehensive. We, on the other hand, needed to think about the enterprise users, the ones that wear protective gloves, use their devices in harsh environments, try to see their screens in bright sunlight or under rain. The point is, in enterprise, our devices are used in extreme conditions. We needed to make the overall experience easier for the people in the field. That’s why we decided to create a customised version for the most used components. The changes we made were subtle changes but it made a difference in the daily life of our end users whilst still keeping visual look and feel familiar with their personal smart devices.
Buttons:
We started with the buttons, as it was the obvious choice. It is what the users interact with most.
The standard button size was not big enough for gloved use so we already knew increasing the size would help solving the issues regarding touch area but we also made some other minor changes. First, we wanted to have sharper corners to move away from the consumer look as much as possible. This made the button a bit more serious but this is what we wanted. Then we increased the text size by almost 30% to have better legibility. After some initial testing, we found out that some users were still struggling to see this rectangle as an interactive button so we created another version with a chevron to emphasise the interaction. We decided to align the the text to left hand side on the chevron version rather than keeping it at the center to visually balance the button. The big versions were designed purely for gloved usage where the button was 25% bigger than standard buttons. We knew all this would mean fitting fewer items on the screen but we thought of this as an advantage because this would force us to think about the menu structure, place fewer items on the screen and simplify everything as much as we could.
Draggable floating action button:
We focused on the floating action buttons next, as they are a powerful component in the Material design universe. A floating action button represents a primary action in an application and is used for a promoted action. It floats above the UI and when pressed, it may contain more related actions. In Material design, the location of a fab is fixed but we wanted to give more flexibility in our version so we made it draggable to enable a customisable layout for the end user. They can drag to the left or right hand side if needed. The dfab (Draggable Floating Action Button) works above all applications, making it a powerful component, if and when needed.
We also introduced semi-transparency for dfab as the dragged location might obscure what was behind.
The dfabs helped both left handed and right handed people as the exact location of it was determined by the user, usually them most comfortable for their thumb.
Allocating more space for positive action:
Some actions will occasionally require confirmation from the user to move forward. List items and dialog boxes are good examples where you will be faced with two options from time to time. These are usually “Cancel” or “Confirm” requests. In most of our enterprise apps, we found out that the positive action is selected more than the negative action so we decided to make it bigger for our users. Here is how we allocated more space for “Confirm”:
This helps the end user not just because it is the recommended move on most cases, but also gives more space for easy tapping.
Lists:
We also had some cases where we needed to put more actions inside a list item. The gestures were good for the job but I had always approached gestures with caution. Without a hint, the user would never know that it was there. See the image below for standard material lists:
There is no visual clue about the gesture. This is how it works:
When you swipe, it reveals an icon and then the item disappears, meaning if you swipe fast, the list item disappears before you even realise what just happened. Some apps even use the swipe gesture for both sides with no hints at all. After seeing all this, I came up with the idea to put a color bar to the edge of the list item to give a visual hint that there was more. Here is how our swipe gesture works:
The swipe reveals options for the list item, rather than taking action immediately. This gives the user the time to see and understand the options. This way, I figured, the gesture would be less prone to errors and we can be sure that the following action will be taken with intent.
We went through many other components to make them even simpler to interact with. The end result is a Sketch library that we started sharing internally but as with many similar projects, design is never done and we are constantly adding new features and components to our library. This always evolving components library is at the center of how we create a better user experience for our users in the enterprise.
