Google, Stanford, and The Government Fight Swine Flu

by:   |  Posted on

Bolt | Peters recently collaborated with a team at Stanford University on designing the Google Sites template for local governments to use as a backup to deliver information on the H1N1 outbreak, and also disasters and emergencies in general. The goal was to create a template that was well laid-out, easy for non-techie local governments to edit and update with content, and conveyed the most important information to different audiences.

Swine Flu info template

 

How It Started: The Quick Fix

With the recent outbreak of H1N1, Santa Clara County’s official public flu information site was taken down by the surge in web traffic. To help relieve the demand, the Stanford SIE Program, a Stanford University group that develops technology for social change, stepped in literally within hours of the interruption to create an ad hoc backup site using Google sites, so people could still access the critical info.

This is the version of the site they originally posted, using Google Sites’ standard WYSIWYG editing tools:

Stanford's original stopgap design
Stanford’s original stopgap design

After the site went live, Stanford trained the Santa Clara County maintain it and add their own information. Santa Clara County needed to have site that could handle the traffic and get the information out as quickly as possible—which is to say that there wasn’t a whole lot of time to think about design.

This experience made it clear that it would be valuable to create a well-designed, easy-to-edit template for local governments to distribute information in case of emergencies—not just H1N1, but any public hazard, including floods, earthquakes, wildfires, and so on.

The team contacted us in late October with the original draft of the website. Since it was important to make the site available as soon as possible to deal with the ongoing H1N1 outbreak, so the timeline we had for design recommendations was really brief—just a few days. With that in mind, we got to work.

Spotting the Problems

Because of the layout restrictions, our design evaluation focused primarily on information design. We had two main issues with the early design, along with a handful of usability tweaks here and there.

First draft of Google template

1. Lack of visual hierarchy.

With two columns of equal width and mostly indistinguishable boxes filled with text, it was hard to tell at a glance what information was urgent, time-sensitive, or recently added.

2.
Big chunks of info, no
 organization

The info wasn’t grouped into meaningful categories—there wasn’t much visual or spatial distinction between contact info, prevention info, calls to action, and so on, making it difficult to zero in on information even if you know what you were looking for. Also, the info came in big blocks of unscannable prose, and deep reading is the last thing you want to do when you’re trying to learn about the tsunami headed your way.

3. It didn’t anticipate the distinct needs of the most critical user
segments.

There was plenty of good info on the site, but it was never clear who a given piece of info was for—you couldn’t scan the page headers and think, “Yeah, there’s what I’m looking for”. Instead it had a “general audience” feel to it; the info didn’t take into account that different groups might have different needs and different levels of urgency.

4. Buried info.

Vital info on vaccines, symptoms, and SMS / Twitter updates was absent from the front page entirely, lurking deep in the navigation.

Our Recommendations

To keep editing simple for the local government end-users who would be using the template, we had to stick to using the WYSIWYG Google Sites editor, which meant no custom CSS and very little control over layout. We also had literally a single day to make our recommendations and synthesize them into a first-draft mockup—the result wasn’t pretty, but got our main info design recommendations across loud and clear.

First revision of template
Our first stab at redesigning the H1N1 template

Redesign Goal #1: Prioritize information according to the urgency
of visitor need.

Our design takes into account that there are different “general public” user segments with different goals, and that there are tiers of urgency and priority. From most-to-least urgent, we identified these segments:
* People infected with the flu: Immediate help / contact info
* People worried that they might have the flu: Self-diagnosis
* People concerned about catching and/or spreading the flu: Preventative measures and vaccine info)
* People just curious, staying informed: Information about travel restrictions, public response, news updates, deep flu info

The structure of the site was altered to serve each of these segments:
# We added a page-width alert box that would be displayed to convey urgent, time-sensitive info—this is a common feature on many of Google’s sites, as well as CNN.com.
# A yellow-shaded box to give the highest priority group, currently affected individuals, clear instructions on what to do.
# The left-column contains info on self-diagnostic and preventative measures for at-risk or concerned individuals.
# The top-right contains info on vaccines; below is links to deep info, research, and update notifications. Though the Google Sites template didn’t allow us to resize the right column, we noted that it should be made smaller than the left column.
# The left sidebar navigation was reserved for redundant quick links to most important info, as well as links to pages for specially affected individuals and organizations.

Redesign Goal #2: Reduce block text down to easy-to-scan lists
and chunks.
Cut the bureaucratic BS.

We broke down the block text to keep from overwhelming users with too much difficult-to-scan information upfront. Lists were kept to under 8 items long, unless they broken down into categorized sub-lists; text was kept under five lines. All information that couldn’t be condensed in this way was moved to lower-level pages, and linked from
higher-level pages.

 

Users don’t need to know what the mission statement and goals of the organization are; they just want to know if and how they are personally affected, and what they can do in case they are affected.

Redesign Goal #3: Use informative headers that directly address
user goals, and which give all users clear next steps.

All types of visitor (e.g. directly affected, at risk, concerned, just curious, administrative, medical, etc.) should be able to tell by the header if that information is “for them”. We tweaked the headers to make it clear what kind of info you could find in each section. We also made it clear what, if anything, each user segment needed to do:
* Immediately affected individuals are given step-by-step instructions on how to deal with their
emergency situation(s).
* At-risk individuals are given step-by-step information on preventative, precautionary, and self-
diagnostic measures.
* Individuals seeking non-urgent information can be given supplementary external information
resources (by phone, online, and downloadable / printable) and means to stay updated (by email,
text, RSS, Twitter).
* Urgent contact info is immediately visible in the right sidebar.

The First Revision

After we sent over our recommendations and mockup, a member of the team sent us a nice note a day or two later:

You’ve convinced us that we have to completely rethink and redesign the site from scratch, so
your style guidelines come at a very good time. I can’t thank you enough for opening our eyes to
how we can do this in a much better way. I think we can create a site that works much better than
the original site.

…and then a few days after that, Stanford sent a revised version over to Google, who worked with the design firm OTT Enterprises to create two new designs with some added visual design flourishes.

Unfortunately we don’t have permission to show you this revision yet (working on it), but it wasn’t bad—certainly cleaner and better organized, easier to scan, less dense. There was, however, a large distracting green gradient background, some empty space in the sidebar columns, a few stock photos, and a muddled color palette (green, blue, yellow, and gray).

Our second batch of suggestions focused mostly on visual design and layout. Just a few of them:

Visual Design

* Get rid of the gradient background; it’s distracting and confuses the emphasis on different parts of the site, since it runs behind multiple different elements.
* Get rid of the green coloring, which is tertiary to the blue and yellow. Instead, use several shades of blue as the primary color and a little light beige or light grey as a secondary trim. Blue signifies authority, calmness, trustworthiness, etc., which are of course appropriate here. Notice how almost every major government agency’s website (including the CDC) uses dark blue and gray as the main colors.
* Remove the stock images, including the CDC and Flu.gov widget images, which look like ads. The phone and email icons are fine, however.
* Rather than images, make the content headers stand out with size and strong typography—”make the content the focus” is an old web design adage, and the content, in this case, is the flu information. Here are a bunch of sites that use typography, font size, whitespace, and bold layout to create emphasis, using few images [list of a bunch of websites].

Layout

* Header and upper-page content takes up way too much space—note that the important info (”If you or your child…”) doesn’t begin until more than halfway down the screen. Compress.
* I like how Design #2 places the alert and contact info in the sidebar; in Design #1 the sidebar is wasted space. This frees up space to move important info (Vaccine and How to Care for Someone With The Flu) up to the right side.
* This design consists mostly of links to deeper pages, but there’s definitely room to put more specific, useful info right on the homepage: symptoms, preventative measures, vaccine info (see our original design)
* Get rid of the Contents box.

The Results

Stanford started over once again, aided by our style guide and input from OTT Enterprises. After further iterations in Google Sites, they handed it over to the Google visual designers, and here’s the before-and-after:

Before
Google Sites template, super rush draft

After
Google Sites Public Health Template 1.0

Can you do better?

As with all things on the web, the template is a design-in-progress, and will be improved as time goes on. Stanford SIE is looking for feedback on the design, so here’s where you can send feedback for the Public Health template and the All Hazards template. Since these Google Sites templates are available to everyone, you can even make your own design edits and mock up improvements.

Or if you just think it’s great and you just want to use it yourself, here’s the complete list of links:

Google Sites Templates blog post

Public health sites:

Template
Example site
User guide

All hazard sites:

Template
Example
User guide
Stanford SIE site (we’re credited here!)

Note: Nate and Tony’s book on remote testing, “Remote Research”:http://www.rosenfeldmedia.com/books/remote-research/, will be published by Rosenfeld Media in 2010.

Four Key Principles of Mobile User Experience Design

by:   |  Posted on

Prior to becoming a senior UX designer at Popular Front Interactive, I spent two years as a mobile UX researcher within the Georgia Institute of Technology’s Mobile Technologies Group – a lab tasked with both future-casting and then rapidly prototyping innovative mobile experiences.

As I transitioned from academia to industry, I discovered that while mobile UX was discussed, it wasn’t discussed from the same broad frame of reference that I was used to within the confines of a research-based institution. Although more recent mobile UX conversations I have found myself in have undoubtedly benefited from the ongoing smart phone revolution, overall I still find these conversations to be needlessly driven by tactical adoration and lacking a conscious consensus regarding the fundamental principles of the mobile-user experience.

I do not presume these following principles to be all-inclusive or ultimately authoritative; rather, it is my hope that they are received as an anecdotal summation of my findings that might then spark and contribute to the larger conversation and consensus-building process.

 

PRINCIPLE #1: There is an intimate relationship between a user and their mobile device.

While an intimate relationship between an individual and their mobile device may seem like a given, the depth of that relationship probably goes deeper than most initially realize. In fact, I argue that the relationship extends to a physical level and the exchange of bodily fluids.

Imagine that it is a hot summer day and someone asks if they may borrow your mobile device to make a call. You hand it over. What level of trust does this simple act portray? Consider those around you right now: How many of them would you loan your mobile device to without hesitation? In your social circles, is it acceptable to decline such a request? How does context influence this scenario? What if you are at work? At a bar? How about a family reunion?

Let’s assume that this person is noticeably respectful of your device and the personal data it contains while making their call. At the call’s completion, the individual immediately and graciously returns it, whereupon you notice that it has accumulated an amount of … goo (perspiration, humidity, etc.) that is typical of mobile device use on a hot, sticky summer day…but then again, it isn’t your goo.

From a gooey physical level to a level of data privacy and security, there is an intimate bond between an individual and their mobile device, the strength of which often elevates the mobile device to the status of iconic personification. I am my phone. My phone is I.

In order to meet user expectations, mobile experiences should assume a semi-guarded state of primary usership; however, we must also responsibly protect our users. As the trend of embedding ourselves into our mobile devices increases, so does the cost of our devices being compromised. Assume primary ownership, allow for secondary usership, and plan for what might happen should we lose ourselves.

In a worst-case scenario, a compromised mobile device containing a significant amount of personal data would become the networked equivalent of a voodoo doll, where actions performed via the mobile device could cause actual harm to the individual personified by the device. In cases such as this, a remote wiping of all data on the device may be a user’s only recourse. 

 

PRINCIPLE #2: Screen size implies a user’s state. The user’s state infers their commitment to what is on the screen.

Imagine that you have been looking forward to seeing a particular blockbuster movie since the day it was green lit, and now that the day of its release has finally come you are going to get the most out of the experience by going to see the movie on the largest IMAX screen in the tri-state area.

Let’s say that when you finally take your seat in the sold-out theatre, you notice the person sitting next to you has a very annoying laugh. There is nowhere else to sit in the theatre, and you’ve been dying to see this movie for more than a year. What are the chances you abandon the experience and walk out? Probably fairly slim to none.

Now let’s say that you were backpacking through Europe when the above blockbuster was released, and that you have been equally anticipating the movie’s Blu-Ray release. To celebrate the release, you and your friends are gathering at the home of the friend who has an impressive home theater featuring a 52-inch HD screen, and again you find yourself seated next to the guy with the annoying laugh. Now how likely are you to abandon the experience? Probably more so than above, but still not likely.

What if this scenario played out in a college dorm room and the movie was being viewed on a 22-inch computer monitor? What if you were sitting next to the guy with the annoying laugh? The chances that you might abandon the experience are probably increasing.

What about a mobile device’s 3.5-inch screen? Is there any way you would sit next to some random person with an annoying laugh for 90 minutes to watch that movie? Probably not.

Although there are any number of social and environmental factors that would affect the user abandonment rate in the experiences described above, it is consistently possible to estimate a user’s level of commitment to an experience based upon the size of the screen through which they are engaging it.

Since mobile devices are likely to be the smallest screens in a user’s experience, the design of mobile experiences must accommodate the user’s varying commitment and distributed attention. How an experience accommodates these conditions will change depending on experience type — game, banking application, or the like — but the underlying impetus remains the same.

 

PRINCIPLE #3: Mobile interfaces are truncated. Other interfaces are not.

A dreaded task that usually accompanies getting a new mobile device is the act of transferring your data from the old device to the new. In years past, this meant arduously re-entering all of your contacts via the device’s, most likely E.161 (12 key), keypad.

There were a few early, notable attempts to ease this burden. GSM service providers pushed device manufacturers to save all user data to the devices SIM card by default, but the card’s limited storage capacity produced a poor user experience. On the other hand, CDMA service providers began automatically transferring address books between devices as a customer service. Even early on it was widely acknowledged that although an individual wanted to use information on their mobile device, they would go to great lengths to avoid having to manually enter that information.

Palm, and later Research in Motion, sought to improve this fact of mobile user experience by introducing and then proliferating the practice of syncing. This concept paired the truncated mobile interface with a full-sized desktop interface, allowing the user to easily and reasonably efficiently enter their address book data via a familiar QUERTY keyboard. Although this feature was initially limited to smart phones, it has since been incorporated into a wide swatch of consumer-grade devices. In fact, the notion of syncing has become so ubiquitous in mobile computing that the syncing of one’s entire networked identity is a core plank of Google’s Android operating system.

Even as miniaturized QUERTY became and becomes a more standard feature for all mobile devices, the truth remains that mobile interfaces are truncated and better used for manipulating data rather than entering it. One might conclude that as mobile devices continue to incorporate increasingly impressive sensor arrays, even standard, consumer-grade devices will provide powerful data collection capabilities. Regardless, data collection is not data entry, and data entry is not likely to become a mobile-appropriate activity. 

 

PRINCIPLE #4: Design for mobile platforms — the real ones.

There is a prevailing tendency is to discuss mobile platforms in terms of device manufacturers and service providers. This is understandable. It is fun and easy to get caught up in the moment of the latest tech demo, press release, or rumor. However, in needlessly binding the dialogue to the news of the day, we create unnecessary segmentation across an already complex landscape. The overall conversation is better served by focusing on the mobile platforms that have emerged as constants over time. Those four platforms are voice, messaging, the internet, and applications.

 

Voice

Voice was the original mobile platform, but it is also the platform with the most nebulous future. Don’t get me wrong: People will always need to make an occasional phone call. However, the frequency with which we are doing so is declining. Why? Mobility is as much about efficiency as anything else, and telephony (vocal communication and vocal response interfaces) has proven more difficult to optimize compared to other methods of interactivity.

For example, let’s say that you wanted to verify that your paycheck had been deposited. Most banks offer both tele-banking and online account access. Which interface are you likely to use, and why? How about if you wanted to order a pizza? Would you rather call, be placed on hold for five minutes, and then dictate your order to a multi-tasking teenager, or would you rather just use a GUI to do it?

 

Messaging

Friedhelm Hillebrand, the architect of the messaging (SMS) specification, described the platform’s limit of 160 characters as “perfectly sufficient.” The question we must ask ourselves in considering this mobile platform is, “Perfectly sufficient for what?” Although Hillebrand can provide several reasons for how he arrived at the 160-character limit, the one that I have always found the most interesting is that his team discovered that most postcards typically contain 150 characters or fewer.

Have you received or sent any postcards recently? If you have, they were likely either brief social communications (“Having a great time. Wish you were here!”) or they were simply task-oriented such as RSVP-ing for a wedding or canceling a subscription.

Messaging trends today continue to affirm Hillebrand’s postcard comparison. The vast majority of SMS traffic consists of social interactions within small groups of individuals. The second tier of usage is comprised of simple task-based transactions such as voting, entering contests, and receiving notifications.

In both cases, SMS and postcards, content-heavy experiences are a minority occurrence as the media is not designed to accommodate such a level of engagement. Furthermore one could argue that due to the designed efficiency of the messaging platform, that a content-heavy experience would be far from appropriate. 

 

The Internet

The Internet is the most awkward of the mobile platforms in that it is the one that is the least natively mobile. Currently almost 95% of all Internet users experience the web via displays with resolutions of 1024×768 or greater. As such, 1024×768 is observed as a fairly universal standard and is what a significant portion of Internet-based experiences are designed to. Given that mobile displays typically range between resolutions of 60×120 and 480×320, it is fairly obvious that most Internet-based experiences aren’t designed with mobile users as a primary consideration.

As a means of making Internet-based experiences more accessible to mobile users, most mobile web browsers have been designed to include adaptive methodologies for displaying larger experiences on smaller screens. While these adaptive tactics, which typically employ pan and zoom-esque interactions, have undoubtedly made more of the Internet accessible to mobile user, one could hardly argue that it has resulted in a desirable user experience. In fact, if browsing the Internet from a desktop is regarded as a scanning activity, than browsing the Internet through the adaptive lens of a mobile browser might best be described as a squinting activity.

As mobile web usage has continued to emerge as a somewhat common activity, the assumption that Internet-based experiences are to be automatically adapted for mobile users has given way to the design of alternative experiences specifically for mobile users. While this trend has provided mobile users with more efficient and scannable web experiences, it also has the potential of overplaying the users’ expectations for Internet-based mobile experiences.

As Internet-based mobile experiences have become more device-centric and sophisticated, they have begun to resemble mobile applications, thus creating a scenario where users might expect the Internet-based experience to function as a mobile application would. The distinction between desktop applications and Internet-based experiences may be rapidly evaporating, but it remains germane in the mobile experience. Although there are several differences between the platforms, the primary point of contrast I will draw here is that applications are able to use device-level services such as sensors, ad-hoc networking, and optics, whereas Internet-based experiences cannot. While mobile browsers are beginning to make some of these services available to Internet-based experiences, each platform will always have affordances the other doesn’t. As such, and to manage user expectations, if an experience looks like an application and attempts to behave as an application would, then it should be an application — and vice-versa.

 

Applications

From a technical standpoint, applications represent executables that are native to a specific mobile environment, have been selectively installed, and have access to the device’s full array of available functionality. However from a UX standpoint, they represent a specialized interaction design that caters to an affluent, sophisticated, and targeted mobile user base.

As few as 24 months ago, the seemingly basic task of locating and installing an application on a mobile device required a fairly developed skill set. With the recent proliferation of “app stores,” this task has become more user friendly; however the percentage of users who are able to install an application on their mobile device nowhere near approaches that of those who know how to make a phone call or send a text message. So, regardless of recent improvements to the overall process of acquiring and installing a mobile application, the user who can perform this task would still be considered sophisticated compared to the overall segment.

All things considered, mobile applications might best be described as the boutique mobile platform. As is the case with most boutique experiences, a comparatively small audience will compensate for itself through fervor and zealotry. However, since the success of an application-based mobile experience is based almost entirely upon acceptance within that small audience, extraordinary attention must be paid to the particulars of the target audience’s needs and behaviors. What existing need is the application attempting to mobilize? What efficiencies can a focused interface bring to that workflow? How can the specific affordances of a mobile device augment and improve upon that experience in contrast to using one of the other mobile platforms?

Mobile applications are powerful tools…for a relatively small segment of individuals who want them and know how to use them.

 

Conclusion

Someone tweeting on behalf of Punchcut once wrote, “In mobile UX, don’t confuse precedence with standard.” I couldn’t agree more, but as I hope that I’ve successfully illustrated, this statement is well ahead of where the conversation should be. Both standards and precedence are both tactical perspectives. Within our context, they both represent distinct libraries of interactions and are either redefined as the landscape evolves or simply replaced as more elegant solutions are brought to market.

The variable nature of each of these categorizations only further demonstrates why it is best for the current mobile UX conversation to focus on higher-level principles rather than tactical particulars.

As mobile UX designers, we have both opportunity and choice in front of us. The opportunity is to establish the foundation principles of a stable, yet still emerging, experiential space. The choice lies between getting caught up in the excitement of the fad du jour or asking ourselves the difficult question of what foundational principles am I following, or establishing, with the work that I am currently doing.

The only unfortunate part is that the time we have to make this decision is quickly running out.