Jeff Harrison of Evantage on How to Future-Proof Your Prototypes

You pour blood, sweat and tears into a prototype. You spend hours thoughtfully crafting every nuance of the experience. You present it, like a proud parent. Then your boss, or client, requests “just one small change.” No problem, except making that change requires you to rip apart your entire prototype.

What to do?

We talked with Jeff Harrison, a user experience consultant with Evantage Consulting and an Axure Fu Master, about this particular problem. His prescription: an ounce of prevention.

Okay, so this common sense advice doesn’t help when you’ve already built your prototype and are in the throes of reworking it. Next time, however, Jeff has a few recommendations for ways to think about prototyping in a way that anticipates changes, or at least make them easier to pull off without pulling out your hair. For some sage advice, read our edited Q&A with Jeff.

Q: Here’s a serving of irony. You built this crazy puzzle to demonstrate that simplicity is often best. How exactly does it show that?
Jeff: This was actually the second version of the puzzle. I made the first version in 2009 to demonstrate how you can break a huge interaction into manageable parts. That puzzle used a giant control function that kept track of every square. Every time you clicked, it went through a lengthy calculation to figure out where the squares should move.

In this version, the location of the hole is known, the location of the clicked square is captured, and every tile knows where it is. When you click, every tile has to figure out for itself whether it’s between the clicked tile and the hole, and if it is, it moves. That’s it. Since the logic is built into each tile, it makes it easy to expand the puzzle to a 6×6 or 7×7 grid.

The point was cohesion — everything the component does should be logically connected. If you do that, you can avoid making logical spaghetti. I’ve produced a lot of logical spaghetti in my time.

Q: So Rule No. 1 in Jeff’s Laws for Fireproofing Your Interactions is cohesion.
Jeff: I suppose. (He chuckles.) It’s a matter of building interactions that can withstand stress.

Q: I still have a head-pretzel from looking at how you built this puzzle. Are all your prototypes this insane?
Jeff: The puzzle was just for a little shock and awe. Most of my prototypes are very pedestrian and boring, actually. Many of them look plain and do only one simple thing. I’m a firm believer that if you have three different kinds of questions to answer, you should consider three simple prototypes. Unless those questions are inextricably linked, trying to come up with a single prototype that has everything in it isn’t going to help you answer those questions.

Q: So, Rule No. 2 is make one prototype per question for user testing.
Jeff: Right. When I think about a prototype, I see two reasons why you would make one. One, it can communicate a design better than words. Two, it helps you answer some kind of question.

Q: In your experience, what types of prototypes work best in user testing?
Jeff: With user testing, you need simple prototypes that are focused on the test. Otherwise, people can get distracted and give you feedback about the wrong thing.

Q: Give us an example.
Jeff: High-fidelity prototypes. A lot of people want their prototypes to reflect every nuance and every pixel of the product. But high-fidelity takes more work and time. If things change, it also takes more time to maintain. You also risk eliciting reactions that aren’t useful. A classic example is when testing how people flow through your product. With high-fidelity prototypes, people can spend all their time talking about the color, the presentation or the breadth of functionality — anything but the flow.

Q: Okay, lay down another law for us.
Jeff: Sure. The more simply you can model something, the easier it will be for you to modify it. For example, avoid nesting one dynamic panel inside of another one — if you can. Nesting dynamic panels makes your interactions more complicated, and changing one variable value can involve digging through multiple panels. Build interactions that make it easy for you, the prototyper, to change things down the road.

Q: Now we have Rule No. 3: Avoid nesting dynamic panels. How about a fourth?
Jeff: Uncouple your interactions from your pages. Instead of using OnPageLoad to configure everything on your page, embed the logic into your components so they can configure themselves. Make self-contained masters. That way, if you cut and paste widgets, you won’t break your interactions. This is a concept borrowed from object-oriented programming, but it’s generalizable.

Q: But object oriented UX advocates for a lot of nesting of masters within masters to create those self-contained objects. Doesn’t that violate Rule No. 3?
Jeff: Sometimes, you will find yourself in situations where nesting is best option. I know saying this does jeopardize my status as a lawgiver, doesn’t it? Maybe Rule No. 5 is that there will always be exceptions.