Selling Responsive Web Design To Clients

Designing and developing websites that work well on mobile devices is an important aspect of the work we do on today’s Web. This importance is reflected in the conversations I have with clients, almost all of whom list “support for mobile devices” as one of their top goals for a redesign — all except one, that is.
Late last year, I began a redesign project for a company that sells pressure-treated lumber products. Early on in our conversation, I turned to the topic of support for mobile devices and responsive Web design. Normally, this topic is met with enthusiasm, but not this time, as the client explained:

Our customers don’t use mobile phones to come to our website.

This isn’t the first time I’ve heard this comment from a potential client. I’ve had many conversations in which the company severely underestimates the number of people who access their website on a phone or other mobile device. Typically, a look at the analytics will open their eyes to the true impact that mobile is having on their website’s traffic. But when I looked at the analytics for this particular client, I was the one left in shock.
Two percent. That was how much of its traffic was coming from mobile devices at the time. That’s it!
Jumping ahead to the end of this story, I did end up working with this client to redesign their website, and that website is now fully responsive. The path we took to that point, however, provides an interesting glimpse into how we as designers can go about selling responsive websites, and when we should push for a solution that we know to be an important best practice and yet whose need is not immediately obvious.

Determine Whether They Actually Need A Mobile Web Experience

The title of this article, “Selling Responsive Web Design To Clients,” might sound like a shady salesperson attempting to convince a customer to purchase something they don’t need. That is not what I am advocating for at all. So, let me start by stating that the first step in this process should be to determine whether the client actually needs a given solution at all.

Make sure that the solution you are selling fits the client you are pitching it to. (Image: echerries)
When considering a responsive design for a website that doesn’t currently support mobile devices, begin by looking at the big picture. Do the traffic figures show that the client is attracting mobile users? If the mobile traffic figures are similar to those of this client of mine, then maybe they don’t actually need a mobile Web experience at this time — especially if the website has no other issues.
If a website is currently working well for the organization — meaning that it is converting visitors, features an attractive design, and has a high-quality user experience (for desktop visitors at least), while drawing an incredibly low percentage of mobile users — then redesigning or rebuilding that website only to make it responsive wouldn’t make financial sense.
You could argue that even a small percentage of visitors getting a poor experience is unacceptable and could be resolved by developing a responsive design. The designer in me can appreciate that argument, but I also understand the business side of the situation. Undertaking a responsive redesign to accommodate just 2% of the audience will be a very tough sell, no matter what company you are speaking with. This is why you need to look beyond just the traffic figures and think about more than just the design-related benefits of responsiveness.

Try To Solve Other Problems They Are Having

While support for mobile devices was not a compelling enough reason for our client to redesign their website, other concerns brought them to us in the first place. Two of these concerns were the visual design of their website, which was outdated and did not reflect their current marketing, and the lack of a content management system (CMS) or any tools to enable them to update the website on their own. So, I focused my proposal on solving these problems.
A redesign would bring the look and feel of the website in line with the rest of the client’s marketing, while also improving the overall aesthetics and usability of the website itself. We would bring the website up to current standards and integrate it into a CMS (in this case, ExpressionEngine) — which would solve the second problem of being able to update the website.
As I discussed with the client this proposal and the process we would follow, I mentioned that we would make the website responsive as we rebuilt it. As expected, the client questioned whether this was necessary or added cost to the project — which, of course, it would have. The key here is that I was now able to steer the conversation towards the benefits of responsive design above and beyond the support for mobile devices.

Focus On More Than Just Phones

When we talk about responsive design, we often focus on phones. This makes sense because smartphones are most unlike the type of devices that we’ve designed for in the past — that is, desktop screens. Creating one website to be marketed and managed and to deliver a high-quality experience to all devices, from desktops to smartphones, is an excellent way to demonstrate the flexibility and power of responsive design. But for this client, phone users were seemingly not a factor. Luckily, responsive design is about so much more than phones.

The devices and screens we design for today are a variety of sizes. (Image: Edwin Torres)
In speaking with the client, I discovered that a complaint they often receive from customers is that the website appears “small.” The reason is that it had been designed to a fixed width many years ago — so long ago, in fact, that it was built for an 800 × 600-pixel resolution. When a user on what is now a typically large desktop screen visited the website, they saw a very narrow column, with a lot of unused space on either side. Yet, the company still had a number of other visitors on old desktops and laptops with low resolutions. So, merely making the website bigger wasn’t the right solution. The company needed a website that would work well both on large screens and on old small screens. This was a problem that could absolutely be solved by a responsive design.
Instead of focusing on phones and small screens, I explained to the client that a responsive design would enable us to effectively present a layout for today’s large desktop screens and also reflow to accommodate laptops and old desktop monitors that don’t have a high resolution.
As we demonstrated a responsive website for the client using a large desktop screen and a much smaller laptop, they got excited and told us that they had hated the “smallness” of the website for years, but their previous designer explained to them that, to support visitors with old computers, they had no choice but to design for this “lowest common denominator.”
Responsive design would solve this problem, and by this point our client was pretty much on board because they saw that it solved a problem they had (the “smallness” of the website), without addressing a problem that they didn’t think needed to be solved (support for mobile devices).

Build For The Future, Not Only The Present

When I discuss responsive Web design with my clients, I rarely use the term “mobile support” because it makes those clients think only of phones or, perhaps, tablets. I instead prefer the phrase “multi-device support,” which better encompasses the wide range of devices and screen sizes we are really designing and developing for these days.
One of the advantages of responsive design is that it doesn’t focus merely on the devices and screen sizes out there today. Because a responsive website reflows to fit a screen of any size, with an experience and a layout suited to each, the approach is very future-friendly. The prospect of having a website that continues to work well into the future, even as new devices and screen sizes come to market, appealed to our client. We further explained that, even if the website didn’t draw a lot of mobile visitors today, it might in the future. A responsive approach would ensure that those mobile visitors get an experience optimized for them.
The client remained skeptical that they would ever attract mobile visitors, but they were sold on responsive design because of the other problems it would solve. Additionally, because we were rebuilding the website anyway, making it responsive at the same time made financial sense. Trying to strap responsiveness onto an existing non-responsive website can be daunting and expensive, whereas incorporating responsiveness early on in the design process is much easier, especially if it is a core part of your process and you’ve developed a workflow for it, which we have. That workflow helped us to make this approach both technically and financially viable for our client.
Moving forward with the project, we knew that we would have to keep an eye on traffic once the website went live to prove our theory about the lack of mobile traffic.

Looking to the future will help us to build websites that work well even as new devices and screen sizes come to market. (Image: Joe Penniston)

Break The Cycle

Two percent of traffic from mobile devices is so low a figure that, when I first saw it, I questioned its accuracy.
This particular company does not market or sell to the general public. It is a B2B company that works with a relatively small group of distributors and contractors from a defined geographic area. The client attributed the low mobile traffic to this demographic, which would access the website from an office desk, not on the road with a phone.
I agreed that mobile figures would likely be lower for this demographic than for a typical audience (for the websites we manage, 30% of traffic comes from mobile visitors, although some websites get over 50%) — but not this low. I felt that something else was happening here, and my gut told me that part of the reason was that the website worked so poorly on mobile devices. I suspected that the lack of a mobile experience kept mobile visitors away.
I did not share this theory with the client at the time, but in the year since the new design went live, the mobile traffic figures have climbed, from 2 to 17%. Granted, that is still lower than what many other websites get these days, but it is a sizeable jump and cannot be ignored.
The only reason we can point to for this jump is the website’s responsiveness. Neither the demographic nor the market has changed. The only difference is in how the website works on mobile devices. The improved experience has increased traffic. This was one of the reasons why I pushed for responsiveness, even when the traffic figures suggested otherwise.

Solving Problems

Part of our job as Web professionals is to solve problems for our clients. But we have to solve not only the problems that the client tells us about, but the ones that they do not even know they have.

Our clients’ problems are opportunities for us to provide high-quality solutions based on our experience and expertise. (Image: Donna Grayson)
With the redesign of the website, our team was able to solve a number of problems that the client brought to our attention, including the outdated design and the absence of a CMS. And our solution to the problem that they weren’t aware of — a lack of mobile visitors due to a lack of support — validated our responsive approach, even when the traffic figures did not show the need for it. We knew that a responsive design would fix the layout on large desktop screens as well as on small old monitors, but would also help turn around the website’s unusually low traffic from mobile visitors, and we were proven correct.
We knew that part of the rise from 2 to 17% could be attributed to existing customers who had been sticking to a desktop computer out of obligation but were now switching to a mobile device. Those users are now able to access the website’s content on their preferred device, confident that they will get an experience suited to the device.
Another reason for the increased mobile traffic is undoubtedly new business. The movie Field of Dreams is instructive here: “If you build it, they will come.” If a website does not support mobile devices, then a mobile visitor will likely leave immediately upon noticing it, never to return. This was part of the reason for the low numbers. But the website no longer turns mobile users away, and the users in turn will not leave as soon as they arrive. Rather, they will find the information they are looking for and might visit again or point other people in their organization to the content. Mobile support encourages mobile use.
By addressing the customers’ problems, including ones that the client was not aware of, we were able to sell a responsive approach. The improved experience has boosted the mobile audience, as well as boosted the leads that the company is getting from the website.

In Summary

Selling a responsive design is no different than selling anything else. It all starts with solving problems.
For this project, we highlighted the benefits of a responsive approach beyond the familiar benefit of support for mobile devices that we normally mention to prospective clients. Here are some of the key points we made in discussing the value of a responsive approach for a website without an obvious need for mobile support:

• We would be supporting a variety of screen sizes that aren’t typically considered when discussing responsive design, including large new desktop monitors with very high resolutions and old small screens with correspondingly low resolutions.
• The website would scale into the future as new devices and screen sizes come to market and as mobile users begin to visit.
• We would save time, money and technical complexity by doing this work now, as part of the redesign process, rather than trying to cram it in later when the website is set.

Dear Web Font Providers

When you buy something, I bet you want it to work. Heck, even if you use something for free — maybe borrowed from a friend — I bet you want it to work. No one prefers hiking boots that are too tight (or too loose), a car that shimmies when you drive faster than 40 miles an hour, or a kitchen knife that can’t cut a tomato. And Web designers don’t prefer fonts that don’t fit a project, fall apart in different browsers or can’t be used in a mock-up.
We also don’t like wading through all of the fonts that won’t work for us in order to find the ones that will. It takes precious time away from other tasks and responsibilities.

You’ve Come A Long Way, Baby!

Six years ago, A List Apart published “CSS @ Ten: The Next Big Thing,” in which Håkon Wium Lie describes the @font-face declaration and announces:

“Two things must happen before Web fonts can take web design to the next level… First, we must ensure the validity of the approach.…  Second, we must convince browser makers to add support for web fonts.”

You Helped Make It Happen: Validity and Browser Support

Today, browsers support Web fonts, and we’ve got the valid CSS to make the fonts work. Of course, as old browsers changed and new browsers (and extended font families) emerged, valid CSS became an ever-moving target.
On the DIY side, a big “Thank you!” to Paul Irish, who gave us the “Bulletproof Syntax” to fool Internet Explorer (IE) into loading the correct font file (remember using a smiley face for the local font name?); to Richard Fink, who gave us “Mo’ Bulletproofer Syntax” to fix a font-loading problem in Android; and to Ethan Dunham, who gave us the “Fontspring @font-face Syntax,” which even works in IE 9. You all thoroughly explained why your syntax works, which enabled each to pick up where the other left off. On top of that, Dunham, your @font-face generator brought valid syntax to those of us who (please, I beg of you) just want our fonts to work.
Web font hosts such as Typekit and Fontdeck deserve a shout out, too. You worked to support multiple weights and styles of a font family cross-browser. Your variation-specific font-family names (which is a shorter and sweeter way of saying, “Hey everyone, you need to use a unique font-family name for each weight and style of a family”) require longer CSS, but they are valid and allow more than four weights and styles to load in IE 7 and 8. Those of us who can’t live without light, regular, bold, extra bold, and black weights are in Web font heaven!

You Went Above and Beyond: Responding to the Needs of Type Designers

One aspect that Lie missed in his article was the need for more Web fonts — how could we take Web design to the next level if we didn’t have a lot of fonts to use? This, of course, meant that you had to gain the trust of the type design community.
You had to protect the fonts.
Remember when type designers wouldn’t design or provide Web fonts without the guarantee that their files were secure? Typekit, your article “Serving and Protecting Fonts on the Web” (2009) laid out how you set up hurdles to “discourage casual misuse” and created a reasonably secure system for serving fonts.
Thanks to everyone’s tenacity, at some point in the last four years, “reasonably secure” was enough for type designers to take a chance. And now they’re hooked. In a recent interview, Jonathan Hoefler and Tobias Frere-Jones of H&FJ said: “We’re requiring that every new project have a way to thrive not only on paper, but on desktop and mobile screens.” How freaking awesome is that?
So, in the span of only six years, you’ve come a long way, baby. Web font syntax is valid and supported by most browsers (our fonts load!); we have thousands of Web fonts to work with; we have multiple options to deliver Web fonts (DIY or through a service provider; and free, monthly, yearly or a one-time purchase); and you are constantly improving your services, so Web fonts are easier to implement and they (usually) load seamlessly!
What else could a Web designer need from you?
I am so glad you asked.

“What About Us?”: What Web Designers Need

Web designers — especially those of us who care about type and are trying to be thoughtful about the fonts we use — need more than access to thousands of Web fonts. Frankly, we need access to high-quality, appropriate Web fonts. And we need to be able to find them.
We’ve visited your websites. Some of you have thousands of fonts for us to use. But you know what? More isn’t always better. Sometimes more becomes more-stuff-to-wade-through-to-find-what-I-want. In 2010, a New York Times article, “Too Many Choices: A Problem That Can Paralyze,” reported on the debilitating effect of too many choices. Too many choices make it harder to choose. How do we know our choice is the best one? How do we know it’ll fit when we go for a hike? And if it does fit, how do we know another one won’t fit better?
Benjamin Scheibehenne, a research scientist at the University of Basel in Switzerland, suggests in the article that debilitation comes not only from too many choices, but also from a “lack of information or any prior understanding about the options.” Hmm. While we’re at it, how do we know it won’t shimmy on the highway?
You’ve given us thousands of Web fonts. Now give us useful information about the options. Help us understand them. Help us ascertain which ones will work best for us. Which ones will work for a particular project. Which ones hold up cross-browser. Which ones will integrate seamlessly in our workflow.

Show Us Your Web Fonts in Context

Most of you show us how your fonts will sort of look in context. You give us just enough to see whether a font might be appropriate to use (“Hmm, this one is a slab serif, so it might work.”), and you help us to eliminate those that definitely won’t work (“Nope, I don’t want such a round-looking font.”). OK, that’s a start. But that’s not enough.
Take a page from history. Before type went digital, printers and type designers sold their typefaces to clients by showing how they looked in context. They’d provide broadsides or books, often setting each typeface in paragraphs at various sizes. They’d show available weights and styles of each family. And because the specimen sheets and books were printed, publishers and designers could see how the typefaces held up when the ink hit the paper.

A specimen sheet by William Caslon, 1728. The typeface is shown in paragraphs of various sizes in both roman and italic. A larger digital image shows other fonts available in the family. If I were in the market for a typeface back in 1728, I’d know exactly what to expect from Caslon.
Not to name names, but Fontdeck, Fontspring, Font Squirrel and MyFonts, you guys only offer the opportunity to test-drive Web fonts in a sentence. The problem with a sentence is that it doesn’t show how the font looks in body copy. Body copy has visual texture, and texture can be pleasing (lively but not intrusive, promoting horizontal movement of the eye) or jarring (with uneven spaces or a strong vertical pull, hindering horizontal movement of the eye). Texture affects readability.
Texture also affects the look of a Web page, and Web designers need to know whether they are picking a font with the texture they need. A sentence doesn’t help us to make a good choice. If you don’t believe me, take a look at the images below. Two fonts that look really similar when set in a sentence look different when set in paragraphs of text.

Cascading sentences from Typekit. Top: Kepler Standard by Adobe. Bottom: Utopia Standard by Adobe. Both are serif fonts with a slightly oval bowl (look at the shape of the “o”) and a high contrast between thick and thin strokes. They look pretty similar to the casual eye. Heck, they even look pretty similar to the trained eye!

The same fonts set as text in paragraphs from Typekit. When shown in paragraph format, we can see the difference. Top: Kepler Standard by Adobe. Kepler has a rounder, “bubblier” feel and looks slightly smaller when set at body-copy sizes. Bottom: Utopia Standard by Adobe. Utopia feels more structured, less round. And, of course, it looks bigger when set at body-copy sizes. Neither of these fonts is “wrong” when set in text. But they look different in paragraphs, and each might be appropriate for different projects.
Now, for the rest of you, Google Fonts, Fonts.com, Webtype and Hoefler & Frere-Jones, you show your fonts in paragraphs. Thank you. But just so you know, not all of the paragraphs are as helpful as they could be.
Google Fonts, your text has too tight a line height, so your fonts all look clunky (see the image below). Fonts.com, you don’t offer enough text sizes; if a font looks too small at 14 pixels and too big at 18 pixels, we can’t tell what it would look like at 16 pixels (just so you know, 16 pixels is a really popular type size for Web text). Webtype, you use a string of capitalized words, so there are too many capital letters, and your fonts look clunky; if you want to show us what your fonts really look like, just use plain text. Hoefler & Frere-Jones, your paragraphs are limited to three lines, with a super-long 725-pixel line length; these paragraphs aren’t delightful to read, and they undermine the quality of your fonts.

Which font would you choose? How paragraphs are set makes a difference. Top: Google Fonts paragraphs have a tight line height. Open Sans looks clunky and hard to read, making it hard to tell whether the font would look good in body copy. Bottom: Open Sans on Typekit. A looser line height helps us to see that the same font is actually a pleasure to read.
Typekit and Typotheque, of all the Web font services I’ve visited or used, you provide the best on-site examples of how your fonts look in body copy. You both provide multiple paragraphs at various sizes, with a good line length and a good line height. WebINK, your off-site solution is also pretty good. Using the FontDropper 1000 bookmarklet, I can drop any of your fonts onto an existing Web page and see how it looks in context. One problem I noticed, though: Your bookmarklet doesn’t drop in an entire font family, so we can’t see a font’s true bold and italic.
Which brings us to font families. I’m sure you’ve noticed that bold and italic versions of a font are sometimes too similar to the regular font, which undermines hierarchy. Other times, the bold is too heavy or the italic too squished, and one or both are hard to read. These are all reasons why we might not want to use a particular font. Plus, sometimes a bold or italic has letterforms that a client simply doesn’t like.
So, to really see how a font works in context, we would need to see how the entire family of weights and styles works together. Unfortunately, none of you do this yet.

Show Us What Your Fonts Look Like on Other Systems and Browsers

I’ve been talking a lot about context. Context is not just a font’s texture in a paragraph or how the font family works together. Context is also where a font “lives.”
As Web designers, we know that our designs are ephemeral, constantly changing based on operating system, browser and screen size. For example, we know that fonts behave differently cross-browser — if they aren’t hinted correctly, then letter shapes, strokes and letter spacing will change in unexpected ways.

If fonts aren’t hinted well, their strokes can change significantly from browser to browser. This font looked great on my Mac (top). When I tested it cross-browser, I ran into problems (bottom). The font is too light to read easily.

If fonts aren’t hinted well, then spacing (both inside and between letters) can change significantly from browser to browser. This font looked great on my Mac (top). When I tested it cross-browser, I ran into problems (bottom). The font gets narrower, and the spacing between letters is erratic.
The only way to know whether a font will work cross-browser is to test it. And let me tell you, testing Web fonts is mind-numbing and time-consuming. (I once cleaned out my garage to avoid testing fonts for a project.)
Thank you Fonts.com, MyFonts and Typekit for providing screenshots of your fonts in different browsers. You present only cascading sentences, but even that helps. Much like Caslon’s printed specimen sheet showed what his typeface looked like in print, you three give Web designers a glimpse of what your fonts look like in use. You show us which fonts to reject and which to consider for further testing.
Hoefler & Frere-Jones, you claim that your new Cloud.typography service creates multiple font files (each hinted and built for a specific browser and platform) and supplies each browser with its unique font file. If this is true, then your fonts should look great across all browsers. If this is true, I might just have to bake you some cookies. But I sure wish you’d provide screenshots to back up your claims. Some things I need to see for myself.

Let Us Use Your Fonts in Mock-Ups

Some Web designers comfortably go from a pencil-and-paper wireframe to building a partial-website-as-mock-up. Others prefer (or are required) to include an intermediate step and mock up pages with a tool such as Photoshop, Illustrator or InDesign.
I know — now it’s your turn to tell me to take a page from history.
Before type went digital, designers didn’t mock up projects using real fonts. Clients certainly couldn’t expect to see such a thing — comps were fine. But since the late 1980s, mock-ups have been expected to “look like the real thing.” And if we want (or need) to show a realistic mock-up to a client, we need access to the Web fonts.
Fonts.com, Font Squirrel, Google Fonts and WebINK, you all supplement Web fonts with free access to desktop (or “mock-up”) fonts for subscribers. Thank you.
Again, unfortunately, none of your solutions are perfect. Fonts.com, you allow access to mock-up fonts for only one day, to “kick off the design process.” I don’t know how it works in your office, but I can’t get anything done in one day. Font Squirrel and Google Fonts, you specialize in free fonts. While I (and my students) love having free fonts to use, access to good-quality body fonts is sort of limited. WebINK, your plugin for Photoshop is a great solution — unless a Web designer prefers to use Illustrator, InDesign or another tool.
Fontspring, MyFonts, Typotheque and Hoefler & Frere-Jones, I know you all offer bundles or discounts for purchasing both Web and desktop fonts, and bundling does take some of the pressure off a Web designer’s wallet. But if you’re a small company or an independent designer, like me, shelling out the extra money just to mock up an idea is hard.
The most promising approach for mock-up fonts might be just around the corner. Typekit, I know you’re working with Adobe Creative Cloud to bring us desktop font sync. I’ve tested it out, and I’m happy to report that it works like a charm. (OK, my old Mac laptop runs more like a tortoise than a hare when I’m running Creative Cloud — but, hey, I can turn it off when I’m not using it.)
I was cynical (who me?) about font synching actually working. I use CS6 out of the box and the free Creative Cloud membership level. But you promised me that it would work with a paid Typekit membership (which I have), and it did! The fonts even stay synced when I’m working offline. This has exciting possibilities.

In Conclusion

I know you guys are busy, so I’ll wrap this up.
One more thing needs to happen before Web fonts can truly take Web design to the next level, and only you can do it. You need to meet the needs of the people who actually choose and use the Web fonts (ahem, Web designers).
Sure, we can all work around these issues. Personally, I’ve got a font specimen page that I use to test the fonts I’m interested in. After I narrow down the options, I can test fonts cross-browser myself. Hours later, if one of the fonts I like actually works, I can go straight to HTML and CSS from my pencil sketch and avoid the need for mock-up fonts.
But here’s the question:

“Why should we have to work around these issues?”

(All Web designers who love to use new fonts, repeat after me, “Why should we have to work around these issues?”)
If it’s important that fonts load in every browser, why isn’t it important to identify which fonts actually look good in every browser?
If it’s important to woo font designers so that you have a lot of fonts to offer, why not show us how those fonts actually work in copy?
Look, Web fonts aren’t just font files that need to be secure and easy to implement. They affect the overall look and usability of a website. They need to be chosen with care. And thanks for the thousands of fonts, but quantity is not as important as quality. A hundred knives that can’t cut a tomato won’t meet my needs when I’m making my kid a BLT.
So, make our lives a little easier. Make our work a little better. Help us find the Web fonts we want to use.
I dare say, you’ll win some affection from every Web designer who has ever looked at the thousands of Web font options and said, “Oh shit. Which one should I use?”
Sincerely yours,

---

P.S. In case you’re interested, I’ve summarized how you’re all doing so far. Web designers who love to use new fonts, I hope you find it useful.
P.P.S. Below you’ll find the official bibliography of the articles quoted above. Otherwise, my students would be very disappointed by my lack of scholarly detail.

• “CSS @ Ten: The Next Big Thing” Håkon Wium Lie, A List Apart
• “Serving and Protecting Fonts on the Web,” Typekit by Adobe
• “Too Many Choices: A Problem That Can Paralyze,” Alina Tugend, The New York Times

(Credits of image on front page: Michael Bundscherer)