4 Lessons Web App Designers Can Learn From Google

4 Lessons Web App Designers Can Learn From Google

4 Lessons Web App Designers Can Learn From Google

Suzanne Scacca

Whenever I’m curious about what more we could be doing to improve our users’ experiences, the first place I look to is Google. More specifically, I go to the Google Developers site or Think with Google to pull the latest consumer data.

But I was thinking today, “Why don’t we just copy what Google does?”

After all, Google has to walk the walk. If not, how would it ever convince anyone to adhere to its SEO and UX recommendations and guidelines?

The only thing is, Google’s sites and apps aren’t very attractive. They’re practical and intuitive, that’s for sure. But designs worth emulating? Eh.

That doesn’t really matter though. The basic principles for building a good web app exist across each of its platforms. So, if we’re looking for a definitive answer on what will provide SaaS users with the best experience, I think we need to start by dissecting Google’s platforms.

What Google Teaches Us About Good Web App Design

What we want to focus on are the components that make Google’s products so easy to use time and time again. By replicating these features within your own app, you’ll effectively reduce (if not altogether remove) the friction your users would otherwise encounter.

1. Make the First Thing They See Their Top Priority

When users enter your dashboard, the last thing you want is for them to be overwhelmed. Their immediate impression whenever they enter your app or return to the dashboard should be:

“I’m exactly where I need to be.”

Not:

“What the heck is going on here? Where do I find X?”

Now, depending on the purpose of your app, there are usually one or two things your users are going to be most concerned with.

Let’s say you have an app like Google Translate that has a clear utilitarian purpose. There’s absolutely no excuse for cluttering the main page. They’ve come here to do one thing:

Google Translate translator tool
Google Translate users don’t have to hunt around for the translator tool. (Source: Google Translate) (Large preview)

So, don’t waste their time. Place the tool front and center and let all other pages, settings or notices appear as secondary features of the app.

Something else this example teaches us is how you should configure your tool for users. Google could easily just leave this open-ended, but it defaults to:

Default Language —> English

Google’s data likely shows that this is the most popular way users use this app.

Although you can’t see it in the desktop app, you can see it on mobile. The formula goes like this:

Default Language —> Recent Language

I suspect that, for first-time users, Google will set the translation to the user’s native language (as indicated in their Google user settings).

If you have the data available, use it to configure defaults that reduce the number of steps your users have to take, too.

Not every web app provides users with a hands-on tool for solving a problem. In some cases, apps enable users to streamline and automate complex processes, which means their primary concern is going to be how well those processes are performing.

For that, we can look at a product like Google Search Console, which connects users to data on how their sites perform in Google search as well as insights into problems that might be holding them back.

It’s no surprise then that the first thing they see upon entering it is this:

Google Search Console overview - Performance and Coverage stats
The Google Search Console overview page shows users stats on Performance and Coverage. (Source: Google Search Console) (Large preview)

Performance (the number of clicks in Google search) and Coverage (number of pages indexed without error) are above the fold. Below it is another chart that displays recommended enhancements to improve core web vitals, mobile usability and sitelinks searchbox visibility.

Bottom line: The Overview page isn’t littered with charts depicting every data point collected by Google Search Console. Instead, it displays only the top priorities so users can get a bird’s-eye view of what’s going on and not get lost in data they don’t need at that time.

2. Create a Useful and Simple Navigation Wherever Relevant

This one seems like a no-brainer, but I’ll show you why I bring it up.

Zoom is a great video conferencing app. There’s no arguing that. However, when users want to schedule a meeting from their browser, this is what they see:

Zoom in-browser web app with multiple menus to choose from
The Zoom web app complicates things with multiple menus. (Source: Zoom) (Large preview)

The “Join Meeting” and “Host Meeting” options are fine as they both eventually push the user into the desktop app. However, the “Schedule Meeting” in-browser experience isn’t great because it leaves the website navigation bars in place, which only serves as a distraction from the app’s sidebar on the left.

Once your users have created a login and have access to your app, they don’t need to see your site anymore. Ditch the website navigation and let them be submersed in the app.

Or do as Google Hangouts does. Lay your app out the way users expect an app to be laid out:

  • Primary navigation along the left side,
  • Hamburger menu button and/or More (…) button contain the secondary navigation,
  • Wide open space for users to play in the app.
Google Hangouts distraction-free interface and simple navigation
A look inside Google Hangouts and its distraction-free interface and navigation. (Source: Google Hangouts) (Large preview)

But Google Hangouts doesn’t do away with the google.com website completely. For users that want to quickly navigate to one of Google’s other products, they can use the grid-shaped icon in the top-right corner. So, if you feel it’s necessary for your users to be able to visit your website once again, you can build it into the app that way.

This example also demonstrates how important it is to keep your navigation as simple as possible.

Google Hangouts’ primary navigation uses symbols to represent each of the app’s tabs/options:

Google Hangouts primary navigation design - icons only
Google Hangouts uses icons to represent the tabs of its primary navigation. (Source: Google Hangouts) (Large preview)

While I think it’s okay for Google Hangouts to get away with this icon-only menu design, be careful with this approach. Unless the icons are universally understood (like the hamburger menu, search magnifying glass, or the plus sign), you can’t risk introducing icons that create more confusion.

As NNG points out, there’s a difference between an icon being recognizable and its meaning being indisputable.

So, one way you can get around this is to make the outward appearance of the menu icon-only. But upon hover, the labels appear so that users have additional context for what each means.

As for any secondary navigation you might need — including a Settings navigation — you can write out the labels since it will only appear upon user activation.

Google Hangouts secondary navigation design - icons and labels
The Google Hangouts secondary navigation uses an icon and label for each tab. (Source: Google Hangouts) (Large preview)

Although some of the icons would be easy enough to identify, not all of them would instantly be recognizable (like “Invites” and “Hangouts Dialer”). If even one tab in your secondary navigation is rarely seen across other apps, spell them all out.

One last thing: The divider lines in this menu are a great choice. Rather than jam 10 tabs/options into this navigation bar together, they’re logically grouped, making it easier for users to find what they’re looking for.

3. Provide Users with Predictive Search Functionality

Every app should have a search bar. It might be there to help users sift through content, to find the contact they’re looking for from a long list, or to ask a question about something in the app.

The more complex your app is, the more critical a role internal search is going to play. But if you want to improve your users’ search experience even more, you’ll want to power yours with predictive search functionality.

Even though I’m sure you have a Support line, maybe a chatbot and perhaps an FAQs or Knowledgebase to help users find what they need, a smart search bar can connect them to what they’re really looking for (even if they don’t know how to articulate it).

Google has this search functionality baked into most of its products.

You’re familiar with autocomplete within the Google search engine itself. But here are some other use cases for smart search capabilities.

Google Drive connects users to documents (of all types — Docs, Sheets, Slides and more) as well as collaborators that match the search query.

Google Drive search for 'speed'
An example search for 'speed' within Google Drive. (Source: Google Drive) (Large preview)

Users can, of course, be taken to a full search results page. However, the search bar itself predicts which content is the most relevant for the query. In this case, these are the most recent pieces of content I’ve written that include the term “speed” in the title.

Google Maps is a neat use case as it pulls data from a variety of connected (Google) sources to try and predict what its users are looking for.

Google Maps predictive search example 'Alicia'
Google Maps pulls from a variety of sources to predict where users want to travel to. (Source: Google Maps) (Large preview)

In this example, I typed in “Alicia”. Now, Google Maps knows me pretty well, so the first result is actually the address of one of my contacts. The remaining results are for addresses or businesses within a 45-mile radius containing the word “Alicia”.

It doesn’t just pull from there though. This is one of those cases where the more enjoyable you make the in-app experience, the more your users will engage with it — which means more data.

For example, this is what I see when I search for “Three”:

Google Maps displays a 'Favorite' location when a user searches for 'three'
Google Maps will provide 'Favorite' locations in search results when relevant. (Source: Google Maps) (Large preview)

The very first thing it pulls up is a restaurant called Three Sisters (which is a fantastic restaurant in the city of Providence, by the way). If you look just above the center of the map where the red heart is, that’s the restaurant. This means that I’ve added it to my Favorite places and Google Maps actually calls it out as such in my search results.

Imagine how much more your users would love your app if it wasn’t always a struggle to get to the content, data or page they were looking for. Or to perform a desired action. When you give your users the ability to personalize their experience like this, use the information they’ve given you to improve their search experience, too.

4. Enable Users to Change the Design and Layout of the App

As a designer, you can do your best to design a great experience for your users. But let’s face it:

You’re never going to please everyone.

Unlike a website, though, which is pretty much what-you-see-is-what-you-get, SaaS users have the ability to change the design and layout of what they’re interacting with — if you let them. And you should.

There are many different ways this might apply to the app you’ve built.

Google Calendar, for example, has a ton of customization options available.

Google Calendar - view customizations
Google Calendar allows users to customize the look and view of their calendars. (Source: Google Calendar) (Large preview)

On the far left is a list of “My calendars”. Users can click which calendars and associated events they want to see within the app.

In the bottom-right corner is an arrowhead. This enables users to hide the Google apps side panel and give them more room to focus on upcoming events and appointments.

In the top-right, users have two places where they can customize their calendar:

  • The Settings bar allows them to adjust the color and density of the calendar.
  • The “Month” dropdown allows them to adjust how much of the calendar is seen at once.

These customizations would all be useful for any sort of project management, planning or appointment scheduling app.

For other apps, I’d recommend looking at Gmail. It’s chock full of customizations that you could adapt for your app.

Previously, if users clicked the Settings widget, it would move them out of the app and into the dedicated settings panel. To be honest, it was annoying, especially if you just wanted to make a small tweak.

Gmail Settings panel - design and layout customization options
Gmail’s Settings reveals a list of design and layout customization options. (Source: Gmail) (Large preview)

Now, the Settings button opens this panel within Gmail. It enables users to adjust things like:

  • Line spacing,
  • Background theme,
  • Inbox sorting priorities,
  • Reading pane layout,
  • Conversation view on/off.

This is a recent update to Gmail’s settings, which probably means these are the most commonly used design customizations its users actually use.

For any customizations users want to make that they can’t find in this new panel, they can click “See all settings” and customize the in-app design and layout (among other things) even further.

Other customizations you might find value in enabling in your app are:

  • Keyboard control,
  • Dark mode,
  • Color-blind mode,
  • Text resizing,
  • List/grid view toggling,
  • Widget and banner hiding,
  • Columns displayed.

Not only do these design and layout controls enable users to create an interface they enjoy looking at and that works better for their purposes, it can also help with accessibility.

Wrapping Up

There’s a reason why Google dominates market share with many of its products. It gets the user experience. Of course, this is due largely to the fact that it has access to more user data than most companies.

And while we should be designing solutions for our specific audiences, there’s no denying that Google’s products can help us set a really strong base for any audience — if we just pay attention to the trends across its platforms.

Further Reading on SmashingMag:

Smashing Editorial (ra, yk, il)

Helping Browsers Optimize With The CSS Contain Property

Helping Browsers Optimize With The CSS Contain Property

Helping Browsers Optimize With The CSS Contain Property

Rachel Andrew

In this article, I’m going to introduce a CSS Specification that has just become a W3C Recommendation. The CSS Containment Specification defines a single property, contain, and it can help you to explain to the browser which parts of your layout are independent and will not need recalculating if some other part of the layout changes.

While this property exists for performance optimization reasons, it can also affect the layout of your page. Therefore, in this article, I’ll explain the different types of containment you can benefit from, but also the things you need to watch out for if applying contain to elements in your site.

The Problem Of Layout Recalculation

If you are building straightforward web pages that do not dynamically add or change elements after they have loaded using JavaScript, you don’t need to worry about the problem that CSS Containment solves. The browser only needs to calculate your layout once, as the page is loaded.

Where Containment becomes useful is when you want to add elements to your page without the user needing to reload it. In my example, I created a big list of events. If you click the button, the first event is modified, a floated element is added, and the text is changed:

A listing of items with a button to change some of the content in the first item
(See the initial example on CodePen)

When the content of our box is changed, the browser has to consider that any of the elements may have changed. Browsers are in general pretty good at dealing with this, as it’s a common thing to happen. That said, as the developer, you will know if each of the components is independent, and that a change to one doesn’t affect the others, so it would be nice if you could let the browser know this via your CSS. This is what containment and the CSS contain property gives you.

How Does Containment Help?

An HTML document is a tree structure which you can see when inspecting any element with DevTools. In my example above, I identify one item that I want to change by using JavaScript, and then make some changes to the internals. (This means that I’m only changing things inside the subtree for that list item.)

DevTools with the list item of the featured item expanded to see the elements inside
Inspecting a list item in DevTools

Applying the contain property to an element tells the browser that changes are scoped to the subtree of that element, so that the browser can do any possible optimizations — safe in the knowledge that nothing else outside of that element will change. Exactly what a particular browser might do is down to the engine. The CSS property simply gives you — as the developer and expert on this layout — the chance to let it know.

In many cases, you will be safe to go right ahead and start using the contain property, however, the different values come with some potential side effects which are worth understanding before adding the property to elements in your site.

Using Containment

The contain property can set three different types of containment:

  • layout
  • paint
  • size

Note: There is a style value in the Level 2 Specification. It was removed from Level 1, so does not appear in the Recommendation, and is not implemented in Firefox.

Layout

Layout containment brings the biggest benefits. To turn on layout containment, use the following snippet:

.item {
  contain: layout;
}

With layout containment enabled, the browser knows that nothing outside the element can affect the internal layout, and nothing from inside the element can change anything about the layout of things outside it. This means that it can make any possible optimizations for this scenario.

A few additional things happen when layout containment is enabled. These are all things which ensure that this box and contents are independent of the rest of the tree.

The box establishes an independent formatting context. This ensures that the content of the box stays in the box — in particular floats will be contained and margins will not collapse through the box. This is the same behavior that we switch on when we use display: flow-root as in explained in my article “Understanding CSS Layout And The Block Formatting Context”. If a float could poke out of your box, causing following text to flow around the float, that would be a situation where the element was changing the layout of things outside it, making it a poor candidate for containment.

The containing box acts as the containing block for any absolutely or fixed position descendants. This means it will act as if you had used position: relative on the box you have applied contain: layout.

The box also creates a stacking context. Therefore z-index will work on this element, it’s children will be stacked based on this new context.

If we look at the example, this time with contain: layout, you can see that when the floated element is introduced it no longer pokes out the bottom of the box. This is our new Block Formatting Context in action, containing the float.

A listing of items, a floated element is contained inside the bounds of the parent box
Using contain: layout the float is contained (See the layout containment example on CodePen)

Paint

To turn on paint containment, use the following:

.item {
  contain: paint;
}

With paint containment enabled, the same side effects as seen with layout containment occur: The containing box becoming an independent formatting context, a containing block for positioned elements, and establishing a stacking context.

What paint containment does is indicate to the browser that elements inside the containing block will not be visible outside of the bounds of that box. The content will essentially be clipped to the box.

We can see this happen with a simple example. Even if we give our card a height, the floated item still pokes out the bottom of the box, due to the fact that the float is taken out of flow.

A floated box poking out the bottom of a containing box
The float is not contained by the list item

With paint containment turned on the floated item is now clipped to the size of the box. Nothing can be painted outside of the bounds of the element with contain: paint applied.

A box with a floated box inside which has been cut off where it escapes the box
The content of the box is clipped to the height of the box (See the paint example on CodePen)

Size

Size containment is the value that is most likely to cause you a problem if you aren’t fully aware of how it works. To apply size containment, use:

.item {
  contain: size;
}

If you use size containment then you are telling the browser that you know the size of the box and it is not going to change. This does mean that if you have a box which is auto-sized in the block dimension, it will be treated as if the content has no size, therefore the box will collapse down as if it had no contents.

In the example below, I have not given the li a height; they also have contain: size applied. You can see that all of the items have collapsed as if they had no content at all, making for a very peculiar looking listing!

A listing of items with a button to change some of the content in the first item
(See the size example on CodePen)

If you give the boxes a height then the height will be respected when contain: size is used. Alone, size containment will not create a new formatting context and therefore does not contain floats and margins as layout and paint containment will do. It’s less likely that you would use it alone; instead, it is most likely you would apply it along with other values of contain to be able to get the most possible containment.

Shorthand Values

In most cases, you can use one of two shorthand values to get the best out of containment. To turn on layout and paint containment, use contain: content;, and to turn on all possible containment (keeping in mind that items which do not have a size will then collapse), use contain: strict.

The Specification says:

contain: content is reasonably "safe" to apply widely; its effects are fairly minor in practice, and most content won’t run afoul of its restrictions. However, because it doesn’t apply size containment, the element can still respond to the size of its contents, which can cause layout-invalidation to percolate further up the tree than desired. Use contain: strict when possible, to gain as much containment as you can.”

Therefore, if you do not know the size of the items in advance, and understand the fact that floats and margins will be contained, use contain: content. If you do know the size of items in addition to being happy about the other side effects of containment, use contain: strict. The rest is down to the browser, you have done your bit by explaining how your layout works.

Can I Use Containment Now?

The CSS Containment specification is now a W3C Recommendation which is what we sometimes refer to as a web standard. In order for the spec to get to this stage, there needed to be two implementations of the feature which we can see in both Firefox and Chrome:

Screenshot of the browser support information on Containment on Can I Use
Browser support for containment (Source: Can I Use)

As this property is transparent to the user, it is completely safe to add to any site even if you have lots of visitors in browsers that do not support it. If the browser doesn’t support containment then the visitor gets the experience they usually get, those in supporting browsers get the enhanced performance.

I would suggest that this is a great thing to add to any components you create in a component or pattern library, if you are working in this way it is likely each component is designed to be an independent thing that does not affect other elements on the page, making contain: content a useful addition.

Therefore, if you have a page which is adding content to the DOM after load, I would recommend giving it a try — if you get any interesting results let me know in the comments!

The following resources will give you some more detail about the implementation of containment and potential performance benefits:

Smashing Editorial (il)