Strategic Web Designer

Strategic Web Designer

The Strategic Web Designer

By: Christopher Butler
Publisher: HOW Books
Pub. Date: August 22, 2012
Print ISBN-13: 978-1-4403-1502-2
Web ISBN-13: 978-1-4403-1504-6
Pages in Print Edition: 176

The Case for the Web

If apps are not the best format for content, then how does one account for mobile technology in a comprehensive digital strategy? My belief is that the web provides a strong answer by naturally accounting for the weaknesses of apps in its most basic attributes. In particular, there are three web-centric principles that can provide strong guidance as you are assembling a mobile approach.

1. Content First, Content Second

Most of the conversations we have with our clients about mobile technology involve planning for how to account for existing web content in an overall mobile strategy. The key point here is that, in the context of these discussions, the existing content has already proven itself and there is a recognized need to extend its accessibility across wider conditions - namely, to mobile users. But invariably, as we work on adapting content templates for mobile devices, we start getting requests to build new types of unique content - essentially separate, mobile-specific versions of websites. That’s where the logic gets unproductively circular - why are we all of the sudden talking about creating new, unique content when the entire conversation started around making the existing content easier to consume for mobile users? If we were to take that route (for which there could be good reasons), the new content would be untested - a risk. But the existing content has already met the demand test. That is why mobile strategy should proceed from content, not the other way around.
By the way, this principle extends to particular technologies, as they can become a barrier, too. For instance, video, which might generally be accessible on the web implemented with Adobe Flash-based players, won’t work on most mobile devices. The solution, of course, isn’t necessarily to create new video content. Rather, it should be to facilitate wider accessibility to the existing video content by choosing the right technology that works in all contexts. YouTube is a good solution for this.

2. Use Unique URLs

I hope I already made clear why a lack of URLs is a weakness of apps. On the web, the question of where a piece of content exists is almost always relevant - to the humans that search for it, interact with it, share it and save it for later, as well as to the search engine bots that crawl the web indexing it. In short, addresses matter. Imagine if you went to visit a friend at an apartment building but did not have their apartment number. The best you could do would be to knock on every door on every floor until you found the right one. We take this for granted on the web, but had there not been a web version of the Wired article I mentioned earlier, I would have had no way to direct anyone else to it.
In January 2011, Mathew Ingram, a writer for GigaOM, was interviewed6 for an episode of CBC Radio’s Spark podcast about this very issue and had this to say:
… apps as individual, controlled experiences are good for some things. I’m pretty convinced it’s not the best thing for things that have to do with media, with content. The whole lifeblood of content is the sharing, the linking. Whether it’s apps or websites, if you look at the ones that don’t do that I think you quite quickly come to the realization that they’re missing something fundamental.
I completely agree.

3. Create Seamless Experiences

The first priority for creating content in a long-term digital strategy should be to facilitate seamless user experiences across a variety of contexts, from desktop to tablet to smartphone. A working example of this comes from Google Books (I first considered this in a blog post I wrote in March, 2011),7 which successfully preserves the essential reading experience regardless of the device you use. It is difficult to express how incredible and revolutionary that really is - that I can read a bit on my desktop and pick up exactly where I left off on my tablet or phone without giving any thought at all to bookmarking. Google has made seamlessness innate to their books experience. Of course, the book itself is closer in nature to an app like the Wired magazine example, in that it is one file without a master URL or locations for individual chapters or pages. But, it still serves as a great standard to strive for in terms of seamlessness of use. Just imagine what that could mean for content on the web that is truly optimized for reading. I’m confident that we will be able to bring the same level of fluidity to all web content in the not-too-distant future. In fact, that is what the responsive web design movement is all about.

The Case Against Apps

I’m not categorically against apps. On the contrary, I think apps are quite suitable for a variety of purposes; in particular, productivity, gaming, communications and one-way, consumable media are all types of applications that work quite well in the mobile context. But apps are not an ideal format for wide and unmonetized content distribution. In addition to a format mismatch, the economic and practical factors surrounding the creation and distribution of the apps themselves are, in my opinion, indicators that the long-term sustainability of the app paradigm is unlikely. I have three main complaints in my case against apps.

1. Ecomonmic Oligarchy

The charge of economic oligarchy is, admittedly, more of a political complaint I have with the way in which the overall apps marketplace has been established. But in that it is political, I feel that it fundamentally contributes to the imbalance and unsustainability of the apps economy. Presently, there are only two companies that control almost the entirety of consumer app-related commerce: Apple and Google. And while scores of developers are understandably excited about their 70 percent cut of the revenue generated by the sale of their applications, the economic conditions will always remain drastically in favor of the very tippy top.
At the time I last investigated, there were more than nine hundred thousand unique mobile applications available for download. That’s a staggering number considering the relative recency of the launch of the two app marketplaces, which, by the way, have already seen more than twenty-eight billion downloads combined. The activity and the revenue have reached far beyond anyone’s expectations. Since there’s so much money to spread around, all the application designers and developers must be doing quite well, right? Not exactly. Consider this: The average price of a mobile app is a paltry $3.64. Only an unusually prolific individual could expect to get rich developing apps, whereas the owner of the entire marketplace has only to open the doors, so to speak, to generate significant wealth. Additionally, Apple and Google have tight control over which apps make it into their inventory. These factors result in a system that is not exactly an innovation breeding ground. The real innovation has already happened - the creation of the marketplace itself. The next big thing is much more likely to come from outside the app marketplace (like, say, on the web), where fewer controls exist to stifle such things.

2. Unnecessary Redundancy

If you are a designer or developer, the pain of inefficiency should resonate with you, even if you have never created a mobile app. Because of the platform division between the two major marketplaces, not to mention others like the Windows Phone and Amazon Kindle Fire, developers are forced to build their mobile apps several times in order to make them available to the largest number of potential users. The Apple and Android platforms are proprietary systems with unique technical requirements. Economic competition, of course, is the only real reason for this - and, in my opinion, it is not a good enough reason to validate the resulting doubling, tripling or quadrupling of effort. Surely there are plenty of competitive angles that could be pushed as far as the devices themselves are concerned (e.g., form factor, feature sets and network carriers) that a standardized approach to app development could be possible. But for now, that is not the case. It’s not only the developers that suffer under these conditions. If I were considering green-lighting the production of a mobile app, I would be frustrated enough by having to fund essentially the same thing twice to consider it a legitimate barrier to entry. It is only a matter of time before that pressure results in developers either limiting their capabilities to one platform or the other (which, in and of itself might make sense - Michael Surtees, a principal of Gesture Theory, had some thoughts on this that are worth considering),4 or rebelling en masse and forcing the app dictators to tear down the wall between them (hyperbole intended). My hope, of course, is for the latter.

3. NO URLs

As a web enthusiast, the lack of URLs for apps and the information they contain is my biggest complaint against the app marketplace. Without a protocol for locating the information contained within an app, its ability to be found and shared is nonexistent. Here’s just one example: Wired was one of the first major publications to release an iPad app version of its magazine. I eagerly anticipated trying it out after seeing many demo videos and generally buying into the hype that preceded it. When it did finally launch in May of 2010, I immediately looked it up in the Apple App Store, paid the $3.99 for the first issue and waited several minutes for it to download. I spent some time “flipping” through it, but it was not long before I gave in to disappointment - you know, the kind that you deny for a while in order to avoid the sting of shame that comes from naive capitulation to undeserved hype. Yes, I thought it was going to be wonderful. No, it was not. The main reason? No URLs!
The Wired app has a nifty time-line interface that lets you “zoom out” to see all the articles contained in an individual issue. It’s a nice UI idea, and not a bad way to navigate the issue on a tablet. But suppose I read an article in the issue and then wanted to share it with with a friend or among my social network. There is really no good way to do so; the article itself doesn’t have a specific address of its own, nor does the issue as a whole. The best I could do would be to link to Wired Magazine’s listing at iTunes.5 The article I read is an undifferentiated, unlocatable piece of the issue - the 500 MB glorified PDF that we’re calling an “app.” Sadly, this is not just a hypothetical scenario; this very conundrum presented itself to me within an hour of downloading that first issue. Being the savvy and resourceful web user that I am, I went to www.wired.com, found the article I liked and sent a link to that URL - the web version - to my friend. Just a second or two later, after clicking “Send,” I thought, Why didn’t I just start here in the first place? You know, on the web - where, for the most part, the exact same content offered by the $3.99 app is available for free, along with additional sharing and engagement opportunities the app version lacks.
This is my central objection to “appified” versions of content that have a more natural, flexible and indexable incantation on the web. Rushing to hop on the mobile app bandwagon has resulted in a thoughtless trend of cramming content into impenetrable shells. If you searched for information that would best be supplied by content in a mobile app, you wouldn’t find it with Google. (And sadly, you would be just as unlikely to find it using Apple’s App Store search tool, which falls far short of being useful.) But you would find it in plenty on the web. For those creating content simply to share or for marketing purposes - as a means of describing expertise and educating prospects about a product or service that could be useful to them - the locating and sharing limitations of apps undermine the very purpose of content, whereas the inherent nature of the web provides the platform upon which it can fulfill it.
Between the economic factors, the practical inefficiencies of development and the lack of URLs, apps are currently subject to a system that almost seems intent on stunting the potential of content. Of course, looking at the sales numbers of mobile apps, you might not think anything was wrong. I certainly don’t want to rain on anyone’s parade, but something is wrong when the outcome falls far short of the promise. When it comes to apps, we should be clear in admitting where they lack many of the things that make the web great.

What to do?

As these visualizations demonstrate, referral traffic is one of the most important sources of data that you have available within the analytics environment. Beyond the inclination to be gratified when someone else links to you, studying referral traffic will yield a deep understanding of the rich ecosystem in which your website exists. Look at your own referrers. You’ve probably got some robot-referred activity (Search), some less-than-familiar social network stuff (Twitter, Facebook, LinkedIn) and probably even some from your own marketing initiatives, like email campaigns. But what about more influential recommendations? You may not be able to get a nod from the President, but I’m sure there are influencers within your network that would love to point people your way. If you haven’t done so already, seek them out. Don’t ask for a link (that’s so 1998), but build a relationship with them so that the referral is implicit in all kinds of activity between you, whether that be within social networks, participation in blog conversations or something else. You may even be able to deepen that relationship by writing articles or creating other content for them on their turf. But don’t expect to reconvert the already converted - those who already subscribe to your content or have engaged with you in some other way. Focus your efforts on spreading new seed in the most fertile ground you can find. The “sweet spot” of the familiarity spectrum is going to be just shy of the most familiar audience you have, probably among those connected strongly to an influencer with whom you could build a strong, mutually beneficial relationship. By looking closely at your conversion data and using the techniques I have described in this chapter, you should be able to pinpoint whom that might be.

Understanding Bounce Rate

Because the term bounce rate describes traffic that moves away from your website, it’s often the metric that causes the most concern. What’s worse, some get overly focused on hitting a very particular percentage without thinking about where that percentage comes from and what it applies to.

The most important principle I have learned about bounce rate is so obvious it often gets completely ignored: The bounce rate only applies to traffic that landed on a page. Unfortunately, Google Analytics makes that principle a little too easy to ignore by sequestering landing page data in one report and commonly displaying visit and bounce rate values on most others. You see, a visit is any view of any page, but a landing is a visitor’s first view of any page on a website; all landings are visits, but not all visits are landings. To determine the exact number of bounces from a particular page, you must combine data from two different reports in Google Analytics - the Top Content report (or Content Detail report) and the Top Landing Pages report.

Google Analytics’ Top Content and Content Detail reports list the bounce rate along with the total number of unique visits but exclude landing data, creating the false impression that the bounce rate should be applied to the total number of visits. But as we’ve learned, the bounce rate should only be applied to the number of visitors that landed (first entered the site) on that page - often a much lower number than the total visits, which means that the bounce rate is also likely lower than you might initially conclude. By merging data from both the Content Detail and Top Landing Pages reports, you can create a new custom report of your own that will help you to better understand the traffic to any page.

Let’s explore an example to see how this works. I’m going to throw a bunch of numbers at you - real-world data, so they’re not going to be tidy, round numbers, either - as well as a bit of math, so just take it slow and stick with me.

The Content Detail report in Google Analytics will tell you about the activity on an individual page of your website.

The Content Detail report above tells me that a total of 5,863 unique visitors have come to an individual page on my site in the last month. Because this page was promoted midmonth (you can see the resulting spike of activity), I can assume that most of the visitors arrived to my website for the first time by landing on this page, but without checking the Top Landing Pages report, which will tell me the exact number, I won’t know for sure. In fact, I’m likely to apply the bounce rate shown on the Content Detail report (29.19 percent, which I’ll round down to an even 29 percent) to the total number of visitors, which would create the impression that 1,700 visitors bounced. That may be more than actually did bounce.

The Top Landing Pages report in Google Analytics will tell you about the pages that serve as entry points to your website for first-time visitors.

After checking out the Top Landing Pages report, I learn that 5,539 visitors landed on this page, slightly less than the total visitor number. Now, between these two reports, I want to be able to reconstruct the story of all the visitors to the page. I can do this by focusing in on the visit numbers, the bounce rate and also the percentage of visitors that exited the site after viewing this page (29.04 percent, which I’ll also round down to 29 percent).

My first step is to subtract the number of visitors who landed on this page from the total number of unique views of the page - that’s 5,863– 5,539, which leaves me with 324. If I apply the exit percentage (29 percent) to this number, I am left with only 93 - the number of visitors to this page who came to it from another page on our website but then decided to leave. This is different from the bounce rate, which, as I mentioned before, identifies the portion of landing traffic that left the site without viewing any other pages. To determine the number of bounces, I apply the bounce rate (29 percent) to the number of users who landed on this page (5,539), which gives me 1,606 bounces. This is less than I thought before investigating the landing traffic data.

By doing this bit of math, I now know that out of the total 5,863 visitors to this page, 5,539 entered my site for the first time on it (landed), 1,606 left right away (bounced), 93 left our site from this page after having viewed other pages (exited) and 4,164 continued from it on to other pages. Now 1,606 is only 23 percent of the total traffic to this page, leaving 4,257 others that at least saw some additional content on my site - that’s 73 percent of its total traffic.

As you can see, separating the data and doing a little bit of work to get the numbers right is worthwhile. If I hadn’t done this, I probably would have assumed that a 29 percent bounce rate (granted, a very low rate) for my web page meant that 1,700 of its visitors bounced, when in reality, 1,606 of them did. That may seem like an insignificant difference, but consider this: The difference is not just a number, it is 94 more people than the Content Detail report made it seem. In human terms, discovering an additional 94 people that were exposed to your message is very significant!

What DOes This Mean For Conversions?

If I apply a custom segment to these reports, I can get an even more detailed view of the story of the visitors to my page. Creating a custom segment that adds in conversion data to my reports will enable me to see which visitors to this (or any other) page ended up completing a goal - say, filling out a contact form, registering for an event or subscribing to my newsletter.
Suppose that 2,900 visitors of this page (49%) also completed goals and that the Top Landing pages report tells me that 2,750 of these were completed by visitors who landed on this page. That leaves the remaining goals (150) completed by those non-landing visitors (324). If I parse these two amounts, I can conclude that 95% of landing traffic to this page converted, while only 46% of visitors that viewed this page among others during their session converted. Because this page is a landing page for our website’s newsletter, it makes sense that landing traffic would be compelled to sign up for our newsletter (the main conversion point available on this page). These numbers show me quite clearly that the page is doing exactly what it was designed to do.

Measurement Is a Way of Life

Measurement means all kinds of things to different people. In the early days of the internet, web masters, content to simply count traffic to their site, slapped visitor counters onto their home pages. The higher the number, the more the glory (and, oh, the glory when that counter advanced into the thousands!). But once database-driven websites became more common, the coveted hit - the metric everyone had come to obsess over - became irrelevant. After all, the number of times a call is made to your database, especially for graphics-heavy sites, is irrelevant to any meaningful measure of success. Eventually we got a bit more sophisticated, thanks to tools like Urchin and WebTrends, and began talking about true visits - unique website user sessions - and measuring them with enthusiasm. But even visits don’t tell us much more than hits. We all know that now. The truth is that the volume of traffic a website receives is a far less relevant indicator than the action taken by the visitors that make up that traffic. This insight, the steady refining of meaningful measurement, is what led Google Analytics to sweep us all off our feet and begin our new romance with website data. By setting goals that correspond to visitor actions, we could truly see if our investment in the web was paying off. We learned that user engagement was the best measure of success.
Well, I think we all believe we’ve learned it. But my experience has been that, in order to tell the real story of what’s going on with your website, you have to do a bit more than just track the numbers that Google Analytics - or any other tool - provides in their preconfigured reports. Measurement is a discipline, not an isolated step in the web development process. It does not happen just once; it is best made a routine. The long-term value of your website will grow as you regularly draw actionable conclusions from your measurement that help you to improve it. In order to do that, you’ll ultimately need to create your own custom reports that answer the questions that only you can ask, those influenced by your unique story: why you built your website in the first place, what you hoped to achieve with it and how you’ve nurtured it over time as your business has changed. Remaining grounded in your ongoing story will enable you to focus your measurement, to extract meaning from metrics. Losing sight of it, on the other hand, will quickly reduce your practice to a pattern of repetitive and meaningless number watching. I’ll return to the idea of creating unique reports later. But first we need to get acquainted with the language of measurement.
There are three core terms that encapsulate a corresponding series of big-picture questions that measurement should help you answer in lieu of those only-you-know-to-ask questions. These terms - referrers, top content and bounce rate - represent concepts with which everyone should be familiar when reviewing analytics data, especially for the first time.

The Three Big Questions

1. Who is driving traffic to my site?

The simple answer to this question is search engines … and everyone else. Google Analytics will help you make sense of this by breaking down your website’s traffic sources, which it calls “referrers,” into a tidy list ranked by visitor volume. If you’ve optimized your pages for search engines - specifically by paying attention to the on-page factors I outlined in chapter 6 - you should be noticing an increasing volume of traffic referred from search engines. Google Analytics will also show you the most commonly used terms that led searchers to your site. Keep an eye on those. If they don’t correspond with what your site is about, rework your metadata, especially your title tag. The goal here is to receive visits from the people who are looking for someone like you but don’t know about you yet. As for the rest of your referrers - that long tail of unique sources comprised of everything from links you leave in blog comments to social media and press mentions - they can represent very valuable traffic in the aggregate that you’ll want to nurture, as well. In fact, I’ll dive a bit deeper into this in the last section of this chapter.

2. What are the most popular pages on my site?

For most websites, the home page will initially receive the bulk of new visitors, keeping it at the top of Google Analytics’ Top Content report. But that does not mean it will always be the first page that every visitor sees. On the contrary, many of your site’s visitors will enter on a subpage of your site. Indeed, as your website’s content grows, the number of entries to subpages will likely exceed those to the home page. Take a look at your site’s top content and think deeply about the impression users might have after entering your site through them. While that alone is likely to cause you to rethink the information they contain, drill down a bit deeper to follow the entrance paths and see what pages users tend to navigate to next. Getting a realistic sense of flow from the user data will help you to refine the information architecture of your site.

3. How many of my site’s visitors leave unsatisfied?

User satisfaction is often expressed in terms of a website’s bounce rate, one of the most misunderstood metrics you’ll encounter in Google Analytics. Put simply, the bounce rate is the percentage of visitors who entered your site but did not continue browsing it, either because their browsing session expired or because they left your site without visiting any other pages. Consequently, conventional wisdom deems the lower the bounce rate, the better. After all, the idea is to gain and keep visitors. A high bounce rate can be the result of web pages with poorly optimized metadata, which can give search engines and their users a false sense of what they’re actually about. If a user searches for one thing and lands on a page that is hardly related to her query, it makes sense that she wouldn’t stick around. This is why a website’s bounce rate is typically seen as an indicator of user satisfaction. However, larger sites - both in terms of content and traffic - are likely to have high bounce rates even if most users are satisfied. The more pages a website contains, the wider its topical scope is likely to be, which in turn will attract users with all kinds of needs that, while they may be addressed by individual pages, are not in line with the site’s overall purpose. For example, a user may find an isolated article about web typography helpful or interesting, but that user may not explore the site that contains it any further if they’re not actually looking to hire the designer who wrote it. Such a user would register as a bounce, but who’s to say that she was unsatisfied? Perhaps she will return again someday, when she needs a designer, or refer someone else to the website. As we learned in chapter 3, the mind of the audience is mysterious, and not all website content should be created for a single persona. Today’s influencers, though their activity may increase a website’s bounce rate, are quite possibly tomorrow’s decision makers. It’s troubling enough that a website’s bounce rate is so often qualitatively misunderstood, but sadly it is just as often quantitatively misunderstood. I’ll explain how bounce rate percentages properly apply to website traffic numbers later in this chapter, in the section on Understanding Bounce Rate (page 95).
These three questions are what you might consider “Measurement 101.” But what if you want to go deeper? As I mentioned earlier, the best way to do that is to gather data and assemble custom reports based upon your finely tuned and informed questioning.

Gathering Data

Google Analytics does a great job of presenting a vast array of data in many meaningful reports, but those reports can also be confusing or not quite configured to tell the particular story you’re looking for. With that in mind, I’m often inclined to pull the data out of Google Analytics and into another context in order to make the connections I need to see in order to discern what’s actually going on with my website’s traffic. Fortunately, Google Analytics offers the ability to export any report in just about any document format you might need.

I can’t emphasize enough the benefit of exporting Google Analytics data. You just won’t be able to make certain connections by only viewing isolated reports - particularly if you’ve been doing basic website measurement for a few years now and are ready to go deeper. Sometimes, in order to answer the more meaningful questions you have about your site, you’ll need to create your own reports that draw from multiple analytics sources. It was by doing this that I came to an interesting conclusion about how referral traffic actually converts. In order for those conclusions to make sense, however, I need to clarify a few things about bounce rates.