2. Do not ignore the Material grid & keylines

The visual part of Material Design is inspired and strongly based on the principles of high quality print design. The ink’s role is to express the content while giving it order and hierarchy, just as the paper does to the structural level that holds that content. And besides inheriting the principles of print design, Material Design adopts the same tools — grids, keylines, the savvy use of typography and imagery.

One of the key elements that makes an app aesthetically pleasing and much more intuitive is the use of grids and keylines.

To put it simply, a grid system is a structure made of a series of horizontal and vertical lines which intersect and are then used to arrange content.

In the mobile world context, an appropriate use of the grid will make the UI balanced, ordered, rhythmical, harmonious and easier to understand and to interact with — and this happens because the grid system helps to design accordingly to some important Gestalt principles, like the law of proximity (humans perceive objects that are close to each other as forming a group) and the law of good Gestalt (we tend to perceive different objects as grouped together if they form a pattern that is regular, simple and well-ordered, finding a meaning in such structured scenes). The best part? We just need to let ourselves to be guided by the grid, using white space to express groups and sections — no suffocating boxes or lines needed!

In Material Design, the various UI components are sized according and aligned to a 8 dp grid, while text uses a smaller 4 dp grid.

Keylines are used in tandem with the grid system to enforce the sense of a well ordered UI and to help the user to easily scan the screen — their goal is to align and spacing properly the UI components in a coherent manner, vertically and horizontally.

Material Design suggests a number of vertical keylines to determine the placement of elements from edges of other elements, specific vertical sizes for content blocks height and horizontal margins for spacing appropriately the components laid on the screen.

At very least, you should consider three fundamental vertical keylines and the basic heights for the most common UI elements like items list (tiles); here there are these specs for smartphones — but remember that they should be coupled with other factors like text size, presence of subheaders and so forth. The Material Design specification will be super handy in this case, and the sticker sheets provided by Google are a really great time-saver.

Three basic vertical keylines

From the left and right edges, a vertical keyline at 16 dp for auxiliary content, like icons or avatars;

From the left edge, a vertical keyline of 72 dp for the main content, such as the App bar title and the main body content when supported by auxiliary items; otherwise, the main body content should be aligned to the previous 16 dp keyline;

Three fundamental vertical keylines used in Material Design. Dimensions are expressed in dp and are valid for smartphones.

An example of content blocks height

A height of 48 dp for list elements with a single line of text, that becomes a 52 dp height when auxiliary components are also present; add 8dp of padding at the top and bottom of the list, except for lists with subheaders;

A height of 72 dp for list elements with two lines of text, with or without other type of content; align icons and/or avatars with the compound text area; apply the 8 dp padding as the example above with the same restrictions;

A height of 88 dp for list elements with three lines of text, with or without other type of content; top-align icons and/or avatars with the primary text and apply the 8 dp padding to the list as in the first example with the same restrictions;

That said, please give a sense to your app’s UI and do make use of the Material grid system and at least of its fundamental keylines and spacing suggestions; don’t be afraid to make your content breathe, using wisely the white space suggested by the grid. Because as we have seen, it is not just a matter of aesthetics — in design, it is never just about making pretty things.

Pro tip: use a dedicated app to check how your own xxapp aligns to the Material grid and keylines. Here you have a couple of interesting tools to use for free!

3. Do not make surfaces vanish into thin air

Motion is the third pillar of Material Design. Once having defined the metaphor of paper and ink and its visual expression and behavior, motion provides meaning: it makes surfaces dynamic, expresses the energy imprinted by the user to the paper during interactions, guides the focus, gives hint about what is going to happen and explains what’s happened after an interaction. The feedback that motion provides to the user it’s a visual reassurance, starting from the humble ripple originated by the user finger touching the screen. Long story short, Material Design is alive and its motion is always meaningful, giving visual expression to what the user did.

“M otion is meaningful and appropriate, serving to focus attention and maintain continuity. Feedback is subtle yet clear. Transitions are efﬁcient yet coherent” — from Material Design Guidelines

I know: Material motion, inspired by natural motion, it’s hard to design and to implement. Ideally, the user should perceive an app like a continuum, a unique scene where the paper UI moves, morphs, expands to create structure, while ink flows over surfaces to reveal content — all in a perfect, coordinated and graceful ballet. And even if the SDK has some tools that we can use to start with simple things, good motion is still hard to achieve.

Remember that simple but well done is much better than complex but useless, confusing or an end unto itself — meaningful, remember?

So please stop with the cascades of components flying across the screen without a purpose — I mean a purpose besides having things moving around — and remember that the barely fact that some components are animated is not expression of Material Design.

Another perl we see a lot these days is the pop-the-component-in-or-out-in-a-snap. Now, while it’s true that sheets of material can be generated and destroyed [1] at any time, anywhere, they don’t just disappear in the blink of an eye. A surface can shrink to the point where it doesn’t exist anymore, or expand to fill the entire screen losing its identity; it can move out of the screen or merge with another surface, it can morph or split or heal. But it will never vanish or fade away in front of your eyes [2]. A sheet of paper is solid, impenetrable, tangible and behaves according to its properties.

The same concept applies to the entire screen (or Activity for the tech guys): no screen should just pop in from the void.

To arginate this busy mess, here some pinpoints to follow:

Always remember that Material motion is natural, responsive, clear and — overall — intentional.

When an element moves within the bounds of the screen, it follows a natural curved path

Never forget to use interpolators, because linear movement is really unnatural and ugly to look at; use the right kind of movement depending on whether an object is moving within the boundaries of the screen or if he is entering or exiting from it. And don’t forget about the new curved motion to be used when a component moves between two points within the bounds of the screen!

Even if you don’t want to dive into the new Transition framework, at least spend some time on building decent Activities transitions: in general, it’s best to use translation animations instead of the old crossfade animation.

Try to implement Shared Element Transitions when you have the opportunity: that is, when switching from a screen to another, both holding one or more views in common — think of the usual case of a media player, where the first screen is a list of albums with their relative covers; the detail screen for each element will have the same image, maybe bigger and used as part of the App bar. During the transition, this shared element (or hero element) will seamlessly animate between the two activities, guiding the user eyes while expressing clearly what’s happening — without any sudden change. [3]

If it’s not feasible for you to treat the different Activities as a unified, single choreographed stage, at the bare minimum you should try to express the relationship between these screens: use vertical slides animations for parent-child relationship or top-to-bottom navigation, and lateral translations for sibling relationship.

Never make any animation or transition too long or too short: try to find the right amount of time fiddling a bit around your code, and remember to take account of the size of the object you are moving, the distance it has to cover and the cause of the movement itself — is the object leaving the screen forever or is it just peeking in to remember the user of its existence? Also, is fundamental to calibrate timing according to the device you are targeting. As a rule of thumb, for handheld devices you should never go over 400 milliseconds for any animation — try to remain into the 195 / 300 milliseconds range.

4. Do not use Cards everywhere — they are a distinctive element, not the foundation of the whole Material system

Let’s be clear here: we all know that the card component was a kind of a prolepsis of Material Design, and that it was among the first Material components to be implemented long before 2014. And we all know that cards are fabulous elements to contain chunks of information (like on Google Now or on Android Wear) or content composed of different elements, like images and text and buttons. They are beautiful when showcased in lists or grids, especially when the content they hold is rich and vibrant, and it’s a pleasure to look how they gently scroll across the screen. They are perfect to layout elements that can respond dynamically to the screen size.

But that’s it.

Cards have their own purpose and they are not suitable for every scenario where we need to display data. Nope, they are not the panacea for every design problem: when misused they end up being a cognitive hindrance — a beautiful one, but still a clog.

So please use cards only when the content you have to display calls for them, such as:

a collection of heterogeneous elements or data types: text, images, graphs and so forth;

a collection of elements with interactive content, such buttons, sliders or checklists;

a collection of elements whose content has variable height or dynamical length that can possibly grow over time (think of a card holding an image subjected to users comments);

not-so-much rich content that has to fill the entire screen.

The case when you never should use a collection of cards is the one in which the user has to scan a list or a grid of homogeneous elements on the screen to compare one element with to another until he finds the data he was looking for. Ring any bells? Yep, I’m talking about the dear, old scrollable list of items — like a list of contacts, places, options and…. You name it.

Do not — I repeat — do not replace tiles with cards in these scenarios. Are you asking why? Because a list of tiles — a glorified table, if you want — is much easier to scan than a list of cards; and in a grid of images tiles, it’s easier to find the one you are searching for than in a grid of cards; in both cases, the problem is that the card contains the elements you are scanning, adding space, visual noise and increasing the overall cognitive load of the process: instead of a linear, seamless top-to-bottom scanning, the user has to literally jump from card to card because of the chrome that surrounds the data.