Facebook PDQ

Posted on February 15, 2010 by Jeremy Horn

A company can have the best product around, but if the pages are too sluggish, if the product suffers recurring outages, if the user-product interaction is varied and inconsistent, the product’s overall Usability can, and does, suffer.

Quick-UX provides for the rapid, simple and quantifiable assessment of a product’s User Experience (UX). Among the various components that define a product’s Usability, as well as Quick-UX‘s, are Accessibility, Consistency, Recognition, Navigation, and Page Load Time.

In answering the question of Usability, "Can I use it?" the sub-category of Page Load plays an instrumental role. Page Load, often obfuscated or connected with other perceived causes of a product’s dissatisfaction, ultimately, either positively or negatively, presents an unquestionable influence on a product’s overall Usability.

Example: Prompt Load Time (value = 1.0)

When I recently twittered my followers asking for their opinion of a web product that best exemplified a Prompt Load Time, some of the most common responses were…

WordPress and
Basecamp.

But, the product that received the most votes was Facebook.

Facebook is not only a good example of a product with a Quick-UX Usability Page Load Time variable value of 1.0, Prompt Load Time, but also a wonderful example of improvement along the same lines.

Amazingly, as recently as January 2008, Facebook was seen as one of the slowest, most inaccessible social networking products.

Now, Facebook, is one of the promptest, fastest web products, with 350 million active users, 50% of which log on every day, with the average user spending 55 minutes interacting with the product.

Whatever part of the product with which the user chooses to interact, the end result is always and consistently the same… quick reaction and responsiveness – from visiting and interacting with one’s Inbox…

… to participating in conversations in the News Feed.

Should Do

With all the positive efforts being taken, some ‘flourishes’ of the user interface continue to inject a sluggishness into an overall snappy Page Load Time and user experience that would best be redesigned or redeveloped inline with the rest of the product’s established Page Load Time expectations. An example of such an interface event, with sluggishness caused by either the method of display, and/or of content retrieval, is the user action of adding a friend.

If a recent interview with an anonymous Facebook employee is accurate, Facebook can be viewed as being very much on the right track to further improvement of their already Prompt Load Time.

On the continued optimization of downloaded file size and its client-side performance…

"…actually found out it increased the number of page views by 77%, essentially because we were reducing 77% of the page load, and therefore it was loading faster, and thus generating more clicks. We not only reduced our bandwidth, and how much we have to pay for our Internet, but we made the site faster and increased the clicks-per-minute, which is what we’re truly interested in."

On the optimization of server responsiveness…

"…this guy right now is single-handedly rewriting, essentially, the entire site. Our site is coded, I’d say, 90% in PHP. All the front end — everything you see — is generated via a language called PHP. He is creating HPHP, Hyper-PHP, which means he’s literally rewriting the entire language.

"We’re going to reduce our CPU usage on our servers by 80%, so practically, users will just see this as a faster site. Pages will load in one fifth of the time that they used to."

Next…

Over the course of this series we explored many real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Subscribe now (click here) to make sure you don’t miss any part of exploration of Quick-UX, the quick and easy method of generating quantifiable and comparable metrics representing the understanding of the overall User Experience of a product, as well as other insightful posts from The Product Guy.

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

About these ads

Slow Paced Conversation Pieces

Posted on February 8, 2010 by Jeremy Horn

Example: Delayed Load Time (value = 0.5)

Conversation Pieces is a web product that provides an online venue from which indie designers can sell their creations. This product has also earned a Quick-UX Page Load Time variable value of 0.5, Delayed Load Time.

According to a report that Akamai released in 2009…

40% of consumers abandon the site after 3 seconds of load time

23% of consumers stop shopping due to long page loading time

These are 2 concerns that Conversation Pieces would be well served to pay attention to.

Store, Set Up

Bandwidth utilization resulting from the speed of the product’s server(s) plays a critical role in the understanding, and consumer’s perception, of a product’s Page Load Time. However, Page Load Time, the Quick-UX variable, is a quantification of the perceived time it takes to load the page, content, or complete an action. If the product’s page downloads everything in 100ms, but does not show anything to the user for 5, 10, or more seconds, then the page has a Page Load Time problem.

As far as bandwidth utilization is concerned, going beyond the basic hardware of the servers…

unoptimized images
Resizing the used images, reducing the number of colors used, and selecting the proper compression algorithms (GIF, PNG, JPG), can have a tremendous impact on the final file size delivered to the consumer.

uncompressed files
Using products like YUI Compressor or Google Compile on files containing the likes of JavaScript and CSS can remove whitespace and restructure your underlying code to be compact and small in file size.

no HTTP compression
Compressing HTTP requests and responses are very common on many servers and typically demonstrate as much as a 70% reduction in response size, a.k.a. the files the consumer is receiving via their browser. note: depending on your server setup there may be CPU overhead

uncombined files
The more file requests that are made, the more overhead that is involved in the process, and the slower the Page Load Time. Various methods can be used to reduce the files, from using sprites to combine many images into one, to concatenating CSS and JavaScript files.

… all use up unnecessary bandwidth, resulting in superfluous seconds wasted in Page Load Time. Some more best practices to optimizing Page Load Time can be found at http://developer.yahoo.com/performance/rules.html .

Minding the Store

The Conversation Pieces product exhibits occasional, inconsistent delays, everywhere from the initial home page load to the display of various purchasable content .

These delays are most likely caused by the way the Flash and the caching of images has been coded. The resulting experience created is a very real concern in the product’s Usability, with the consumer sometimes waiting, sometimes instantly getting what was requested, with no apparent pattern to the behavior.

Such inconsistency of Page Load Time does more than wreak havoc within the online shopping experience. Beyond the impact on the product’s Usability, there is enough inconsistency present to assuredly have an impact on the actual pocketbook of the company; resulting from consumers leaving to go elsewhere, to a more stable, more consistently usable website.

Should Do

Perceived page load time is the ‘real’ Page Load Time as far as the consumer is concerned. With that in mind, specific steps can be taken to improve the Page Load Time of the Conversation Pieces product.

Focus the product on providing content in manners empowering the rapid actions and decisions of its consumers.
Whether sticking with a full Flash web product, or not, further optimize the dynamically loaded images and perform smarter caching and, especially, preloading of content with better user feedback as to what is actually going on, e.g. image X of Y loaded, W% loaded, Q time remaining.
A good deal of what can be accomplished in Flash can be done in a much more lightweight and prompt fashion via the latest techniques of HTML and JavaScript. With the availability of very powerful JavaScript libraries (MooTools, YUI, jQuery, …) companies are hard pressed nowadays to justify the absolute requirement of Flash over that of HTML.

Next…

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Subscribe now (click here) to make sure you don’t miss any part of this series exploring the Usability and Page Load Time of Quick-UX, the quick and easy method of generating quantifiable and comparable metrics representing the understanding of the overall User Experience of a product, as well as other insightful posts from The Product Guy.

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

Twine Tied Up in Load Time

Posted on January 25, 2010 by Jeremy Horn

Example: Poor Load Time (value = 0.0)

Based on a recent study commissioned by Akamai…

2 seconds = Page Load Time when customers become impatient

Twine is a web product that goes beyond the basic user contributed content model of more familiar sites, like Digg and Mixx, and performs semantic analysis on your contributed content and interests to help identify both related content, as well as additional information of potential interest to each active user.

I have been a user of Twine since being accepted into the early Beta. Beginning with my initial interaction with the product, and despite the evolutions of the user interface, it is apparent that the product’s Usability has been degrading over time — most notably in the department of Page Load Time, earning Twine a Page Load Time variable value of 0.

From the inability to login due to page timeouts…

… to the incredible unresponsive (or barely responsive) interfaces…

10+ seconds later

… Page Load Time is a present and seemingly growing issue of Usability with this product.

One set of interactions, experienced in December 2009, best exemplify the negative impact on Usability of this product experienced due to Poor Load Time. In addition to sluggish interface interactions, for example when expanding the ‘related people,’ that would leave all but the most patient of patient people to conclude the product was merely unusable/broken, was the common and (hopefully) trivial task of accepting a friend request.

From the time starting with clicking the link within the email to accept or check out the friend request, to finally accepting, many minutes of delays and frustration transpired. For every click on the inbox, every time, every action involved in the process, 3-5 seconds was spent waiting, locked in a frozen state, unable to use the product in another way, locked into the current glacial path, of click, wait, click, wait, click, wait…etc.

While the Twine product does have its good moments and days, performing lickety split, the Page Load Time experience is one of (increasingly) frequent and long delays as well as the inability to access and load content.

Should Do

In addition to a basic focus on reliability and duration of Page Load Time, there are other improvements that a product, such as Twine, would benefit…

For the times where delay is unavoidable…
- provide better user feedback to better align the user expectations of time remaining — e.g. progress bars instead of endlessly spinning wheels, clear messaging of server timeouts and delays instead of generic ‘unable to login’ messages
- allow for the asynchronous performing of actions within the product, so that while one action processes, other actions, by the user, can be taken and content explored

Next…

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

Twitter’s Crawl

Posted on January 17, 2010 by Jeremy Horn

Example: Poor Load Time (value = 0.0)

Twitter is fast becoming, and for some already is, an essential communication tool.

Yet, Twitter earns a Page Load Time variable value of 0, due to its intermittent slow performance, but more so contributing to this value are the constant outages felt through the year, month after month.

If the page doesn’t load, if requested action takes an interminable amount of time, if the likelihood of the next user action failing is constantly looming, the overall Usability of a product takes a terrible toll.

In 2009, according to Pingdom, Twitter experienced a total of 20.82 hours of downtime.

Outages of Twitter were not isolated to merely the entire site being unavailable, but also consisted of sub-sections, or sub-features not working or resulting undesirable or unexpected behavior. Contributing to the pervasive problem of Page Load Time is both the inaccessibility of the product as well as the inability of the users to obtain key information (missing updates, etc) and other bugs leading to incomplete or otherwise incorrect Page Loads.

A Quick Study

I quickly examined and compiled a list of incidents that affected the Page Load Time of the Twitter product, distinguishing between total downtime, and partial downtime and information inaccessibility, based upon the public posts on Twitters blog.

http://status.twitter.com/archive

I did my best to not double count any problems, but it was difficult since many of the problems occur so frequently, and it is often difficult to distinguish, from these status blog posts alone, between a persisting problem being experienced or fixed, from that of a new emergence of a similar or same problem. Furthermore, I also excluded the impact on Page Load Time arising from scheduled maintenance/downtime – periods of time over which the user expectation would be most aligned with the product’s promise of Page Load Time.

Some of my notes regarding my review of Twitter’s 2009 product Page Load Issues…

Dec 17	Site Outage	DNS records compromised	http://status.twitter.com/post/288586541/working-on-site-outage
Dec 14	sms service unavailable		http://status.twitter.com/post/283934158/sms-service-temporarily-unavailable-we-are-working-on
Dec 8	unplanned downtime		http://status.twitter.com/post/275824585/responding-to-unscheduled-downtime
Dec 7	unplanned downtime		http://status.twitter.com/post/273515629/brief-downtime
Dec 6	high rate of failwhales		http://status.twitter.com/post/272315876/responding-to-whales

Nov 30	Unplanned downtime	high error rate; tmp disabled list feature	http://status.twitter.com/post/263867698/responding-to-high-error-rate-lists-feature
Nov 23	elevated error rate		http://status.twitter.com/post/254725789/fixing-elevated-error-rate-on-twitter-com
Nov 11	high number of errors		http://status.twitter.com/post/240542434/working-on-high-number-of-errors
Nov 6	elevated errors		http://status.twitter.com/post/235296654/were-looking-into-the-cause-of-elevated-errors-on-the

Oct 21	elevated error rate	http://status.twitter.com/post/219264090/elevated-error-rate-being-worked-on
Oct 18	network connectivity problems	http://status.twitter.com/post/216351172/responding-to-network-connectivity-problems
Oct 13	account lockouts after username/pw change	http://status.twitter.com/post/212318608/researching-username-password-change-problems
Oct 12	errors and inability to tweet	http://status.twitter.com/post/211258987/responding-to-increased-errors-inability-to-tweet
Oct 7	Unplanned downtime	http://status.twitter.com/post/207018761/recovering-from-unplanned-downtime

Sept 10	site slowness		http://status.twitter.com/post/185079863/working-through-site-slowness
Sept 9	secure connection failed issues		http://status.twitter.com/post/183975122/secure-connection-failed-issues

August 24	unexpected service interruption		http://status.twitter.com/post/170695014/we-are-responding-to-an-unexpected-service-interruption
August 16	Oauth and API problems		http://status.twitter.com/post/164410057/trouble-with-oauth-and-api-clients
August 15	unexpected downtime		http://status.twitter.com/post/163603406/working-on-unexpected-downtime
August 11	Site outage		http://status.twitter.com/post/160693237/responding-to-site-downtime
August 6	Site is down	DOS attack	http://status.twitter.com/post/157160617/site-is-down http://status.twitter.com/post/157191978/ongoing-denial-of-service-attackhttp://status.twitter.com/post/157191978/ongoing-denial-of-service-attack
August 2	Search Down	problem coming from migrating data centers	http://status.twitter.com/post/44516325/twitter-search-temporarily-down

July 10	site latency	widespread	http://status.twitter.com/post/139238308/working-on-site-latency
July 5	restoring accidentially suspended accounts		http://status.twitter.com/post/136164828/restoring-accidentally-suspended-accounts

June 15

Outage

problem w/ maintenance by provider

http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific

May 30	unscheduled downtime	fatal software error	http://status.twitter.com/post/115523264/unscheduled-downtime
May 28	unable to create new accounts	captcha problem	http://status.twitter.com/post/114566780/unable-to-create-new-accounts
May 27	site latency		http://status.twitter.com/post/113959453/working-through-site-latency
May 27	Unplanned downtime		http://status.twitter.com/post/113891094/recovering-from-unplanned-downtime
May 22	search down		http://status.twitter.com/post/111769727/search-temporarily-down
May 21	robot errors		http://status.twitter.com/post/111054487/fixing-robot-errors
May 20	user search unavailable		http://status.twitter.com/post/110639419/user-search-temporarily-unavailable
May 14	unplanned downtime		http://status.twitter.com/post/107824532/unplanned-downtime
May 8	latency issues	resulting from a scheduled site maintenance	http://status.twitter.com/post/105202075/back-from-site-maintenance-working-on-site-latency

Apr 28	elevated error rate	fail whales	http://status.twitter.com/post/101237008/fixing-the-elevated-error-rate
Apr 13	slow load times and high error rates		http://status.twitter.com/post/95787359/responding-to-slow-load-times-and-high-error-rates
Apr 9	high latency	also fb not updating	http://status.twitter.com/post/94536362/twitter-com-is-experiencing-high-latency-were-also
Apr 7	high site errors; downtime/load issues		http://status.twitter.com/post/93850673/update-on-delivery-delays-errors
Apr 6	maintenance (no advance warning); downtime		http://status.twitter.com/post/93641925/one-hour-maintenance-starting-at-5-45p-pacific
Apr 6	errors; downtime	fail whales, robot pages; missing tweets	http://status.twitter.com/post/93501130/working-through-some-errors-this-morning
Apr 3	errors; downtime	fail whales, robot pages	http://status.twitter.com/post/92659539/recovering-from-errors-this-morning

Mar 16	unplanned maintenance	widespread slowness	http://status.twitter.com/post/87009894/unplanned-maintenance
Mar 4	problems logging in		http://status.twitter.com/post/83602310/problems-logging-in
Mar 2	power failure	degraded performance	http://status.twitter.com/post/82874378/power-failure-this-morning

Feb 18	latency issues	very long load times	http://status.twitter.com/post/79456053/working-on-site-latency-issues
Feb 14	downtime	db problem	http://status.twitter.com/post/78228774/back-from-maintenance-mode
Feb 11	Site down	db problem	http://status.twitter.com/post/77438630/site-back-up

Jan 20	site slow	slow load times	http://status.twitter.com/post/71824634/slowness
Jan 16	downtime	notified user of potential for more downtime	http://status.twitter.com/post/70991844/twitter-downtime

Dec 17	timeline delays and missing tweets		http://status.twitter.com/post/287676075/known-issues-timeline-delays-and-missing-tweets
Dec 10	problem posting tweets to FB	problem resulting from FB latency issues	http://status.twitter.com/post/277958642/not-all-tweets-from-facebook-app-being-posted-to

Nov 5

missing mentions

http://status.twitter.com/post/234412987/missing-some-mentions

Oct 28	no dmsg emails		http://status.twitter.com/post/226186595/not-receiving-emails-for-direct-messages
Oct 15	timelines 0.5h behind		http://status.twitter.com/post/214053142/timelines-currently-30-minutes-behind
Oct 8	timeline delays	bug	http://status.twitter.com/post/207632462/timeline-delays-this-morning

Sept 16	missing tweets	bug	http://status.twitter.com/post/189862465/tweets-from-users-you-follow-may-be-missing-from-your
Sept 14	missing tweets for some		http://status.twitter.com/post/187786359/missing-tweets-from-some-users
Sept 4	short delivery delays		http://status.twitter.com/post/179752377/working-on-short-delivery-delays
Sept 2	some tweets & followings delayed	small subset?	http://status.twitter.com/post/178076369/some-tweets-and-followings-delayed

August 12

timeline delays

http://status.twitter.com/post/161638570/working-on-timeline-delays

July 28

missing followers for new users

http://status.twitter.com/post/151217980/working-on-missing-followers-for-recently-joined-users

June 29	viewing other people followers/following disabled	bug	http://status.twitter.com/post/132761078/viewing-other-peoples-followers-and-followings
June 16	unable to find new users		http://status.twitter.com/post/124832153/working-to-get-new-users-into-find-people
June 12	search delay	new tweets not being picked up by search	http://status.twitter.com/post/122606485/search-delay
June 3	delayed followings	resulting from spam attack	http://status.twitter.com/post/117482837/delayed-followings

May 13	timeline delays	hardware failure	http://status.twitter.com/post/107561169/temporary-timeline-delays
May 4	search running behind	search not processing real-time	http://status.twitter.com/post/103533181/search-running-behind

Apr 22	data inconsistencies	bug [still being fixed on the 27th]	http://status.twitter.com/post/99180872/tracking-down-data-inconsistencies
Apr 22	missing user images		http://status.twitter.com/post/98960090/missing-user-images
Apr 14	delayed search results		http://status.twitter.com/post/96196695/search-results-are-delayed-about-20-minutes
Apr 10	missing updates		http://status.twitter.com/post/94970050/were-working-to-resolve-an-issue-with-some-missing
Apr 6	missing avatars and dmsgs		http://status.twitter.com/post/93589702/missing-user-icons-avatars-and-direct-messages
Apr 2	not finding self in people search	bug	http://status.twitter.com/post/92334992/not-finding-yourself-in-people-search

Mar 18	missing tweets	db inconsistency, etc.	http://status.twitter.com/post/87625680/some-users-experiencing-missing-tweets
Mar 16	Delays on following and dmsgs		http://status.twitter.com/post/86986973/some-delays-on-followings-direct-messages
Mar 12	missing updates & actions		http://status.twitter.com/post/86067236/some-missing-updates-actions
Mar 11	inconsistencies	data inconsistencies (msg, counts, other data)	http://status.twitter.com/post/85644965/update-on-inconsistencies
Mar 9	inbound sms delay		http://status.twitter.com/post/84921942/inbound-sms-delay

Feb 6	inconsistent follower/following counts		http://status.twitter.com/post/76219963/delays-in-posting-text-messages
Feb 6	txt msg posting delays	problem w/ provider	http://status.twitter.com/post/76219963/delays-in-posting-text-messages
Feb 2	Missing updates		http://status.twitter.com/post/75182201/missing-updates-were-bringing-them-back
Feb 2	missing self	new users missing from search	http://status.twitter.com/post/75102341/unable-to-find-yourself

Jan 30	follower/following counts wrong	due to replication lag	http://status.twitter.com/post/74360199/were-looking-into-inconsistencies-with
Jan 19	slow search	search fell behind realtime due to maintenance	http://status.twitter.com/post/71697063/search-behind-realtime
Jan 8	Delivery delays	tweets slow to appear in the timeline	http://status.twitter.com/post/69184677/catching-back-up
Jan 6	Delivery delays	tweets slow to appear in the timeline	http://status.twitter.com/post/68751921/delivery-delays

That said, a clear picture of the Page Load Time experience felt by the Twitter product’s user base quickly emerged.

Approximately 14% of all days in the year experienced delays and disruptions, directly altering the Page Load Time of the product. And, another ~10% of the year’s days experience pages loading with missing information, resulting in a total number of days experiencing disruption at around 24% of the year or 86 days! (note: there may be some day overlap that is not taken into account in these numbers)

Note: Data for December is complete (only goes through December 21, 2009)

Should Do & A Clear Flight Path

When using Twitter, tweets, responses, searches can and sometimes do occur quickly and without incident. However, with such consistency of problematic service, fail whales, site latency, etc. Twitter earns no more than a value of 0 for Page Load Time; but with a clear path to improvement…

first, focus on the reliability of the Page Load, drastically reducing downtime,
then, focus on the missing data and other inconveniences, some of which are touched upon in my table of notes above.

Next…

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

On the Page Load Time of Quick-UX

Posted on January 11, 2010 by Jeremy Horn

There are some products out there (Twitter comes to mind) that could not possibly have an easier to use interface coupled with a simpler purpose (to say "what’s happening"). However, simple purpose and simple interface are not all that constitute a product’s Usability.

Accessibility,
Consistency,
Recognition,
Navigation, and
Page Load Time.

In answering the question of Usability, "Can I use it?" the sub-category of Page Load plays an instrumental part. Page Load, often obfuscated or connected with other perceived causes of a product’s dissatisfaction, ultimately, either positively or negatively, presents an unquestionable influence on a product’s Usability.

The more engaged a user is with a website, the more they are able to interact, the more they can interact. The slower the website, the slower the rate and capability to engage.

Think of the last time you were shopping online when you made a purchase. Where you able to rapidly get to and purchase the product you sought? The answer most likely is yes. Now, think of the last time you visited a shopping website, where the pages were slow to load. Did you make a purchase? Most likely, the resounding takeaway characteristic you can recall today is one of frustration, in navigating, in seeking, that drove you to other websites — that facilitated your decision process through their greater Usability, and responsiveness.

If the user can forget what they were doing, due to sluggish responsiveness for actions taken in a textfield, the Page Load Time is too slow. The slower a page, the more opportunity a user has to be distracted by other websites, tabs, in-office activities, that can easily pull them from the initial web product.

The perceptions of acceptable Page Load Time are always changing. As the Internet and web continually accelerate, so too do people’s expectations regarding what they consider, ‘instant’ or ‘slow.’ At one point, over dial-up, ‘instant’ was many seconds, or even a minute, but today, a second is nearly ‘instant’, and many seconds is mostly unusable.

Assessing the Page Load Time variable requires very little of your time. However, I do recommend that you average at least a few data points over the course of a day or days to make sure you have an accurate sense of the normal product responsiveness.

If the product typically loads the information promptly (within acceptable expectations) then the Page Load Time variable is assigned the value of 1.
If the product exhibits the occasional, inconsistent delays, use 0.5.
And, if the product (like Twitter) has frequent and long delays (including outages) the value for Page Load Time variable is 0.

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

Can I use it? Evaluating Usability through Quick-UX.

Posted on March 31, 2008 by Jeremy Horn

The first of the 3 primary components of Quick-UX, of which I will be discussing in greater depth, is the one of Usability. Put simply, Usability is a measure of how easy something is to use.

In sticking with the primary goals of Quick-UX (quick assessment for summary, directional guidance, and quantitative comparison) the variables constituting the minimal representative subset for Usability are…

Accessibility,
Consistency,
Recognition,
Navigation, and
Page Load Time.

Accessibility

Accessibility is the measure of how many differently skilled/abled types of people (including individuals with disabilities) in varying locations (e.g. mobile web) can make use of a given product. There exist many, very thorough, guidelines for determining the degree to which a product adheres to accepted accessibility standards. However, many can be very complex and time-consuming, also requiring the study of a good deal of the underlying code — much of which goes against the goals of the ‘quick’ part of Quick-UX.

I use a robust (and free) proxy for quickly assessing a product’s Accessibility through the use of the Functional Accessibility Evaluator (fae) link. The fae’s resultant scores are averages which, in turn, are normalized to a range from zero to one to represent the value for Quick-UX‘s Accessibility variable.

Consistency

Consistency is a fundamental component of Usability. The less learning a new user has to do to use a product the more usable is that product. Products should not have multiple interface elements, page layouts, or content that are used for the same purposes, but vary depending on how the user got their or where they are currently looking.

For example, if the product/site is in the travel industry and the site often references ‘travel search engines,’ a consistency that can grow confusing (inconsistent) is when the language that describes the same engines varies from instance to instance, from ‘engines’ to ‘tse’s,’ to ‘search travel engines,’ etc.

The determining of the value for the Consistency variable is done through the brief surveying of the product, and assigning a…

1 if there are no apparent inconsistencies,
0.5 if only minor, non-intrusive inconsistencies are found,
0 if there exist inconsistencies on major element(s) or a majority of minor elements. Inconsistencies on major elements lead to immediate confusion and second guessing information being conveyed.

Recognition

The measure of the Recognition and intuitiveness of a product conveys how easily an average user of a product can immediately grasp how to use it. When evaluating this Usability variable remember… YOU are NOT an AVERAGE user. The Recognition variable is assessed from the perspective of an average user and is assigned a value of…

1 if the interface and product, in general, feels familiar and is easy to use,
0.5 if some poking, finesse, and interaction are required before the user will be able to gather his or her bearings in the use of the product,
0 if the average user will have clear difficulty understanding (1) how to use the product and (2) what the product is trying to communicate.

Navigation

Evaluating the Navigation variable as it relates to Usability (and Quick-UX) also includes, in addition to site navigation, the review of the site’s flow, transitions, interactivity, and clear communication of progress. If a user can’t figure out how to get from point A to point B, or is not presented with clear information as to how he or she got to point C or that there remain points D through Z to still travel, the overall Usability of the product can be sorely damaged.

The Navigation variable is assigned the value of…

1 if the product presents a straightforward decision process, leveraging animated transitions when appropriate, providing clear feedback, and communicating progress within each multi-stage task,
0.5 if the two following conditions are met:

occasional, but easily correctable, mis-steps in accomplishing tasks and/or completing processes occur, and
there exists a visible current progress indicator for all multi-step tasks,

0 if any of the following scenarios occurs with frequency:
- resultant Interaction or other resultant event occurs contrary to the desired decision path,
- surprised by result of interaction, or
- no communication of progress, flow, or navigation.

Page Load Time

There are some products out there (Twitter comes to mind) that could not possibly have an easier to use interface coupled with a simpler purpose (to say what you are doing) that are frequently rendered barely, or completely, unusable due to entirely unacceptable product responsiveness.

A company can have the best product around, but if the pages are too sluggish, they can achieve a real pain-point in the overall user experience, rendering a product unusable.

Assessing the Page Load Time variable requires very little of your time. However, I do recommend you average at least a few data points over the course of a day, or days, to make sure you have an accurate sense of the normal product responsiveness.

If the product typically loads the information promptly (within acceptable expectations) then the Page Load Time variable is assigned the value of 1.
If the product exhibits the occasional, inconsistent delay, use 0.5.
And, if the product (like Twitter, at the current moment) has frequent and long delays (including outages) the value for Page Load Time variable is 0.

Usability. Quickly. Done.

The quantitative assessment of these variables are structured to provide a quick and painless method of evaluation to form a summary, directional guidance, and/or values that facilitate inter-product comparisons through the answering of the basic question…

Can I use it?

When answers to the above question of Usability is combined with…

Should I use it? (Usefulness)

Do I want it? (Desirability)

… the result is a product’s overall, repeatable, quantitative assessment of User eXperience.

Enjoy! (and discuss)

Jeremy Horn
The Product Guy

The Product Guy

Discussion, advice, and reviews regarding online products, the people behind them and the trends they represent, from Modular Innovation and Product Management to User Experience and Quick-UX.

Tag Archives: page load time

Facebook PDQ

Example: Prompt Load Time (value = 1.0)

Should Do

Next…

Slow Paced Conversation Pieces

Example: Delayed Load Time (value = 0.5)

Store, Set Up

Minding the Store

Should Do

Next…

Twine Tied Up in Load Time

Example: Poor Load Time (value = 0.0)

Should Do

Next…

Twitter’s Crawl

Example: Poor Load Time (value = 0.0)

A Quick Study

Should Do & A Clear Flight Path

Next…

On the Page Load Time of Quick-UX

Can I use it? Evaluating Usability through Quick-UX.

Accessibility

Consistency

Recognition

Navigation

Page Load Time

Usability. Quickly. Done.

Follow “The Product Guy”

Example: Prompt Load Time (value = 1.0)

Should Do

Next…

Share this:

Like this:

Example: Delayed Load Time (value = 0.5)

Store, Set Up

Minding the Store

Should Do

Next…

Share this:

Like this:

Example: Poor Load Time (value = 0.0)

Should Do

Next…

Share this:

Like this:

Example: Poor Load Time (value = 0.0)

A Quick Study

Should Do & A Clear Flight Path

Next…

Share this:

Like this:

Share this:

Like this:

Accessibility

Consistency

Recognition

Navigation

Page Load Time

Usability. Quickly. Done.

Share this:

Like this:

Follow “The Product Guy”