Posts tagged ‘usability’
Proof of Usability Testing Would Help Both Enterprises and Vendors
Recently, we have been evaluating options for a new website feature, which can either be bought or built. If we decide to buy a solution, we can choose from a number of vendors with considerable, specific expertise in this area. Building it would require us to utilize the general expertise of a web agency to design, develop, and test ourselves. The former option, to buy, will require fewer internal resources, but give us less control over the final product.
Less control is acceptable if a vendor delivers unique value that we could not produce ourselves – outsourced expertise. While there’s a number of considerations, one question that we ask each vendor is “Have you conducted usability testing?”
So far, we’ve received perfunctory assurances that they do so, with generic examples provided. It’s leaving an uneasy, wanting feeling. Wouldn’t it be nice to have a more concrete way to evaluate whether vendors can deliver a better web feature than you could build?
I envision a trusted third-party certification that assures us that the product has been built incorporating satisfactory usability testing – like Truste does for privacy. It would be an easy way to help enterprises make data-driven decisions about resources and costs: “this certificate means they have done x, y, and z – are we willing to make that investment ourselves?”
There are two potential approaches:
- a certification that a website is acceptably usable or
- a certificate that acceptable usability testing has been incorporated into its development.
The former seems more immediately compelling, since it addresses results, not process. But the problem lies with defining which standards are acceptable. For example, is it up to the standards for people with disabilities? What about multi-lingual considerations?
Since there are fewer methods of usability testing than there are different needs of enterprises across the globe, let’s consider the latter: certifying the process. As I said above, this is an easy way for us to judge the costs of building versus buying. Without evidence that a vendor conducts good usability testing, among other practices, I’m more likely to think “Hey! We could do this!” After all, I can judge whether the features meets our needs, especially if I’ve done a good job assembling my requirements. I just want to be confident that our members are going to find these great features we’ve purchased for them and want to repeatedly use them.
How to establish this certification is a separate question, and I acknowledge finding a simple way to do so may be difficult. Who should certify? How much does it cost? How broad or narrow would our standards of acceptable testing be? I’ll leave you with those questions and address in a future post. Meanwhile, I’d love to hear your reactions.
Why Twitter Should Re-Name the Re-Tweet
Why would Twitter tinker with arguably its most powerful feature?
Let’s face it, the name “re-tweet” is an idiosyncrasy – one of many on Twitter (ex: “hashtag”). Idiosyncrasies are hurdles to new users. And Twitter has an issue engaging new users. It needs to overcome these issues to ensure it remains as powerful a conversational medium as it is a broadcast medium.
So re-name “re-tweet” what it really is: “like”. The reason we re-tweet is because we read 
something we like. Instead of working hard to educate new users on a unique convention, let’s teach them to hit the “like” button. Easy.
There’s no harm following a popular convention, as YouTube recently demonstrated. And there’s no bigger rival to Facebook than Google, so if they can swallow their pride to adopt a convention that Facebook popularized, Twitter can as well. The change would initially create hassles for the Twitter community, but we’ve survived changes before. And it will be easier to manage sooner, rather than later.
This seems to be a relatively simple way to make Twitter easier to use and maintain the power of the re-tweet. And that will lead to an increase in engagement that will serve all of us better. “Re-tweet” needs to go.
Krug’s “Rocket Surgery”: Excellent Book and Support for your Usability Projects
Like many who read Steve Krug’s excellent Don’t Make Me Think, I looked forward to reading his new book about usability testing, Rocket Surgery Made Easy. It did not disappoint and I highly recommend it to anyone with website management responsibilities.
Krug’s main point-of-view is that inexpensive, in-house usability testing is extremely valuable. He does not demean more extensive usability testing (i.e.: consultants and labs). Instead he preaches that valuable findings can be identified with what he calls “discount” or “do-it-yourself” testing, especially if conducted regularly. Throughout the book, Krug provides numerous to-do’s, advice, and scripts that fit into his framework. In fact, one of these tools has already proved to be a valuable internal reference for me.
Recently, I had advocated to teammates that usability testing should be added to one of their projects. I was met with skepticism, especially to my contention that it could be executed in-house for about $1,000. Enter Rocket Surgery and the handy-dandy sample budget Krug included. I used it in a presentation to demonstrate that, in fact, we can do it for even less than my initial estimate. My only recommended edit is to use the term “qualitative usability testing” rather than “discount usability testing”.
By the way, there’s great bit of inadvertent blogging inspiration in the book, too. Krug says he waited to write his second book, because he “hates” writing. Hey, if he can write two classic books while hating writing, can’t we all pull together a few blog posts?
Let me know what you think of Rocket Surgery and if you plan to use it as a reference to advance your projects.
(disclosure: book links are affiliate links)
My New Droid
Two weeks ago, I bought a Droid. Why? I love great gadgets, but I am not a gadget freak who has to have the latest and greatest. Nevertheless, my BlackBerry is an irrelevant old model and our iPod Touch is of course phone-less and camera-less. I wanted greater social capabilities on-the-go.
The good news is it has mostly delivered.
Good: elegant integrations between functions, camera picture quality, on-screen keyboards, and the screen itself
Bad: a bit buggy, call clarity, too heavy, too easy to hit the bottom permanent buttons when screen is sideways and…
physical keyboard is a disappointment. I am using it to type this post and just this much has taken 13 mm so far. And my thumbs are sore. A blogging machine this ain’t.
Overall, though, we’ve become inseparable because there is so much to do and explore.
My favorite apps so far are HootSuite and RoboDefense. Let me know if you have any recommendations!
Five Lessons in Web Design and Usability from the New York City Subway
Bob Noorda passed away in Milan on January 11. Who was Bob Noorda? In the 1960’s, he and Massimo Vignelli designed the New York City subway signs. Their designs were so well-crafted, that they remain in place today over 40 years later, and have achieved fame far beyond their original mission.
It struck me that, given the history and complexity of the New York City subway, this success provides a number of lessons for web projects – especially within large organizations
1. Clean and clear design
When you’re trying to help people navigate a system as large and chaotic as the New York city subway, it’s especially important not to give people one more thing to think about. Mr. Noorda is quoted as saying “don’t bore the public with mysterious designs”. He utilized a plain, clear typeface (Helvetica) and consistent verbiage and formatting.
Likewise, most website visitors aren’t too interested in learning a “mysterious design”. They want clear “signs” that point the way to information they’re trying to find.
2. Scope
If you are unfamiliar with the city, you may not know whether the Guggenheim is uptown or downtown. But once you do look at a map and determine a route, you’ll be in good hands when you enter the train station. You may get sidetracked by the infamous garbled service announcements, but it’s simple to find which track gets you uptown or downtown, to the Bronx or to Brooklyn, and which is the express and which the local.
This is a key point. The subway signs design would have gotten bogged down if had tried to do more, because, above ground, New York is too chaotic to capture in this context.
3. Data-driven design
“I remember when Bob came to New York and spent every day underground in the subway to record the traffic flow in order to determine the points of decision where the signs should be placed” his partner Massimo Vignelli said.
Sounds like Noorda watched how people were using the subway, and used that data to design a highly usable system. This is a great reminder not to let a good opinion get in the way of facts.
In fact, the New York Times obituary says that Mr. Noorda’s simple designs were initially resisted by groups within the M.T.A. (the organization that runs the subway). Unsurprisingly, the data-driven design eventually won the day.
4. Focus on the customers’ experience – not your organizational silos
The subway system as we know it today resulted from the mergers of a number of different agencies. The signage of the day reflected this lack of cohesion. For example, this schedule from 1948 shows that subway riders had to sort through multiple naming conventions to find their route (e.g.: IND lines had adopted letter names before the other agencies did). The Times obituary also states that “the existing signs they encountered were cluttered with various typefaces of different sizes.” Mr. Noorda was quoted as saying “sometimes pieces of paper taped to the wall were the only indication for the station.”
Think you would have been able to find the Guggenheim?
5. Optimize! Optimize! Optimize!
In the 1980’s the M.T.A showed us that there’s always room for improvement.
Noorda’s color-scheme, which had identified each train by a different color, was a key piece of the system’s usability. The M.T.A. improved upon his convention by consolidating the color-scheme, so that related train routes would now share colors.
Compare the iconic subway map of the 1970’s to the present day version (below) to see how this change not only simplified, but added context to the color scheme. Now, if a train has a green color, for example, you know it will travel down Lexington Avenue in Manhattan.
I hope this reference is a good selling point for web usability going forward. Now if they can only fix those garbled announcements….
My name is Adam Gross. 
