As a mobile designer, I visit Google’s Material Design Guidelines website quite frequently. It has become like a recipe book marked with many dog ears, to which I can return any time a question arises, or a very particular ingredient is needed. In my first article on Medium (yay!) I would like to suggest several ways of working with the guidelines in order to create great products.
Having to rely on these guidelines at work, to keep my design consistent and platform-friendly, has allowed me to get familiar with the system to the point that I don’t need to refer to it as often as I used to during earlier days; I can simply choose the part I need, the one that is missing in the puzzle, and apply it.
I would not say, however, that all of the puzzle is made out of the material components. Nowadays, platform best-practices are becoming cross-platform — the FAB is seen on iOS apps, bottom navigation tabs are becoming best-practice on Android apps, and has even been included in one of the latest Support Libraries. The secret, as I see it, is having the best-practices in mind, and using them only for the purpose that is right for the current project, for the current goals. Never blindly repeating, the guidelines should not limit you in any way.
Speaking with several Android developers, it was interesting to discover they have a different view of the Material Design Guidelines. Some of them work at start ups in their early stages, some work in companies where the importance of design hasn’t quite sunk in yet. They use the guidelines as building blocks for the whole app. If we go back to the puzzle analogy, once the puzzle is complete, it will be obvious to the observer that it contains solely pieces that adhere to the material design guidelines. It has, one of the devs told me, everything you need to build a good app — color schemes, fonts, grids and components.
To argue that these guidelines cannot replace a UX or UI designer was not necessary, since we were all in agreement, and I understood the limitations they were facing. To illustrate the point they made, I created several screens using components fr0m the guidelines website:
So there are those who base the whole design of their app on the material design guidelines, and there are those who incorporate some of the components into the design. Both use components from the material design guidelines to a certain extent. However, there is a third option. In some cases, incorporating material components as they are out of the box will not work. Sometimes you need to learn the rules, and then break them.
Games are one genre of apps in which material design might not work, another genre is applications that are meant for children. Recently, while working on a personal project, I’ve had the chance to break some rules 🙂
Learn. Adapt. Repeat.
Meet CommBoards, an Android Augmentative and Alternative Communication app, for children with limited verbal communication abilities. My partner and I have been working on this app for the past two months, in order to help a friend whose child has autism, and provide him with an accessible, easy to use app. We released it to Google Play two weeks ago, and it was very exciting for us to see children beginning to use it.
When designing CommBoards, it was clear we had several limitations to consider:
- The interface had to be as clean as possible, since there would be many options for the child to choose from.
- The audience of our app will have a wide range of disability severities, hence the components of the interface would have to have large tappable areas.
- We initially planned to create the app for tablets only. However, research showed that many of our potential users did not have tablets, and so we had to make the interface work well on multiple screen sizes to support mobile phones as well.
Here is a wireframe of the CommBoards main screen:
And the image selection screen for creating a new cell:
From the first look, the main screen might look as a simple gallery of images, with short description underneath. For such a layout, material design guidelines suggest grid tiles:
“Grid tiles are a clean and lightweight way to present a gallery of images.”
However, each such pair of image and word are actually a button, on which the user presses so that the word is then spoken aloud. Tapping on several buttons one after the other forms a spoken-aloud sentence, allowing the child to communicate. So we broke the rules, and used cards instead.
Using cards allowed us to get elevation, rounded corners and shadows, for free. Adding these three elements to each cell made the cells look like clickable items, standing out from the screen and putting them first, in terms of hierarchy, placing the focus on the most important aspect of the app.
The rule breaking ordeal didn’t end there. In the image selection view, where a parent would select an image for the new cell they created, we wanted to offer a large bank of images, and a comfortable way of filtering between the images. Instead of using tabs to organise the different filters, we chose to use chips.
Being able to play with the size of this component, and making the filters look like buttons helped us create a consistent interface, the size of the button increased tapping area and the larger font size allowed for easier readability, all of which would not have been possible when using tabs.
Every product and project differs in the questions raised, the problems it is meant to solve, and the solution that is necessary to solve these problems.
As the designers and builders of these products, we must be aware of limitations, know best-practices and follow guidelines. But we must also be capable of breaking the rules when it is necessary, and learning when it should and shouldn’t be done is a process, not a magical solution.