Websites/Mozilla.org/One Mozilla/Documentation/Checklist-UX

originally published by cbrodigan, Feb 2012

Pre-Launch

Create Personas

Personas will help you design an experience with an audience's attitudes and motivations in mind. They can be complex or informal, depending on your needs.

A persona then helps to define who the users are for your product, so you might include:

• Attitudes (as they relate to your context)
• Behaviors & Tasks
• Humanizing elements:
  • Name
  • Photo
  • Tagline
  • Demographic info
• Skill level
• Environment

Example: /firefox Product Site
You can think of personas as categories of users. For example, when designing for the /firefox product site, we design for at least four personas ("matching the right user with the right build"), because we're serving up four flavors of Firefox:

• Firefox GA - non-technical user
• Firefox Beta - semi-technical user
• Firefox Aurora - very technical user
• Firefox Nightly - ultra-technical user

Adam "WebDev" Parker

• Used Firefox for years, but currently uses Chrome for its speed and developer tools
• Loves speed more than anything else when it comes to browsers
• Is an advanced web user, who develops mainly on a macbook and uses iOS products exclusively for his mobile devices
• Is looking for a strong Chrome alternative that has powerful developer tools
• Needs information on Developer Tools as well as the latest Firefox Download (and release notes)

Determine Primary Goal

Each page on your website or webapp should have a primary and achievable goal. Think of this as the problem that you are trying to solve.

Example: /firefox Product Site
On the /firefox product site, the primary goal is "Download Firefox for Desktop."

Build Use Cases

Use case is a fancy word for story. These are the stories that provide context for the copywriter, designer, and developer who are working with you on your site.

You can write use cases very easily, answering the following questions:

• Where does a user come from when she arrives to your website, webpage, or particular area of your webapp?
• How does she feel when she gets there?
• What steps does she need to take to accomplish the primary goal?

Example: /firefox Product Site
V1-Simple:

• The user should be able to download Firefox within 30 seconds.

V2-Complex:

• The user would like to learn more about how Firefox uses geolocation.
• She should locate the /features page, read the description on how Firefox uses geolocation, understand it, and then be compelled to download Firefox."

Note: The second example is broader and more exploratory, where success can be more difficult to measure. A broad user goal can be useful in identifying areas in which to do further examinations.

Map the User Flow

All users come to a website, web page, or inside of an app experience from somewhere. Mapping the user flow before implementation helps the copywriter, designer, and developer understand the different ways in which users will find this information.

Places users come from

• Organic keyword search/SEO (how Google organizes your website's information)
• Clicking from a static element:
  • top & sub-navigation
  • direct link from link a home or sub-page, Paid Search Ad, email newsletter, social share inside of Facebook or over Twitter)
• In-browser notifications

(those are just a few of many!)

Checklist:

• Do you want your product discoverable by search engines like Google? (if yes, read SEO checklist)
• Are users who share a link to your product, sharing the best "snippet"? (if yes, read SEO checklist)
• Are you able to better target users that also increases their level of qualification (e.g. on the /firefox site if we over-market Aurora to the wrong user, we might lose a great GA user)
• Who else do you need to work with to get your site, page, or app positioned for some direct-linking love?

Accessibility

Outside of optimizing the experience for typical users, set aside time (a few hours will do wonders) to work with a developer to improve how your website, web page, and app can be viewed by:

• screenreader users
• keyboard-only users
• users who have difficulty processing text (e.g. users with a cognitive disability)

Checklist:

• Is text easily re-sized?
• Have you included keyboard shortcuts?
• Are form fields clearly labled?
• Is intuitive alt-text present on all images and media files?

Tips:

• Group related sub-points and sub-navigation links into lists
• Front-load links into sentences
• Offer a text alternative that provides the same information for non-text assets
• Include a synchronized alternative for multimedia (never auto-play multimedia it will run into conflict with the screen reader being able to read the page)
• Avoid grey typeface

Design for Sharability

People share things for all sorts of emotionally complex and simple reasons. When you design something, it's important to plan for how, when, and where it might be shared. Sharing is a powerful and authentic marketing tool.

Create compelling cases for why a website, web page, or app is sharable

• Improve the quality of an aspect in someone's life (e.g. faster browser = get more work done)
• Improve a user's social status (e.g. early adopters revel in being first to discover)
• Increases the likelihood that someone will share something reciprocally

Determine sharable assets

• editorial content - blog posts, articles, individual web pages
• multimedia content - videos, audio, photos/slideshows
• coupon content - invitations, discounts, etc.
• geographic content - a direct link that will lead a user back to a particular place on a website

Schedule the best opportunities for sharing

There are times for sharing and times for withholding just a little bit for a better time. For example, if there's a blog post, moving the share closer to the end of the article (or having it in multiple places) can be helpful, because someone just finishing an article is likely more motivated to share what she's just finished reading.

• Immediate sharing is designed largely for editorial content, especially a thought-provoking article, fabulous slideshow, laugh-out-loud video
• Interval sharing is designed largely for user flows, after the user completes the primary goal. While not immediate, it can actually be more fulfilling for the sharer.

Example: Foursquare
Apps like Foursquare leverage interval sharing, so after your first check-in you post and receive a badge that you can chose to announce to your friends on Facebook, Twitter, and Foursquare itself.

Example: /firefox Product Site
For the /firefox product site, the main action users take is downloading Firefox. Post-download isn't necessarily the best time to ask a user to share this information. She hasn't launched the new browser, so anything she might say or share is less informed. (exception: "Download Day" was an epic use of immediate sharing)

We're working to include more sharing on pages like the What's New and First Run pages, which appear when a user launches the browser after a download/upgrade.

Determine sharing features you want to build for
Social networks and email are the two primary channels to build for.

• Social networks: Twitter, Facebook, Google+ (there are other more targeted niche networks)
  • @ Mozilla we use a universal sharing component [Sandstone link to go here]
• Email - this is an important and lately overlooked feature, even today most users are on email not social networks.

Post Launch

Audit for Drop-off

Drop-off rate is the rate at which users bounce off of your site, page, or out of a web-app experience. No matter how well-designed, there will always be a few leaks somewhere, including those that happen when the wrong users arrive at the site.

Example: /firefox Product Site
We have multiple funnels for the following user flows:

• new user arrives on /new downloads Firefox Desktop
• existing user on latest Firefox Desktop arrives at /fx
• user who downloads Firefox for Mobile (more than likely a desktop user)
• user who downloads Firefox Sync (more than likely a desktop & mobile user)
• user who follows Firefox on Twitter
• user who "likes" Firefox on Facebook
• user who follows on Twitter & likes on Facebook
• users who arrive at /firefox/new in Chrome, Safari, or Opera

We create funnels around 3-points of acquisition:

• Step 1. download Firefox
• Step 2. connect socially "stay in touch via Twitter/Facebook/Google+"
• Step 3. sign-up for a newsletter

Our funnel for each use case looks like this:

• Site visit (100%)
• Download (70% - this is our conversion rate for each experience)
• Social connection (#of likes/follows/+)
• Return user on latest desktop version of Firefox (this is where we present a new download, usually mobile)
• Recurring use (this is where we engage users from What's New & First Run pages)

When a user arrives at the top of one of our major download funnels we attempt to learn why she doesn't download and bounces from the experience.

Recently, we've been learning that we need to enhance our SEO to create the right snippet message about the product the user might be looking for, serving the expected experience helps to decrease bounce rate.

Choose an Area to Improve

Even the best website, web page, and application has leaks. Post-launch, starting with one area will help target your efforts and move the needle. For instance, if you're trying to increase downloads of the latest Firefox, don't expand the scope to include an analysis of how to improve social sharing. Keep it simple, focused.

Checklist:

• Record a baseline (state of your current data)
• Determine which layer of the funnel you want to improve
• Specify where & what your are you? (this could be as simple as having the wrong snippet of copy showing up in Google results or as complex as having removed a critical download button)

Tips:

• Small design and copy changes can have a large impact
• Measure change and compare it to the baseline

Example: /firefox Product Site & the Case of 3.6 Downloads
At the time I'm writing this, the /firefox site is leaking a lot of 3.6 content and creating a conflicting experience around downloading the latest Firefox v. 3.6. "3.6" is the 10th most popular keyword that brings users to the website.

• Challenge: We still support 3.6, but we are urging users towards the latest build.
• Baseline: Page views & 3.6 download numbers
• Leaks: Take a look at how users are seeing our active 3.6 support in Google searches for the keyword "Firefox" here
• Small design & copy change: Bug 722856 is working to solve that with revised ux, new messaging & a new page title More on this challenge on Tracking Bug 722848
• Measurement: Coming soon!