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.

It's over.

Busted. They figured it. The registration numbers must be way in the hundreds. The real Doug is back. It was nice while it lasted, but I knew it could never last. Ohh well, it's back to writing post with actual relevance.

AFTER:
 

BEFORE:

Scott in the Boston Marathon

Scott Nelson, id8's Director of Application Definition, will be running the Boston Marathon on Monday.

We wish him the best. Good Luck Scott!
Off the record Scott tells us that he's looking to complete the Marathon in 3 hours 15 minutes.

Marketing Mistake or Marketing Genius?

Shameful publicity -- I'm not Doug! Clearly they realize the short hair look ups the register attendance.

A day in the life -- as requested.

Recently I've had a couple of friends ask me what a typical day looks like for me. So today I decided to try and document it.

I thought today would be a good day to do so as it takes me from Portland OR, into Boston MA.

Here goes.

Wake up as late as possible (5:45am) park my car at the airport and start sprinting to the terminal.... while it rains.
 

Next up... make it through security (I'm getting very good at that) and hope that my gate is somewhat close.

Then I realize that I actually have more time than I though, and what better way to use that time than to buy an overpriced badly constructed breakfast sandwich with excess packaging. Yumm.

Board the plan.
 

Walk right past First Class, wish I had better status, and check out what's on their menu.

But then get the gift of a flight with not a lot of people on it and get the whole row to myself. Nice.

Now the fun stuff, start working on methodology ideas and concepts. I like to do that on paper first and the flight is 5 hours so plenty of time to do so.

Land in Boston nice and safely and on time.

Get a cab, a very nice guy, he estimated it would cost $59 to get me to the hotel and he was bang on... that's a first. I like Boston.
 

Get to the hotel and check out the room. I like the sweet dreams pillow, I hope that will be the case.

Now, what better way to review and discuss ideas than over a local beer in a local brew pub with a very cool guy.

OK, the day is getting close to being over. But wait I realize I need additional pictures to make this post. So quick, out comes the camera and let's try to get some final shots in.

And then to my luck... what do I see... a free Tibet protest. Open the car window and get a shot. Perfect.

OK, final thing here. Get to the hotel and take them up on the Sweet Dreams offer.

There it is, a bit off the regular theme, but none the less a day in the life documented.

In action it looks like this...

We post about new simulation videos and various iRise techniques, but how exactly would you convey this to a group of users?

Scott's recent video received a lot of great feedback about how creative it was to visualize the bar codes on the clipboard.

Here is Scott in action running through a similar visualization with the business stakeholders, the IT folks, and the actual users of the hand held scanner.

I was in that session, it was from 10am - 2pm. It was great fun, highly interactive, and we were able to cover a lot of requirements--close to 100 if I remember correctly.

In a prior life I have also been in sessions where we would try to cover requirements in word documents printed out in front of us... a grueling session to say the least, and I'm sure many of you have been there.

Working from the visualization and using that as the focus, and even making changes in the room where appropriate, are by far the most productive JAD sessions.

Come on... I mean... look at the concentration on his face!

More importantly notice the computer next to me... It's been in sleep mode for a while... no web surfing in these sessions.

I have some other examples about what happens behind the scenes, but that is for a later day and a different post.

I Love Data

A while back I blogged about expanding our definition “user-centered design.” But I want to return to this issue in light of the most recent public debate on usability—the new Facebook UI.

I’m not going to list the “mistakes” they made in this interface or praise its design, either. There are plenty of folks doing just that in blogs all over (see http://www.burningthebacon.com/2009/03/16/new-facebook-interface-fails-usability-test/ about its usability feature changes, and http://www.forrester.com/Research/Document/Excerpt/0,7211,47046,00.html about Forrester research regarding the Facebook UI)—and I’m fairly ambivalent about it, because for the most part, I know it will change soon again anyway. One thing I will praise social networking sites like Facebook for, though, is that even though they recognize that people get USED to interfaces and get annoyed when you change them, that you have to keep changing them.

As annoyed as people initially are, new users are MORE annoyed when you keep an old UI that eventually becomes outdated or obsolete.  Take the example of large-scale enterprise software, like SAP, or PeopleSoft. When initially designed, they were revolutionary, and still are for their sheer power. But they continue to face a problem where old users have taken years to get used to the interface and DON’T want it to change, while new user find if cumbersome and poorly designed by today’s standards. Facebook, for example, keeps its UI iterative on a short timescale, and for that I praise them.

What I really do think is needed in usability studies is simply MORE DATA. One of the most popular blogs for the 2008 U.S. elections is fivethirtyeight.com (check it out—it is a lesson in analysis). It is wildly popular, because these guys KNOW DATA and use it well and in an accurate, predictive, or explanatory way. They’re statisticians, and they know social science. I argue that we need such a quantitative revolution in usability (and UI designers can help them some, too—you’d know that if you’ve used statistical software like SASS, SPSS, or STATA). Let’s regress!

In usability, we do a great job of filming users, asking questions, and applying more universal cognitive principles, but we don’t do such a hot job of using significant or representative samples, or using standard methodologies in survey design.  I’m hoping for even more improvement in the science of how applications are used and by whom.

One interesting example is the use of social network analysis—the mapping of individuals’ social networks—such a methodology could be very useful in understanding how user are interrelated. Here is one researcher’s visualization of his Facebook social networks (see http://www.connectedaction.net/2009/03/02/facebook-social-network-visualizations/):

Every single user will have a different social network, and there will be commonalities across populations or groups. But understanding that not all users maintain the same networks, or even use software in the same way--even for the same purpose, is crucial to developing adaptable, evolving applications that use all the quantitative tools at our disposal.

Scott's New Video

Scott Nelson, id8's Director of Application Definition, has posted a new simulation video: Handheld Scanner with Barcodes.

It's a very cool video and demonstrates how you can use practically simulate anything with user interface.
You should also check out his blog post about this subject. 

The video has also been posted on the iRise website. 

Simulate Anything...

One of the things I love about rapid prototyping through visualization is that there are few, if any, limits. I remember a scene in Apollo 13, when they know they have to fix a potentially deadly problem, and back on Earth, the scientists get a duplicate of all the available materials on the ship in order to devise a solution with just those materials. I see simulation with iRise the same way—creative solutions with a finite set of widgets.  And when we’re able to do something, it helps expand what others, including iRise, are able to help us accomplish. If we can simulate it—it most definitely can be built.

Soon, id8 will post a video of a handheld scanner system simulated using iRise. I determined that we needed to think outside the monitor as much as possible, even when we have to use the monitor to run a simulation. We can create multiple spaces and push the prototyping methodology way outside to web-based applications. Using the scanner interface as well as a barcode interface to the side, we can easily dynamically generate a system that visualizes BOTH interfaces at the same time.

So, given the success I had with handheld visualization, I decided to undertake an experiment. I went out and took pictures of interfaces—any interface at all—to see if I can somehow simulate it using iRise. Take a look:

The first thing I randomly ran across was my thermostat:

So it basically has a few different functions like “Program,” “Hold,” and “Time,” with a couple for different modes (“Heat, “Cool,” and “Auto”), plus an up and down button. So sure, I could pretty easily simulate this, with the digital display.  And it might actually be an effective method for testing such an interface before being built!

So next, I had to go do something in my car:

 

This one is a whole bunch trickier. I COULD simulate the interface for heat, radio, and air, but it likely wouldn’t get me much.—same with the speedometer, etc. In order for this visualization to be useful, we’d probably need to have pedals, transmission, etc. So while simulation might help a tiny amount, it’s probably NOT the best approach to cars (feel free to prove me wrong!). But I was NOT discouraged! I went to the kitchen to find something to eat, and I saw:

The microwave!

So YES, it immediately became apparent the usability of this interface could most DEFINIETLY be tested and designed with the help of visualization. Is it intuitive to press certain combos? What would we expect the display to say at certain points in a process? Are there too many clicks? So I should get a meeting with Frigidaire. .

So all this is getting me excited about possibilities—I should probably check my blood pressure:

I could fairly easily simulate the use of this automatic blood pressure monitor. Would it get me anything if was designing such an interface? You bet it would! I watched an older relative use a similar device and saw how thoroughly confused she was by how to use this device. Had I simulated this ahead of time, I might have solved some of those issues.

So I guess the point is—do what it takes to make your interface or system work the best—get as much visualized as you can—and it will help create the best tested, bought-into systems out there.

Next time you see an interface, of any kind, say “Can I simulate that?” And I’ll be the answer is that you can.