id8 Blog

Put the Rider in the Wind Tunnel

It's nearly summer in Chicago, so I've got bicycling on the brain. I was recently out visiting bike shops, trying to figure out which triathlon bicycle I should buy. I asked the bike shop owner the difference in aerodynamics, comfort and speed between two particular bicycles. He told me that one tested especially well in the wind tunnel testing for aerodynamics, but he also mentioned that he didn't put too much weight in wind tunnel data.

"Why not?" I asked.

He explained that in wind tunnels they don't often use people on the bikes, but dummies meant to mimic a human rider. He said it's difficult to get professional riders to spend the kind of time they need to in a wind tunnel. Of course, I thought, I would totally want to volunteer for such a thing! I'm a rider who wants to know how those data translate to amateur racing. These bike companies do a LOT of prototyping right on the spot, with different molds for pieces of the bike ready to be made to test different structures.

The problem is not using actual riders who aren't either dummies or paid professionals.

We face the same problem in using rapid prototyping for applications. We spend a lot of time in business analysis, making decisions with a business owner or UI expert. And we can create some pretty cool and complete visualizations. But formal usability testing with actual end users is almost universally a "nice to have," rather than a centerpiece of design and production. We end up with a lot of applications that should be great on paper, but often face many change requests from actual users.

I've mentioned in past blog entries that we need to use more specific data--and this posting is a continuation of that theme. But I'm feeling more emphatic than ever about specifically usability testing. Like with the bicycles, our rapid prototyping loses so much of its value when it's not tested sufficiently by its most common "riders."

The more I think about it, the more it seems crazy to ever NOT do it. And those of us who do visualization should be at the forefront of that push. Why use the wind tunnel without the end rider? Why use iRise without the end user on the prototype? Visualization provides an opporunty we didn't have before--to test usability before the application is even built. Let's push hard to take advantage of that.

Marathon UI

We tend to think of user interfaces as proximate machine interfaces where one user at a time (or sometimes more than one) creates inputs that create a given range of outputs, usually through voice or touch.  But arguably, ANYthing with which we interact to produce an expected output could be considered an interface.

As Michael mentioned, I recently ran the Boston Marathon. And I run a lot of races in a given year. So I’ve been struck recently with the ways race registration and races themselves seem to have become more and more informed by principles of usability and user interface design. If we think of UIs as inputs and expected outputs in a given fairly confined system, our definition can be fairly broad.

In most races, you register online from the race website, and then sometime before the race, there is a “packet pickup,” where you receive your bib, timing chip, race t-shirt, etc. Especially in the higher-end races, these races have become highly complex systems with very visual interfaces and unique branding to promote effective human-system interaction, as well as brand equity.

Much like the transition from early websites with text only (what a colleague of mine calls "developer UI syndrome"--apologies to developers) to Web 2.0, races have evolved from posters with handwritten notices that say “A-L Here” to sophisticated three-dimensional user spaces that are now big co-branded businesses.

I'll use the Boston Marathon as an example. It has a great deal in common with a great online user experience—more so than mere signage in a business, or even signs on an interstate. In this case, the user is making specific inputs and getting specific individual outputs form the “system.” It also has over 25,000 registered “users.”

When you register, you go their well-designed website. The brand, and your user identity, are established:

After registration, you get a similarly branded brochure in the mail (AND in email). It’s really similar to a confirmation email:

You use that card to go to the race “expo” to get your packet "output":

And your race bag—the only bag you’re allowed to check at gear checked—also designed around your system identity—as a user you know exactly where to drop off and pick up your belongings—bus windows with your user identities categorized:

Even the finish line in consistent:

After you finish, you’re guided through a series of interfaces to get food, timing chip removal, and finisher medals:

And your results, the final system outputs, are sent in exactly the same fashion:

(yeah, those are my results)

There’s more--signage along the course itself, co-branded clothing and other gear, etc. This kind of consistency and ease, especially in three-dimensional space, is something I can learn from. It also helps me learn more and more about related but separate systems and usability across applications.