I’ve been working with Axure for seven years now, and I’ve learned a thing or two about working with it efficiently. What follows are 10 rules that will help you build your Axure prototypes efficiently too.

Rule #1: De

sign Outside of Axure

Axure is fantastic with its ability to make it easy for designers to make small to moderate changes throughout an entire prototype. However, it’s an absolute disaster if you have to make large shifts in your design direction (although I suspect this to be common to all interactive prototyping methods). Rework city! But if you do your high-level design outside of Axure, validate design direction with sketches or other lo-fi design artifacts, and then start prototyping, well then you’ve just bought yourself an insurance policy against rework hell.

Rule #2: Plan Before You Prototype

Of course, there’s just one more step you should take before you get your, uh, screen all dirty with dynamic panels & conditional logic. You’ve gotta plan out things like:

• What’s going to be a master?
• Which components need to be dynamic panels?
• Do I have all the annotation fields the developers need?
• What are the usability test tasks going to be? (You are testing your big fancy prototype, aren’t you?)
• What content and functionality does the prototype need to support those tasks?

Once you’ve got your pile of sketches and the answers to these questions, you’re ready to prototype quickly and efficiently. If you follow this path you’ll pretty much be doing data entry at this point, where the data you’re entering is the design and interactions. Of course, your design

will evolve as you interact with it in the course of building it, but that’s a good thing.

Rule #3: When in Doubt, Right Click

Okay, so now you’re prototyping away and there’s some feature you know is in there but you just can’t find it. What’s the answer? Probably a right click. Trying to make a group of radio buttons work together? Right click on them. You need a triangle? Right click on a rectangle (what do you mean that’s not obvious?). You have a graph paper fetish? Right click on empty space (not even kidding!) to make the grid dots into lines. Want vertical scrollbars on your dynamic panel? Right click. And so on and so on and so on.

Rule #3a: My friend Amy Silvers pointed out that Rule 3 has a corollary… If you can’t find it with

a right-click, you’ll probably find it in the “Wireframe” menu. (Or as I like to call it, the “If it’s useful it’s probably here” menu.) Thanks Amy!

Rule #4: Convert to Master, Not Copy & Paste

Copying & pasting doubles your work (at least) if anything changes (more like “when”). If you have the same (or even just similar) content or functionality that needs to show up in multiple places, use a master so you can manage that content or functionality from a single place. Here are a few tips:

• Instead of copying & pasting, right click your selection and select Convert > Convert to Master
• Do interactions on the component you need to duplicate manipulate other objects? You can still convert the component to a master and use Raised Events to preserve that behavior.
• Do some things about the component stay the same while others change? Consider using a custom widget master with a regular master made out of the things that won’t change.
• Does the component need to look a little different on each page? Masters have OnPageLoad interactions that fire after the OnPageLoad interactions on the pages they’re associated with. Use this property to configure instances dynamically.

Rule #5: Show an Example, Document the Details

The great thing about interactive prototyping is that you can show people how an interaction is supposed to work. But you only need to show them once. Unless it’s necessary for a proof-of-concept or a usability test, I try to prototype an interaction once and simply document its use elsewhere. Error messages are a great example of this. You don’t need to prototype every single error message! Just prototype one so you can get input from stakeholders, feedback from users, and so you can communicate effectively with developers. Include the error conditions and the messages that result in the annotations and/or page notes.

Rule #6: Don’t Dawdle With the Documentation

Yes, I know you’re busy getting the prototype working for the imminent test, but if you leave the documentation for later, you’ll be sorry. Trust me. I did that. Twice on concurrent projects. To regain my sanity afterwards I took a week off and drove around Lake Superior. By myself.

The one complication with this rule is highly iterative design. For example, if you’re working at a pace where you’re going through one iteration of design, testing, & revision each week, what you document one day could easily be removed the next. In this case, documenting after design is complete is actually more efficient, even if it does feel like a slog.

Rule # 7: Panel Chains Prevent Panel Pains

Out of all the new features Axure has gained since I first started using it, the OnMove interaction might have had the biggest impact (well, that and the native Mac version). OnMove allows designers to create extremely flexible pages. You can link panels together with OnShow (move panel below down), OnHide (move panel below up), and OnMove (move panel below when this one moves) interactions so that when something happens to one section the rest react appropriately. This technique makes it very easy to manage a page with multiple dynamic sections. Need a new section? No problem, just tweak one interaction. Need to get rid of a section, again, no problem. It’s just swapping links into and out of the chain. Explaining panel chaining, though, doesn’t really lend itself to words. It’s best to see it in action. To that end, I give you an example.

Rule #8: One Widget, Many Styles

In addition to dynamic panels, Axure also allows designers to assign different formatting to different states of a single widget. If that’s all you’re doing, right click on any button shape widget or image and edit the rollover, selected, disabled, or mousedown styles. If your dynamic thing is any more complicated than a single widget, though, then you need a dynamic panel.

Rule #9: Fewer Variables, Fewer Problems

In addition to making your prototype more palatable to IE, using methods other than variables to control interactivity actually decreases complexity and increases your ability to see what the heck is going on. One of my favorite tricks is to use a checkbox to keep track of whether something is selected. You can’t build a condition off of whether an object is selected, so many people would think that they’d need to store the state in a variable. Nope. Just put a checkbox outside the border of a panel state or at a negative value on the screen so it’s hidden from view and it will act like a Boolean variable (check state is either true or false). If something’s not working right, it’s super easy to move the checkbox such that it’s visible so you can see if it’s actually getting triggered.

Rule #10: Nuke It From Orbit

Sometimes, an Axure prototype can act just plain weird. If something’s not working and you’ve picked through your prototype without finding anything wrong, sometimes the only way to fix it is to nuke it from orbit. If you delete the folder that you generate the HTML prototype to and then generate fresh, that will often fix any unintended strangeness in your prototype. If it doesn’t fix the problem, well, then you really did do something wrong. I often find that simply talking through the interaction with another Axure user often reveals a flaw that had previously concealed itself from me.

I hope these rules are useful for you and that they help you work more efficiently with Axure. But you know what? I would love to hear about any rules you’ve come up with in your own work. Write them in the comments!

Tags: Axure, Prototyping