Interface Mason

Nice to know when you're thinking like the big boys

My last two posts separately covered the pitfalls of imitation and the importance of context. So when I saw that usability giant Jakob Nielsen covered the same two points in largely the same way in his August 23rd 2010 AlertBox it was as if Babe Ruth had come up to me and congratulated me on my swing of the bat.

See below for an excerpt ...

Should You Copy a Famous Site's Design? (Jakob Nielsen's Alertbox)

Jakob Nielsen's Alertbox, August 23, 2010:

Should You Copy a Famous Site's Design?

Summary:
Although successful websites typically have high usability, average sites can hurt their business by copying design elements that don't work well in other contexts.

When faced with a design quandary, bosses are often inclined to say, "why don't we just copy X?" where X is some high-profile, successful website. There's something to be said for this strategy; presumably, Site X is doing something right, since they're so big and famous.

Furthermore, users prefer well-established designs that follow conventions and work as expected. For example, having a search box in the upper right corner increases the usability of your search simply because this is what users are accustomed to using in the location where they expect to find it. (See my book Eyetracking Web Usability for more examples of where people tend to look for various design elements.)

But copying successful designs is not a foolproof way to improve your own site's business value. Indeed, this strategy has many pitfalls.

(Note: When I say "copy," I don't mean that in a literal sense � that is, I'm not advocating copyright violations or design theft. Rather, I'm assuming that once you've considered the pitfalls and decided to go with a feature or design that's similar to a big site's, you'll create a new site that's inspired by that site's example. If you fear that your copy is too close to the original, consult a lawyer, but if you feel the need to do that you're probably already going too far.)

Why Copies Can Fail

There are two main reasons why copying another site can go wrong, even if that site is highly successful:

• The specific UI element you're copying is not that good.
• The design works fine in the original site's context, but it's no good in the different context offered by your site.

We recently ran a usability study of 17 big and famous websites: Amazon, Apple, BBC, Chase, Cisco, CNN, Facebook, Flickr, Google, Johnson & Johnson, Kayak, Netflix, TigerDirect, WebMD, The White House, Yahoo, and YouTube. Indeed, our research confirmed that these sites do many things right and have substantially better usability than the more average sites tested in many of our other projects. In fact, the big sites' success rate was 3 percentage points higher than the average for other sites.

Still, the study identified boatloads of usability problems in the big sites' user experience.

via www.useit.com

Remember -- just because a UI paradigm is used by a big successful site or company, does not mean it's a good paradigm in and of itself.

Beware the Idea Frankenstein

I was working on a portlet design with my partner on the project who we'll call Joe. Both the width and height of the portlet was fixed. Problem is, it needed to display multiple nuggets of tabbed-out text and each nugget could easily include more text than could fit in the space allotted.

What to do.

Two issues: how to present the overflow and how should its presentation be triggered.

My thought was a fly-out containing all the text that was triggered when the user moused over any part of the truncated text body. 

Joe liked the fly-out but not the way I suggested it be triggered. He was convinced the user needed a mechansim, a trigger which enabled him or her to conciously choose to see all of the content. He felt that mousing over the text body was too easy a way for the user to mistakenly pop this fly-out even if he/she didn't mean to and that this could be an intrusive, disturbing and annoying paradigm that could cause users to reject the portlet and that was the last thing we wanted.

His thought was a text link at the end of the truncated text that read ... more.

If I hadn't been so thrilled to be working with a UX professional who wasn't suggesting we make the text in the portlet scrollable ( any UI/UX designer worth their salt knows that the idea of scrolling within a scrollable area, i.e. portlet on a Web-page, is generally retarded ), I might have made the following two points: First, that if the user's cursor is anywhere near that portlet, they're going to want to see everything it's got to tell them by definition and that the tabs were far enough away from the text as to render accidental fly-out firing a matter purely of easily-acquired user expertise. Second, that easier is quicker. Users had a lot to do while using this page and would always be on the phone with a customer in the course of using it. Users had to get in to this screen, get what they needed and then quickly move on. I felt that the milliseconds of time it took for the user to steer their cursor over some fussy little link the size of a grain of rice could be better spent elsewhere. If all you really need is for your user to just throw a ball, why require them to throw a strike?

But Joe was sharp as a tack, had a degree in human factors and maybe he knew something I didn't. Plus he was a full-timer showing me the ropes and I was a contractor on the job for only three weeks. Part of what he might have been doing was devising a design he could sell to our stake-holders. In the end, our disagreement over this small point wasn't the important part of this lesson learned anyway.

"Idea integrity" was.

We took one half of an idea and sewed it to another without considering the leftovers.

During user testing with our prototype, when users moused over the more link, they were expecting to see only that content that was previously unavailable, not the whole thing. They had to take a moment to adjust to the idea that what they were seeing in the fly-out was the portion they had already seen, together with the unseen.

Jarring and weird.

My fly-out was inspired by the ghostly pale-yellow tool-tip-like fields that tend to wax and wane over long links and other globs of truncated text in the Windows environment on mouseover. In this paradigm, one need only mouse over the truncated text, not pull a trigger somewhere. Joe's 'more' link was inspired by the kind of thing one sees at the end of a paragraph on a particularly long Web-page that is designed to shoot you to the rest of its content. The former promises totality, the latter promises continuation. We had connected two incompatile ideas in an unholy union and now it was chasing us around the laboratory bent on strangling us both.

We eventually evolved the solution into something we think will be embraced, but the lesson ties back to so much of what goes wrong in UI design: Bastardized ideas floating around without the context from whence they sprang. A good argument for rigorous user testing because it would otherwise never have become apparent to everyone. In my own defense, I had my doubts going in.

So when you find yourself podging a solution together out of parts of other ideas, don't be surprised if the villagers have the following reaction ...

UI design fundamentals: Do you have the right stuff?

User interface design happens as surely as the sun rises in the east. It's inevitable. Whether you let your developers design your UI or your BA or your PM or an experienced user interface designer, someone or some set of circumstances is going to determine your user's experience of that software.

The only question is whether or not that experience will be a constructive one.

UI design is tough because it's highly conceptual and many of the other disciplines involved in software design are far more linear: They have beginnings, middles and ends. The temptation in some of these other disciplines is to decide UI design is sort of a fancy suit you dress your software up in to make it more presentable when it's all done.

True, UI design has its more superficial components: what is the color scheme? what will the buttons look like? what fonts should be employed?

But UI design is not JUST these things any more than a tasty cake is just the frosting. Effective UI design, to really extend the metaphor, is a crucial ingredient that must be mixed in from the beginning and baked into the process.

In the words of Steve Jobs, "Design is how it works."

Which means that if you're coming up with some new product, some new application designed to address a unique business need or client requirement, you have set about to determine how something will work. And if you're doing this, you are facing a number of unknowns.

One way to handle unknowns is imitation. How has another successful product handled a similar problem in the past? Imitation is a powerfully persuasive solution because it is presented alongside direct evidence of its viability: "See, if it's good enough for Microsoft, it's good enough for us -- case closed."

The problem with this strategy, of course, is that Microsoft or whichever other vendor's solution is under consideration may well have been boosted from some other application -- which in turn, may also have been boosted from some earlier application and so on. Bad ideas can persist in this way for years and the more they're copied, the more entrenched they become. If you're building software in a competitive market, you're not in the business of doing whatever everybody else does, you're in the business of getting to the exact right idea and enbracing it fully. When Firefox started eating Microsoft's lunch in the browser market, Microsoft's next version of IE featured tabbed browsing just like Firefox's. Do you want to be the copier or do you want to be the one being copied? As of this writing, Firefox has seized 24% of a browser market once dominated relentlessly by Microsoft. And this diversity has opened the door in the minds of users everywhere to the idea that some other player may be building a better mousetrap after all. As of this writing, Microsoft's browser marketshare is down to 59% and Google's Chrome and Apple's Safari are gaining ground every day.

So if you can't just do what the other guy is doing all the time, what CAN you do to assure the relevance and ultimately, the success of your software?

You have got to focus on what makes life easier for your users. To do this, you must understand their goals. For B2B, your user's goals all fall into one single category -- getting their job done effectively and moving on. They don't want to be impressed, they don't want to read your help files and they definitely don't want to call your help desk.

The single most important factor in determing the efficacy of any user interface, according to Human Factors International is SELF EVIDENCE. Which means the user's workflow has been anticipated by the application's designer, which means that whomever designed it considered the user and that user's goals.

This simple act of stepping outside ourselves and really looking at our product from the user's point of view is the first step toward delivering something they will want and use. Not taking this step in earnest is the best way to deliver a product that garners complaints and costs you references.

In an attempt to drive this fact home for a previous employer, I played the following scene from the 1981 film 'The Right Stuff' to a room full of stakeholders. I analogized the product to the space capsule and the users to the Mercury astronauts. The goal was to make sure no one could analogize our team to the NASA engineers as depicted.

"We want a window." A more poignant analogy for user frustration with a product that has failed to anticipate their needs does not exist. 

The press milling outside I analogized to the product's reputation.

So to all of those stake-holders in corner offices everywhere, and to those among them who think functionality is enough and reputation doesn't count, remember: "No bucks, no Buck Rogers."

Understanding your user's goals, in the end, is the only way to show YOU have the right stuff.

When Tuftean ideas get misinterpreted, "less is more" can run amok

Edward Tufte is clearly one of the most important thinkers in recent history on the matter of representing data visually. Letting data speak for itself means getting to its essence and dispensing with fluff that not only doesn't ADD to the informative value of graphs, charts, or diagrams, but actually SUBTRACTS from it -- leading the eye away from essential meaning.

Dispensing with fluff and getting to the heart of the data aren't always the same thing, however.

Tufte's ideas can often get abbreviated down to a "less is more" strategy. I know because I've made that mistake myself in my own designs on occasion. You think you're letting the data speak for itself and you get the feeling that if Dr. Tufte himself were standing next to you in that conference room as you all stared in amazement at the Powerpoint slide on the scrim in front of you, he'd slap you on the back, give you a hearty "well done, m'boy" and invite you out to the university as a guest lecturer. But your audience is scratching their head instead. Suddenly Tufte isn't the one standing next to you,  it's your third grade teacher and she's got the red marker out.

Why?

Well, sometimes when you're showing super-cool, cutting-edge Tuftean design to a room full of Microsoft devotees, anything that isn't blue with a fade and sorted into a box is going to be met with criticism.

But sometimes it's because less is often NOT more -- sometimes it's just LESS.

Tufte's ideas have helped me produce far more eureka moments for my designs and made them better received than any other single influence. But sometimes you really have to watch where that line is -- the line past which you've reduced away too much and let your interface design veer cold and ungenerous, if not downright alien.

When you have let your design drift in that direction, it's admittedly of some comfort when you realize other experts can make the same mistake.

Especially when it's the guy who designed the interface of the Edward Tufte Web-site!

Now THAT page was designed by someone who took Tufte's ideas too far into a less-is-more realm. The whole top half of that page looks like a site that lost its stylesheet.

Sometimes MORE is more and sometimes data can't speak for itself. As a UI designer it's up to you to give that data a voice and find that perfect middle ground.

Required reading for anyone designing software for humans

Discovered an extremely well-versed and well-spoken UX designer online yesterday working out of New York by the name of Whitney Hess.

There's an ad for some brand of cereal on TV lately in which a customer inquires of the store manager as to the product's quality. The gag is he's so used to fielding the same questions about the product that he anticipates every one of her questions before she has a chance to finish her sentences -- to her amazement.

 Upon encountering Whitney's observations, I felt a little like the amazed customer in this ad. I'm thinking it and she's saying it -- and way better than I ever could have.

Her Blog, 'Pleasure and Pain' has posted to it a presentation entitled 'The 10 Most Common Misconceptions About User Experience Design' that should be required reading for anyone endeavoring to create software for human beings.

I might have changed the title to something like 'The Top 10 Reasons Your Clients Aren't Giving You References,' but I suppose that veers obtuse.

Bravo again, Ms. Hess.

Design minus font and minus color equals significant time-savings

Just put the finishing touches on what may have been the fastest turnaround time I've yet achieved on a freelance mini-site job. About 13 hours fom rough sketch to finished Web-site. That's gotta be a record. As usual, the client needed it yesterday and cost was a priority. Here's the site:

  

So how to produce a site your client can be proud of without racking up the billable hours? Two decisions I made early in the process proved to have been very much worth making:

1. "I'm not going to worry about color."
2. "I'm not going to worry about font."

Everything in this mini-site is either black, white or red. And with the exception of the skinny text (Arial Narrow) used in the bottom two lines (and of course, the logo), the only font used for any line of text is Arial.

You never realize how much time a couple of steps in the design process can cost you till you cross them off from the get-go, apparently. Because doing so saved time huge.

I also spared myself the task of going through and consolidating the styles I added to every page into one master CSS they could all link to, but I think at best that would have been an hour, anyway.

The site itself is a verboten frameset sculpture, but how else are you going to get your video to play on every "page" when you know your client has no interest in the added time and expense of hiring an AJAX programmer? Don't even think about iframes -- they don't persist across multiple pages. Which means you can link different pages together each with an iframe displaying a separate fourth page that carries an embedded video file, and when you link to any of the three from any of the three, the video file will start over from the beginning when you click through.

Not so with framesets.

Put the SEO in the top frameset and Google's bots will sort it out. Was considering putting no index no follow code in the head of every other file, but SEO isn't a crucial issue with this site anyway.

And let's face it, it's fun playing with framesets again.

Lets you party like it's 1999 ...

Starting with WHY

Very provocative 18-minute clip from Simon Sinek, author of 'Start With Why.'

More evidence that what may seem like an obvious question to many UX and UI professionals isn't always where many of our clients and employers are starting out. It often falls on us to help them think clearly.

Most of Sinek's speech here hits the mark and fits in nicely with the first question I always ask of any UI design job: "What is this app supposed to do?" 

Simon Sinek: How great leaders inspire action | Video on TED.com

In praise of iRise

Glimpsed an interesting comparison breakdown of app "simulators" on the Boxes and Arrows site this evening. These are the products people use todefine and map out apps before they get built instead of AS they get built and when Visio just ain't makin' it.

Axure RP4, LucidSpec, iRise, Composer, Enterprise Simulator and Profesy all square off on a list of 12 valuable features:

1. Scenario Design
2. Page Design
3. Widget Library
4. Dynamic Display
5. Data Interaction
6. Decision Logic
7. Annotations
8. Centralized Server
9. Portable Distribution
10. Requirements Management
11. Enterprise Support
12. Export to MS Word

iRise was the hands down winner with solutions for all 12.

NICE.

"Design is how it works." Learn it. Know it. Live it.

I could probably count on one hand the number of sentient human beings whose quotes are worthy of a change in the business-plan of any for-profit enterprise.

Leave it to Steve Jobs:

“Most people make the mistake of thinking design is what it looks like. People think it’s this veneer – that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.”

Dovetails nicely with one of my other favorite quotes of all time. Judge Reinhold's soliloquy at the very end of this clip:

First steps

What my Grandfather said turns out to be true: Those first steps into the blogosphere are always the hardest.