Of all the responsibilities of a designer, the one that clearly tops ‘a boon and a bane’ list is adhering to the guidelines. You create, borrow or adopt a design language with the best intentions to diligently follow the guidelines. Things go all fine and dandy in the beginning, but then, you come across a context that the guideline book didn’t consider about and you hit the wall. You almost imagine that heavy design bible tome fall face first on a cold hard marble floor. Don’t be alarmed. Design guidelines were never meant to solve your UX problems in the first place. They were only meant to lead you to design a coherent system of visual components, interaction patterns and logical semantics.
At Squirro, we jumped on the Google’s Material design bandwagon quite early on. Arguably, a wise decision as it allowed our design team to focus on the user experience instead of general discussions around guidelines. Material design is definitely one of the most elaborate design guidelines out there for web and mobile apps. But let us skip the niceties and fast forward to the story where we had to break some rules of the design guidelines. The team was tasked with redesigning the entire Squirro application with Material design. One of the big pieces to redesign was the dashboard editor UI, a drag and drop tool that allows the users to build their own Squirro dashboards. While the old UI was nothing to write home about, the new editor, after the initial basic implementation of material design styling, was harrowing to say the least. It failed at many levels and left us with a learning to stop stalking and start following the design guidelines.
Squirro dashboard editor: Old design
Squirro dashboard editor: New design
We learned a few things and broke a few rules. My 5 takeaways from the dashboard editor UI re-design:
- UNDERSTAND THE USE
- KILL THE NOISE
- REDUCE EFFECTS
- BOX IT
What makes a Dashboard editing UI different from any other UI? The use. It is a playground with multitudes of tools at your disposal which allow you to build meaningful dashboards. Look at all well designed dashboard editors with gazillions of tools. They all share one key attribute: Compactness. It eases the scanning of the available options and brings in the affordability to easily switch from one option to another given that the options are also laid out with some logical order in mind. Interestingly, even in the physical world, the same attribute is used to lay out the tools in a toolbox. Rule broken: We ignored all previously defined spacings, paddings and margins in the design guidelines and went for a super-compact layout.
Again, coming back to the example of the toolbox, observe how similar tools are laid in a linear fashion in an ascending or descending order of the size of the tools. In the new dashboard editor, we not only re-grouped the similar parameters of data configuration and visualization together but also ordered them linearly with the most relevant parameters at the top and the least relevant parameters at the bottom.
Variation brings structure. Too much variation brings noise. One of the main reasons, why not to use more than 2 fonts in an application. We have various font size definitions for the forms and list pages because there is enough breathing space to highlight hierarchy in the content. With the constrained screen real estate available for the dashboard editor, we decided to kill the noise created by different font sizes and go with a single font size of 11 px. Besides, it also made space for more content to be displayed.
One marvellous thing about Material design is that it takes care of the motions and animations to accompany different UI elements in different use cases. One of the animations we use generously on all our form pages is the text input field animation.
Text input field animation (Source: Google material design)
You click on a field and the label moves up to make space for the text input. It is a beautiful confirmative transition which validates the intent of the user to fill some text fields in a form and hit the submit button. For a dashboard editor kind of compact interface, it is more of a distraction where filling few text fields is a small part of a giant task, the user is set out to do.
Imagine this for a second. You want to create a dashboard to show specific insights. You are already thinking about the most relevant data sources to select and the best visualisations to go with them. What else? You are also thinking about the lay-outing options. And don’t forget the different layers you might have to build. Last thing you want here is some animation at every click you make. That is why, our dashboard editor input fields have the material design animation disabled to augment the focus and concentration on the main task at hand.
One of the later add ons to the text input fields were the text field boxes. They are meant to ‘increase text field identifiability and scannability by using a rectangular fill to enclose the label and input text’ (source: Google’s Material design).
Text input field box UI component (Source: Google material design)
We took it a step further and used it not only on all text input fields but also on selection fields like radio buttons and checkboxes. The result speaks for itself. Still surprised to this day why Google did not use this beautiful element for styling their own data studio editor.
After having read the material design guidelines like a book, one thing I learnt quite early on is that design guidelines work the best for the solved problems. To solve the unsolved ones, go ahead and break some rules!