Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, couldn’t be more excited to be speaking with Rob Giampietro, who’s coming to us to talk about Google Fonts. Rob, thanks so much for joining us.

Rob:

Hey, thanks so much for having me, guys.

Karen:

But before we get on with it, I’d like to welcome back our sponsor, Gather Content. I’m thrilled that they’ll be sponsoring this podcast for the rest of the year. I recommend Gather Content to my own clients who are going through a website redesign. Gather Content provides some much needed structure and editorial workflow to help manage a large-scale content creation process. Because Gather Content works with so many organizations going through a website redesign, they have unique insight into how content fits into a web project. And because they are such great people, they wrote down their advice for you! They’ve put together a 41-page guide to Content Strategy for Website Projects. Head on over to gathercontent.com/RWD to read their advice or download a PDF to share with your team. Thanks, Gather Content!

Ethan:

So Rob, before we actually dive in and talk about Google Fonts’ responsive redesign, maybe just tell our audience a little bit about yourself and what you do at Google.

Rob:

So, I’m a creative lead at Google and I lead the design studio in New York, and specifically I work on a lot of projects that maybe you’d call special projects. So, we have a great team of designers that do a lot of the Material specifications and the site that goes with them, but a lot of the projects that sort of hit my desk are a little bit more out of the box, or extraordinary projects. And then alongside that, I do a lot of our design outreach work. So, that includes a conference called the SPAN design conference; we put out a beautiful reader last year that was a sort of collection of writing by people that spoke at the conference. I run the Google Design site, which is a sort of blog and editorial site; and then get to do projects like the Google Fonts project and other things that pop up that need some Materialize on them.

So many people were using Google Fonts to develop websites that people were reading on their phones and things like that, and they needed a way to address all of those different audiences.

Ethan:

Well, we couldn’t be more excited that you’re here today. It’s been really exciting for me just from the outside, watching all this beautiful responsive work come out of Google over the last few years, and I was just sort of amazed to see Google Fonts, because it’s such a dense, highly interactive interface. Maybe you could tell me a little bit more about the early days of that redesign and specifically if there was anything that drove the decision to go responsive. Was this coming from stakeholders and executives internally, or were you fielding any weird questions or concerns about responsive design as it applied to Google Fonts specifically? Just tell us a little bit about the origin story there.

Rob:

I think there’s a couple different places where the project came from. I talked a little bit about what I do at Google, but before I was at Google, I ran a design studio called Project Projects down on the Lower East Side, which is still active. But I was a partner there and had looked at Google Fonts, had looked at Material Design, and I think specifically with Google Fonts I had always thought that was a really interesting product that maybe Google could do more with.

I was really pleased when about two weeks after joining Google, when two people, a guy named Omer Ziv and Dave Crossland, who worked on the Google Fonts team, reached out to me and said, “Hey, we’re really excited you’re here. We have this thing called Google Fonts and we have some ideas about what we’d like to do with it, and we’d love to talk to you about them.” We had lunch and basically they started to tell me what they wanted to do, and I started to say, “Well, here’s what I think you should do…” and it was really exciting to have all of our ideas basically be the same ideas, which so rarely happens, where you’re totally aligned even though you’ve never met before.

Really what they were looking to do was bring some of the philosophies of Material Design to Google Fonts and say—Material Design, in many ways, was sort of a mobile-first project and is now learning better how to scale up and be adopted for desktop in various ways, and I think they were realizing that so many people were using Google Fonts to develop websites that people were reading on their phones and things like that, and they needed a way to address all of those different audiences.

We also realized that the project was very, very small scale, it was about five people, a couple of “twenty-percent people” throwing in their help where they could, so it had to be very selective about what it could do, and in a way design was not yet a priority as a lot of infrastructure and back-end work was getting prioritized. And so, I think Material saw an opportunity there to get involved because obviously type design is so important to our audience and type designers are really important designers within Google’s design philosophy. So, to show those people that we really value their work was a huge thing.

And then just trying to sort of stress test some of the different material components that we built on a product… A lot of times we make components and we give them to other teams to use, or we open source them and we let everyone use them. But to be able to really use them ourselves in a product for Google was really exciting, and Fonts was obviously kind of a perfect fit in that way.

It wasn’t so much that we could get responsive for free, but we could certainly use what was great about Material Design to make it a lot easier for ourselves to embrace that range of devices.

Karen:

Can you talk a little bit about different scenarios of use, particularly how those might intersect with some assumptions around which types of tasks people more likely want to do on a desktop computer versus on a mobile device? One of the things that I’ve heard is that when people are using fonts, they tend to be using them in a desktop context, and so why does that need to be on a mobile phone?

Rob:

Certainly Google Fonts before the redesign was desktop-only, and I think when we initially started the project, we were very intent on keeping the scale of it focused as much as we could so that we didn’t over-extend ourselves and not launch something. So initially we were like, let’s take the desktop site and make it better. But as we did that, we realized that a lot of the Material components that we were using had been designed to scale up and down to different aspect ratios and screen sizes. And so, we realized that it wasn’t so much that we could get responsive for free, but we could certainly use what was great about Material Design to make it a lot easier for ourselves to embrace that range of devices, and that that would actually make people more able to use the site across different use cases.

And so to address your question specifically, those use cases were designers or people browsing fonts, and one particular user flow would be, I, as a designer or web designer, may pick a couple of fonts, make a collection, send it to my client or stakeholder on my team and have them review it or make it a URL. And so they might be on their phone when they get that URL, and so they might be actually wanting to look at and approve the typefaces I’ve selected from their phone, so that would be a place where supporting the phone is really important.

Maybe just browsing fonts—I mean, a lot of times that’s not something that you can do sitting at work for hours and hours, it’s actually something that’s kind of fun to do on your couch or something like that, to get inspired or think about a project that’s coming up. So, again, the browsing or the reviewing case was when a phone seemed really great. The case of something like a designer sending a set of specified fonts to a developer, or a designer/developer who’s playing both roles, actually grabbing that code, embedding it, optimizing the website—those things do tend to be more on a desktop use, and so certainly the site privileges that user flow for desktop, but a lot of that stuff is still accessible in the bottom sheet that we designed for the site.

Part of what is great about responsive design is that, again, it broadens access, it lets more people using different types of devices access content. I think type is another way of broadening access.

Ethan:

Rob, that might segue nicely into my next question, which is kind of a little bit more broadly around design process. As you’ve been working with products like Google Fonts that are trying to be a little bit more device-agnostic, has that changed the way that you think about designing for the web in general over the last few years?

Rob:

I think really, in the case of Google Fonts, the motivator was really about sort of showing a lot of love towards what we think—we’re all designers on the Google Design team and on Material Design team, and we love typography, and so I think the motivator was let’s show how much love and actually enthusiasm we have for great typography.

A lot of the guidance in Material Design is based around the typeface Roboto, which is obviously something that we use and love a lot at Google. But we recognize that people in other contexts, other brands, other situations want to embrace a range of fonts, and actually that typography, in a weird way, is the most responsive element of design. You can take a typeface, San Francisco or Roboto, from a watch all the way up to a large desktop display and can retain a kind of consistency there across lots of different things. So, I think we love the idea of not having a fonts website that was somehow partial or only supported in one screen size or something like that; we really wanted to go all the way and support great typography across all devices, but we also were interested in the idea that, with great typography and with access to great typography, people could actually use more typefaces within Material Design and do more with them.

And I would actually say that part of what is great about responsive design is that, again, it broadens access, it lets more people using different types of devices access content. I think type is another way of broadening access. When you have non-Latin alphabets, for example, which in Google Fonts, we’re there but we’re not getting shown completely, like a lot of the non-Latin alphabets that we have in Google Fonts have Latin scripts, and the previous version of Google Fonts defaulted to all Latin scripts even for non-Latin fonts, if that makes any sense. So if there was a Hebrew script that had Latin letters, it would show the type in Latin letters, and maybe if you were browsing the page you couldn’t see that there was Hebrew in that font. And so now, the new Google Fonts actually privileges whatever primary script is of the language, and this is amazing for non-Latin users. So in a way, there’s a parity in terms of access broadening as well.

Ethan:

That is fascinating. Thanks for sharing that with us. I don’t know if this is too deep in the weeds, but I’d love to hear a little bit more about how you actually started building this design or how you started figuring out the layout. You mentioned Material Design a few times, it sounds like that was a really valuable tool. Were you still building mock-ups in a traditional design application early in the process, or was this really prototype-focused? Tell me a little bit more about that.

We wanted users to be able to actually edit and interact with type and not have it just be a static image; we wanted to celebrate great type designers by actually serving their assets rather than serving images.

Rob:

Maybe it’s helpful to begin the answer to sort of talk a little bit about how Material typically works, which is that we design a lot of components, and we design them because we think they’re needed often by Google teams or sometimes we review Google teams’ designs and they have needs and don’t have components for them. And so we build components to address those needs, because we think that not only will they need them but other users and open source users will need them as well. So, typically we’re a team that’s kind of laser-focused on certain problems within an interface. I think what’s interesting is that, as a result of that, we don’t actually get a lot of time to make the whole picture for ourselves. I think Google Fonts was actually one of the first products that went through an entire Material Design process by the Material Design team.

And so, we agreed as a team that, in taking on the project, we would actually put it through the typical cycle of Material reviews, but my team would not be the team reviewing the site but rather our Reviews team would be reviewing the site and giving us notes just as they would with Google Maps or any other team at Google. So, that was actually a really great opportunity to put ourselves through our own process and build something end-to-end that was using our components but actually was also involved in the big picture. And just like a lot of the teams that we work with at Google, we wound up building some new components in order to solve specific problems presented by this interface, and also things that came up in user testing. So, things like the font pairing thing that’s on the specimen page, you can compare fonts and pick a body copy and a headline font and things like that. That was not something that existed within Material Design, we had to sort of create that widget and build components, adapt components that we had to do it. So, we kind of got a sense a little bit of what it’s like for other Google teams to be solving some of these problems.

But in reference to your more specific question, I think the process definitely began with flat sketches. We didn’t need to do wireframes or functional spec, because initially our goal was not to add a lot of new features but rather to kind of simplify and clarify the interface and Materialize Google Fonts, so really show that Google Fonts and Material Design were much more closely aligned than they maybe had been in the past. A lot of that work was done in Illustrator, but I think before we even got into Illustrator, what we tried to do is sit down with the Fonts team and the Material team and figure out what the goals of the project were. I think those, more than anything else, informed the initial designs.

One of the goals was we wanted to make it clear what type you needed to read and what type you needed to view, and we thought Roboto was a great way of moving to the background or just being type that was sort of UI rather than type that you were looking at to select. We wanted users to be able to actually edit and interact with type and not have it just be a static image; we wanted to celebrate great type designers by actually serving their assets rather than serving images or something like that. So, there were a lot of things that were just about improving things. We wanted to make it easier for people to make collections, we also wanted to be able to—just like Material Design does a lot of user education, we wanted to be able to educate users, through editorial and also through collections, about choosing great typefaces or what we saw as some of the best of the 800-something fonts in Google Fonts and use Material guidance there. So, a lot of those things were the starting points for the redesign, along with just conveying a sense of simplicity and clarity of purpose on the site.

We didn’t want to be in our own heads and be like, “Material is so great, and if we just Materialize Google Fonts, that will be great!” We really wanted to make sure that people really felt like it was an improvement.

Karen:

That is fantastic. I want to follow up on just one of the amazing things that you’ve already said, which is the review process, where you’re working with the Reviews team. Can you talk a little bit about how you might get feedback internally, but then maybe also did you do any user testing or get feedback from people who had actually used Google fonts?

Rob:

So within Google, most Google product teams meet with Material Design on, more or less, a bi-weekly basis. So we kind of check in with those teams, see how they’re doing, sometimes they share mocks with us and we give them feedback, sometimes we mention something to them or sometimes they’ll bring us something and we’re like, “Huh, that’s interesting. Let us dig into that a little bit more and do some research around it,” or something like that. So that’s the typical process with other Google teams.

In the case of this product, we did exactly the same thing. So we brought Google Fonts to the Reviews team, which is another team within Material Design. They looked at the product, they gave us some amazing notes. A lot of those notes focused on things like, as I recall, we have kind of a unique pattern, we have a right-hand menu that’s activated by hitting the search icon, and you can both search and filter. That’s because we realize that a lot of people just want to type in the name of a font, or a lot of times people are actually needing to drill down the list or filter down the list so that they can find specifically the font they’re looking for and they’re not using the search menu as much maybe because not as many of the names within Google Fonts are names that designers would know, or things like this. So we really felt the need to combine searching and filtering. It took us a little while to get that right, so the Material Review process was a relatively new pattern within Material and it really helped us to make it better.

Another case would be the bottom sheet—so you start adding fonts to your collection, you get this little bottom sheet, you can pop it up and you can see a lot of what you’ve selected, you can de-select fonts that would slow down your site if you’re not actually using them… And when you do that, you get kind of an optimization reading, you get something that sort of says “fast,” “slow.” Previously that was an odometer kind of graphic that was buried in the bowels of Google Fonts’ UI somewhere, and we actually did a lot of work to figure out how we can simplify that. One of the fascinating things that came about was that even though we could use words like fast or slow and be very clear about how optimized your font selections were, it was still much, much easier for people if they saw a green light, a yellow light, or a red light to just kind of, at a glance, determine how well they were doing, and the red light signaled some kind of an error state to them even if the error state wasn’t prohibitive of them continuing and maybe just installing more fonts than they needed to on their website. So, it was super interesting to go through some of those things and stress test some of our assumptions.

But after we did the reviews, to kind of build on what I was explaining before, we had static mocks, we did some motion studies, then we got into a prototype, and basically we were within front-end prototypes by about six months into the project, which lasted around a year. The prototypes were really helpful, and we did a team-wide testing, and we also did a Google UX-wide testing before the product was launched in between the Material reviews and that kind of broader user testing, we did two rounds of more study-like reviews with a targeted set of users; I think there were about ten internal Google users and then ten external users that we did user research on. And each of those processes also resulted in a lot of fascinating insights that found their way into the final product.

So, one of those that I can share is the external users really interestingly wanted to be able to compare fonts, and that was actually data that we had in Google Fonts—one of the fascinating things about Google Fonts is the amount of data that we have about how these fonts are being used. We have a ton of data about what fonts other people pair those fonts with. So, we know that if Roboto is on a page, there might be another font frequently paired with it, and we have that correspondence data. And so, we could easily reveal that data, and what the user testing told us was that people really wanted that guidance, and not only did they want to just be told which fonts were frequently occurring together, but they wanted to be able to swap and test fonts and take the browsing process that one step further before they made their selections. We responded by putting that into the product, and there were a number of things like that that came about from the user testing process that was really great.

The other thing that it did was that it just sort of validated—we didn’t want to be in our own heads and be like, “Material is so great, and if we just Materialize Google Fonts, that will be great!” We really wanted to make sure that people really felt like it was an improvement, and I think that’s particularly true for the Fonts team because a lot of them had been working on this project for five years, since its very beginning. To be fair, Google Fonts, there’s over nine trillion font views of Google Fonts in the six years that the project has been active, so they’ve done okay and they’ve served a lot of fonts, and they’re very happy with their product in terms of its exposure. I think we wanted to make sure that, in doing this kind of drastic change to the interface and bringing it closer to Material, that users were going to see a benefit to that too. And I think the user testing in those more focused sessions really validated it, because you could hear people sort of say, “Wow, I can’t believe this!” and I think it was really helpful for the whole team to hear those kinds of responses also.

Ethan:

Rob, I just wanted to follow up on, again, one of the many things that you’ve just said that was just wonderful, about the products sort of warning users when adding too many fonts could potentially slow down their sites. Was performance a design consideration for Google Fonts? Was it something that you had to keep in mind as you were actually fleshing out this new responsive design?

Rob:

Yeah, absolutely. I think actually that was one of the strengths coming into the project, is that the back-end engineering of the product was so, so strong and, in fact, a majority of the team working on the project was in back-end engineering and infrastructure support, so they’re powering millions of websites around the world with stable font-serving, so that was a strength.

I think what we wanted to do was have some of our Material front-end engineers be able to bring their knowledge and their awareness to the project also, and so we selected Angular Material components to design the entire site with, and what that allowed us to do was have a much more performant site. If you think about it, there are actually a lot of complex needs on the fonts site because, again, there are about 800 fonts in the catalog, so if a user went through and added all 800 of those fonts to their website, they would get all kinds of warning messages in the performance meter. But we had to do that seamlessly and easily for users so that they could quickly filter and find the fonts that they were looking for. So yeah, I think performance was a huge one.

I think it’s also a little bit of a complicated thing. Fonts and Docs is actually pretty clear, there’s a drop-down menu that feels like a word processing editor that people are somewhat familiar with. But I think once, for most users, you go outside of that, how they actually take the fonts from Google Fonts and get them into their blog or into their website, that’s something that we really need to guide them through carefully, and so that was a real goal of ours. A lot of the users of Material Design are actually engineers that are maybe a design team of one and also engineering, and so how to do basic education for them or make it really easy for them to find what they were looking for was important both from a performance standpoint and just from a simplification of the UI standpoint. So, not having everything visible right away but having this kind of progressive sense that you were driving towards a selection and then able to act on that selection really easily.

Google’s investment in Google Fonts is very similar to its investment in Material Design in that you kind of put good design out there and you really hope that people use it and find value in it and that, in a way, the value comes back to Google.

Karen:

Let me ask kind of generally, how do you measure the success or the effectiveness of this redesign? Given that you’re talking about Google here, what sort of research or data are you looking at to know if this site is working?

Rob:

You mean from a user excitement standpoint, or more from an analysis and stability standpoint?

Karen:

I would say from a user excitement standpoint certainly, and I think also from a business standpoint—like is Google getting what they want out of this site?

Rob:

We really feel like, just as Material components are open source and that there’s a certain base set of things that users need in order to be able to make websites or apps or things like this, that in a way typography is the same. I think text, in a way, is a way that people express themselves and they need a certain set of typefaces to be accessible to them in order to make any sort of design system better. Google’s investment in Google Fonts is very similar to its investment in Material Design in that you kind of put good design out there and you really hope that people use it and find value in it and that, in a way, the value comes back to Google in some form. But I don’t think it’s direct; it’s not like we’re selling these fonts or anything like that.

At the same time, we really do want people to buy fonts on other platforms. Like, Google Fonts is an open source platform, but it’s not a critique of people buying fonts. We think that font designers should totally get paid for their work and there’s a huge market clearly for people that are buying fonts. So, I think some of what we want to do is, to use a metaphor, you go to the public library, you check out a book, and then you love that author and you go buy a few more books of theirs at Barnes & Noble. I think there’s a lot of opportunity for great type designers to put a font on Google Fonts and then for us to help users connect that that person is actually a type designer who has a whole lot more fonts for sale and we can try to bridge that gap and introduce people to the idea that typographic design has great value and that there’s a great artistry to it. So in terms of the v1 of Google Fonts, what we want to do is do that by just—we rewrote all of the bios for the typographers on the site. Previously they linked to G+ bios, which some typographers didn’t have, or it wasn’t the best way for users to find information about type designers. Now they actually have real notes about the typeface and the design intent behind it. We released three fonts, when Google Fonts launched, by really celebrated type designers—by Colophon, Dalton Maag, and David Jonathan Ross at The Font Bureau—and we made a print specimen of one of those new typefaces. That was just another sign to type designers out there that we really love and value them.

To answer your question about metrics, that was a really key metric for us, was does the type design community find that we’re moving in the right direction with this product, and do they feel like they would want to put a font on Google Fonts now. We launched a little bit before the Typographics conference in New York, but we brought Google Fonts to the Typographics conference and shared some of our work there, and we also had a chance to meet with a ton of type designers, and by and large we heard from them, “Yes, it really feels like you’re moving in the right direction.” So in addition to web designers loving the product, and some great press, and a ton of positive user feedback and stuff like that, we were really, really pleased that in a way the people that formed the soul of the product, it sort of felt like they gave us a thumbs up that we were moving in the right direction.

The number one thing that we did that was really successful is that we had an opinion about why we were doing this project.

Ethan:

Well, that’s fantastic. Rob, sadly we’re coming up to the end of our time today, but I would just love to know, before we let you go, do you have any advice for our audience? If there’s one or two things that you’ve learned in redesigning Google Fonts, what should somebody who’s listening to this podcast keep in mind for their own responsive projects?

Rob:

I think the number one thing that we did that was really successful is that we had an opinion about why we were doing this project. I think the opinion from the beginning was make this interface really easy for a lot of people to use, and make sure that it celebrates the content that it’s serving on every level. From an editorial standpoint, from a design standpoint—even like a percentage of the interface, much more of the fonts are now visible and the interface is a lot less chrome surrounding them. So I think with those guiding principles, we really were always able to gut-check the designs that we were coming up with and make sure that they were on point in terms of the guidance that we had set out for ourselves.

And I think sharing a lot of those guiding principles early was also really motivating and important for our team, to just socialize why we thought the project was important, why we wanted to move forward with it. I think it brought a lot more stakeholders in early into the process, and then they also agreed with the philosophy of the project and gave us latitude to sort of explore that and come back to them in a few months when we thought we had some good solutions. So it was a really great project, so many great people worked on it beyond myself, and I just want to also say thank you to them and to the users who are using and giving us feedback on the site—we love that, too. So yeah, it was great.

Karen:

Well Rob, this has been spectacular. I will look forward to having you back next week and every week for our now ongoing series talking to you.

Rob:

[laughs] Thanks guys.

Karen:

Thank you so much for coming on.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every episode at responsivewebdesign.com.

Thanks so much for listening, and we’ll be back next week.