Google recently introduced new guidelines for beautiful user interfaces called Material Design. Unlike frameworks like Bootstrap or Foundation, these guidelines are comprehensive enough for any kind of scenario, and let apps retain their own character. In his Øredev talk, Ben Hall explores the guidelines and how to implement them on both mobile and desktop. He looks at real-world examples, along the common mistakes and misunderstandings.
My name is Ben Hall, and I’m a founder of a software development studio called Ocelot Uproar. We help other companies build products, and we also build products ourselves.
One of the products we make is Katacoda, an online learning platform for developers. It includes teaching topics like infrastructure (Ansible, Puppet, Docker, etc.) and creating a beautiful environment so you can play and learn new technologies. We’re also working on BrownBag, an aggregation of conference videos in an easy-to-access format.
In this talk, I want to address some of the principles about why design matters, some key points about colors, icons, imagery, etc, and finally how to implement these guidelines into your own applications.
What is Material Design? (1:45)
Material Design is a very comprehensive set of guidelines by Google about how they implement their own applications, and how they design their own structure. It includes some great dos and don’ts about how you should approach various aspects of design in your applications, i.e. progress bars, feedback to users, and more. If you’re ever stuck and you need a third-party opinion, this is a great resource that you can go to, but you should also maybe take it into consideration when coming up with your design.
Fundamentally, it’s about taking a horrible, jerky experience and making it more fluid. This can be through nice little animations in corners of the applications, how it progresses through different slides, and how to navigate transitions. You can see this in applications like Google Now, where Google applies all of this. It’s just little touches, but as a user, it makes you smile and feel safer. Material Design is there to help you implement that.
People often think of it like Bootstrap from Twitter. The problem with Bootstrap is that it’s a framework, not a set of guidelines. As a framework, every single application looks and feels the same; you implement the CSS, you do exactly what they say, and you end up with something nice. Material Design is different since it’s the theory behind how you put things together. It’s about how you get websites which feel consistent and right, but also feel unique because the guidelines haven’t exposed a strict set of rules like frameworks do.
Why Does Design Matter in the First Place? (4:12)
It’s been proven that attractive things work better. There was a Japanese study which had two ATMs with exactly the same software, but they changed the user experience and how people engaged with it. The people who used the less UX-friendly version reported more bugs. However, since the software was exactly the same, there were no more bugs in either version, but because users had a jarring, awkward experience, they put it down to software bugs.
If we make things that feel cleaner and nicer, the bug reports will actually decrease because our software will match the expectations of what the user is assuming will be there. People have an emotional reaction with software, so we want to create a nice, warming experience. Certain websites feel confusing and noisy, with so much information that nothing that makes any sense. Instead of wanting to use it, you want to get in and out as quickly as possible because it’s not enjoyable.
Design also matters because we have preconceived expectations. As soon as you open a webpage or a mobile application, you’ve already formed an opinion before you’ve even started to use it. It’s exactly the same as falling in love: you’ll either instantly start to love a product, or you’ll instantly start to dislike it. This is how design can make a real impact.
For me, one of the most important things is the use of color. I think use of color can work in so many different ways. There’s a nice theory behind color, and there’s lots of human mind things happening, for instance that red represents anger and rage. Red means unit tests failing, it’s that experience that comes out with us. On the other hand, green is trust, acceptance, and admiration. That’s where we want people to be, and that’s like a good, warming feeling.
I’ve noticed that green is supposed to be a good, warming color, but it’s also the color of zombies. It turns out that different shades of green can indicate completely different emotions. Zombies have a dark green, which indicates more terror and fear, whereas a light green means trust and admiration. It shows the subtleties we need to be aware of when we’re putting color palettes together
At a conference in Lithuania last year, I noticed some text in red next to a flight on the departures board. I assumed it meant something bad, like the flight had been cancelled. It turns out to simply indicate that it was boarding. Why would it be red, implying that something is wrong? Boarding is a good thing to be happening to a flight. Ironically, when flights were in a closed status, the text was the standard white color, the same as check in. There’s no separation visually telling people that there’s a different action happening.
There’s this Material Palette website, where you can select colors that match what you’re trying to express. It’ll then give you a nice little color palette with all of the different variations, and all of the different ways you can put colors together. Quickly and easily, you’re starting to get colors which compliment each other instead of being jarring and conflicting. It also includes colors automatically which help express more important information.
We also need to be careful and consistent about the icons we use. One of the most weird annoyances I have is sharing icons. Every platform wants you to share information, yet every single platform not only changes their “share” icon between versions, but they’re completely different from one platform to the next. A user going to iPhone from Android would find a very different share icon, and vice versa. Not only is that weird for users crossing platforms, but as application developers we need to be aware that we can’t just use the same icon everywhere. An iPhone application designed and running on an Android device will have different icons than what users are expecting.
We also want the icons to actually mean something. If you have to put text next to an icon, the icon’s clearly not doing its job properly. It should express what it means right out of the box. It needs to be visible and easy to engage.
Google has put together icons which they have tested, and they’ve tried to express information which is clear for users to easily access and easily understand. If you’re looking for an icon to try to express a concept, the guidelines have some great examples about what works and what doesn’t.
Responsive icons are also important. Users on desktop and mobile will need different icons because they’re working at much different resolutions. A house in mobile can be really small, but also when we’re on a desktop, we probably want something a bit more detailed and enhanced in order to match a user’s expectations.
Imagery is so important. A nice looking image which embeds and fits into your webpage can have a huge impact on your conversion rates. Your images should feel connected, like everything just flows. It should feel like it was put together by a designer.
When you start using stock photography it, it breaks this approach. Google warns against using stock photos because they just don’t fit always fit, and they can feel unnatural.
Images can control attention (13:45)
You can use images to control how users pay attention, and what they pay attention to. An image of a baby looking straight into the user’s eyes will be distracting, because humans are inclined to make eye contact with the baby, thus forcing them to miss important information that the website might try to express. The only thing the user’s seeing is the baby.
However, if you change the image to a baby gazing at the text you want the user to read, the user will make eye contact and then instantly start looking to see what the baby’s looking at. You’re drawing the user to where the information should actually be, and where you want them to start looking just by subtle changes of the eyes.
Feedback is essential. People want to know that when they’ve done something they’ve actually done it. Especially on mobile devices, people want to know that they’ve pressed the right thing.
Google says that you should have a nice pulsing sensation within your application, so when users touch something it actually responds. On a mobile device, it should highlight the entire row, not just where the user clicked, otherwise the feedback will be hidden by the thumb.
These are subtleties, but they can make a big difference when you engage it within an application. Users can know they’re doing the right thing, instead of interacting with a cold, hard, flat, unresponsive application. People like to feel that they’re on the right journey.
The same is true in animation. It’s all about where the animation starts. The best approach is to be natural. If you press something, you expect it to grow out from that point. You don’t expect it to grow from the center of the screen, which may have nothing to do with where you pressed.
An example from Google is when we press a thumbnail to see a photo, it should grow from the photo that we selected, not simply popping from anywhere. Apple is also doing this in iOS 9, because they’ve made the transitions more related to where you’re pressing. It’s more cause-and-effect.
Generally, these animations make for delightful little details in an application. They are subtle, but they feel smoother, cleaner, and you’ve got an application that has a much more polished response. This can affect everything, even subtleties like how your buttons navigate, and how you transition between different things. You want it to feel like it’s just natural. Avoid thinking linearly, because nothing in reality is all that linear.
Progress bars are another important aspect of feedback. You want the user to start learning what’s going to happen, and what the expectations are for their use of your application. If the wait time is a determinate, and you know how long it’s going to take, then it should be the loading bar we all recognize. If it’s not, then don’t just fake it a progress bar sticking there for 20 minutes and then massively, instantly complete, like in Microsoft Windows. Be honest to the user and say, “Look, we don’t know how long this is going to take.” Indicate that within the progress bar.
The same can be done for circles, which is what we see more commonly in Google’s implementation. For indeterminate, if they don’t know how long they’re going to take, they constantly spin. However, if they know, then they give a determinate time. These subtleties help the user set expectations more clearly, so they don’t get quite so frustrated when things are not behaving like they expect.
Error messages for software developers seem to have this weird disconnect. There is often too much technical information, with weird error codes. The most beautiful one I’ve seen is from Macromedia, that pops up an error message saying “no error has occurred,” even though it is a dialogue with an error icon. These are the annoyances that frustrate people. You can do all of the good work in the world, but if you pop up something like that useless error, that trust is just going to go completely out the window.
Google has some nice approaches to this. For example, if it’s something that is really stopping or blocking, then it should be a dialogue. In that case, there’s nothing else a user can really do, apart from click “retry”. Whereas, if it’s something like not being able to sync or send a photo, then it should tell the user in a more subtle way, like a notification at the bottom.
The same goes for when you’re syncing music, online and offline. If the album can’t be loaded, display a nice image which informs them, but isn’t too overwhelming with some horrible error message. When things can’t be synced, or they are out of sync, then show a notification.
In the use of errors and text input, they recommend that if you need to display some information, display it at the top and add some human, readable information about how it actually works and how they can fix their problem. I think that’s the most important thing, from my point of view: tell the users how to fix it. Don’t just say that something’s gone wrong; give them hints and pointers to keep them flowing through the application.
There’s a great CSS framework called Materialize. It’s similar to Bootstrap, but it’s taken all of the guidelines detailed by Google and made it accessible for developers. They can quickly and easily plug it into their application, and this is what we’ve used for Katacoda. We’ve used it as our foundation.
It has all the subtleties. It’s fully responsive out of the box, and it has all these nice transitions. When you want to do a menu, you can simply swipe over and it does all the right gradients, so it’s not jarring. It does all the flow and animation you would expect, based on what Google is prescribing. For color palette, they’ve done the whole gradient thing for helping you indicate colors and importance. This makes everything coherent, makes everything a bit more connected.
Obviously, it’s a CSS framework, so it’s got its own grid layout, as we expect of every one. However, it’s quite a nice grid layout, and it’s sane, which is the best we can hope for. It also does the impossible, where we can vertically align text in the middle of a div.
Also, because it’s responsive from the outset, it’s aware of how users are engaging in the application on different devices. Everything is adaptive and responsive, even down to the text. From a developer’s point of view, we can just put a tag onto our text and it instantly provides great subtle touches which build a much better experience.
It also goes for things like buttons and feedback. When you start clicking buttons, it has a nice little pulsing sensation to indicate that something has happened. They embraced the guideline mentality, so they’re telling us that flat buttons should be used when you’ve already got some depth to your application.
Other subtleties include the use of cards. Cards are an important concept for Google, using them to express short tidbits of information. From Google’s point of view, they use it a lot in applications like Google Now, where the weather is a card, the airport and the flight schedules are a card, etc. They use this concept to separate information, but make it all consistent and accessible, and not cluttered or noisy. It gives gives everything space and boundaries while still making it all feel like it is one application.
What Do Users Think? (30:36)
What users think is the most important thing. We’re all building this for the users. Obviously, want positive feedback like “it’s very pretty, it’s very nice, I like it,” but that is not the most useful feedback.
As a quick example, I wanted to do the “mom test” on Katacoda, which is a very developer-focused tool. If you gave it to a non-technical user, what would they highlight, and what would they spot?
There’s a really cool service from UserTesting called Peek. You enter in a URL, and they find a random user who may have different degrees of technical abilities, could be from anywhere in the world, and they show them your website. They give them certain tasks, like “What is the initial thing you see about the website?”, or “What is the next step what you would perform on this website?” It’s nice to get third party feedback quickly.
We showed them our webpage, and there were some things that jumped out. Users liked how we’re using thick borders, thick headings at the top with a color block. They said it was much more engaging, and much easier to read, and they found that the colors were consistent and the buttons were easy to recognize. It verified that Google was doing the right thing.
They did make one comment about the way my text was aligned next to an image: “Why is this flipped around?” I hadn’t follow Google’s pattern for figuring out which way the images should be, and the user noticed and called it out as weird and jarring. They also provided interesting bits like, “there’s no FAQ.”
I then gave the site to a designer to look at, who thought it was too wordy. Even though the user wanted more words (FAQs), the designer said it had to be cleaner, and needed more imagery.
These were two very interesting conflicting approaches, but neither one really called out my use of the design, yet they also didn’t say it looked the same as anything else they’d seen on the internet.
For a much more in depth look at everything I’ve talked about, check out google.com/design.
For me, I find Material Design provides a great foundation for developers and non-designers to build sane websites. It helps me get started, and helps me work more quickly.
These are obviously guidelines, not rules. Google is saying that this is what’s working for them. You can adapt, change, and break these rules to match your own users, depending what you’re trying to achieve.
We really like the Materialize CSS framework. It’s nice and responsive, but if you’re using things like React, then there are other projects and other frameworks that have the React styling working out of the box.
About the content