On LinkedIn and similar virtual gatherings of user experience designers I am often struck by questions like, “What is the best wireframing/prototyping tool?” which are typically followed by replies in which the respondents give passionate support for their particular favorite (and there is always a variety of favorites). The questioner is probably left as lost as when they began. There will never be a “best wireframing/prototyping tool” any more than there will ever be a best kitchen tool. It depends on what you are cooking!
The terms Wireframe, Prototype and even Mock-up are somewhat overlapping concepts, and used rather interchangeably in the literature. This is how I use these terms:
- Mock-up: I use this as a general term which includes both Wireframes and Prototypes.
- Wireframe generally refers to a mock-up that intentionally has an unfinished look (to help focus reviewers on interaction and functionality). Just the outlines are shown, with no color or shading, and they often have a hand-drawn appearance. Wireframes typically support at most simple click-navigation between mock-up pages (clicking on images of buttons, menus, URLs etc.), and little else. Wireframes are used for concept exploration, communication, and testing where the capabilities and the basic interaction methods are the focus of the conversation. Because they are quick to produce they are ideal for use during the early phases of a project when there are few screens and lots of churn. As projects grow, wireframes become harder to manage because of the number of screen renderings involved. Balsamiq is perhaps the best known tool in this category.
- Prototype generally refers to a mock-up that supports more complex interaction and conditional logic, such as where the result of a particular user action depends on previous behaviour of the user or the state of the system. Prototypes usually appear more finished than wireframes. They are best for testing complex interaction where realistic behaviour (and responsiveness) is required in order to get meaningful results. Even the fastest of ‘Rapid Prototyping’ is slow as compared to wireframing, so they are best reserved for later in a project, and for testing the more critical usability elements. Axure and Justinmind are well-known examples in this category
The route to a decision about a tool (or tools) to use, like so many decisions, must inevitably include all the usual “W” questions – in particular, “What is my objective in using such a tool on this particular occasion?” Space does not permit me to address many of these questions, but I list 6 key concepts and considerations that help to differentiate between the available tools.
1. Consider Time as well as Cost
It is hard enough to get permission to “take time out” to create prototypes (despite evidence from e.g. Bias and Mayhew in Cost Justifying Usability that prototyping and testing saves development time), so time and cost need to be factored into your decision making. From an up-front cost point of view, paper and pencil win the day, and should always be your first choice. However, it is harder to maintain, distribute, and test with paper and pencil prototypes.
Next in terms of price is PowerPoint! You can create very credible click-through prototypes using PowerPoint. Add a bit of VBA coding and they can be completely interactive! The supply of interactive widgets (e.g. buttons, drop-down controls, etc.) is rather limited, however.
Finally, at the other end of the cost continuum we have tools like iRise and Axure – with up-front costs in the hundreds of dollars. These very powerful tools can be used to create almost everything from simple wireframes, to realistic and responsive applications – but none of them at this time can do everything you can do with real code – see “Interaction Complexity”, below.
You also need to consider how long it will take you to become proficient in using the tool (weeks, in the case of some of the ‘power’ tools), and how rapidly you can turn out screens at the level of fidelity you require. Most tools provide a broad variety of widgets you can drag and drop to quickly layout simple screens (but take the time to learn and use the templating features if the prototype is going to evolve, otherwise you end up re-drawing each screen every time a small global design change is made). Building in logic, on the other hand, requires a relatively big time investment, both in the learning phase and in the production phase.
2. Consider Visual Fidelity
Who would not want a visually stunning prototype that accurately represents the designer’s intent? Well, early in the design process high visual fidelity gets in the way. It takes longer to produce high fidelity mock-ups, and test participants get hung up on the smallest “errors” of color or alignment – taking away from important questions like “Can you use this?” and “Does this meet your needs?” Later in the design process, and for some types of audiences visual fidelity may be important – but don’t waste time on it, if it is not needed.
Tools like Balsamiq are optimized for low visual fidelity, whereas many of the higher-end tools (like Axure and ForeUI) can be used for both low and high fidelity. Watch out, however. With tools like Balsamiq and ForeUI, the designer can toggle between a hand-drawn rendering and a more professional rendering of the same project, according to the needs of the moment. With some of the other tools, however, you build the mock-up with one or the other style from the outset, and changing the look later is not possible.
3. Consider the Widgets supplied with the tool
All wireframing and prototyping tools give you a broad range of widgets (buttons; text fields; lists; tables; trees etc.) to work with. These can often (but not always) be styled according to the target operating system, etc. So in Axure and Justinmind, for example, you can import widget sets that look like all of the Apple, Android and Windows products. You can even import Facebook and Bootstrap widgets.
Beware, however, as there may be some missing widgets that are important to you. For simple, click-through mock-ups, the lack of a particular widget is seldom a problem as you can simply substitute an image of the desired widget, and wire the image to do your bidding. However, if you need the widget to work in more complex ways, you may face challenges. In a recent project I needed a checkbox tree in my prototype. It needed to ‘work’, so tools like Balsamiq were out of the question. Checkbox trees are a common enough feature in the world of web applications – but there is no such widget in Axure or Justinmind. With effort, I was able to build one in ForUI, but even it did not support the tri-state checkbox behaviour illustrated below. In short, verify that all of the widgets and behaviours you need are supported before investing in a tool.
4. Consider the Interaction Complexity required
Here’s the kicker. This is what is usually least clear in reading about the various tools.
Pretty much all mock-up tools support simple hyperlinking between pages. But what about clicking on a drop-down list? Or randomly opening and closing branches of a menu or tree? With low-end tools like Balsamiq you can try to fake it by creating a new page showing the result of each and every click, whereas in higher end tools these widgets “work”. Faking it for a dozen or so clicks is OK, but it rapidly becomes unmanageable after that – forcing you to (a) artificially limit the range of options presented to the user, or (b) have unresponsive “dead ends” in your prototype – all of which impact natural interaction. If you need to support behaviours other than hyperlinking then you need the power that the higher end tools provide.
What if your application requires more than simple clicking? What if you need to respond to right-mouse clicks? Or hover? Or Swipe? Or Drag-and-drop? In Balsamiq, the easiest tool to use, buttons only respond to one ‘event’: a click. In Axure buttons can be programmed to respond to 4 events: OnClick; OnMove; OnShow; OnHide. Gestures like Hover and RightMouse are handled in a different and less powerful way. In Justinmind, on the other hand, buttons can respond to a whopping 33 events, including MouseOver, RightMouse, and Swipe.
The bottom line is: as you begin your journey, think about the most complex gestures and behaviours you need to support in your testing context – and then check if the tools you are considering support them.
5. Consider the Need to Support Responsive Design
In the multi-device world, we often need to test responsive designs on multiple device formats. Here the various tools differ widely.
Most tools provide templates which define the size of the screen, and the look of the widgets for each of the devices – but you still have to actually build a separate set of screens for each device or screen size that you want to test.
Tools such as Justinmind can be programmed to switch between versions of your prototype as the screen changes size, but only one tool that I am aware of (Antetype) is fully layout aware – automatically rearranging the screen contents according to the size and shape of the space available.
6. Consider the Test Environment
On what devices do you intend to show or test your mock-up? Some mock-ups are more easily and effectively presented on small devices. Most tools require you to decide on the target device characteristics before beginning, but others (like Antetype) can be set up to adapt to device size and orientation on the fly. Verify that the tools you have in mind can produce satisfying results on your target devices.
In summary, think through all your objectives and needs in the above categories before committing. If you can, choose a small project that you can complete in a month, and use the free trial of your selected tool. In the end you may conclude that you need more than one tool (I certainly do!) – but don’t forget, you already have and know how to use paper-and-pencil!
Once you have a good idea of the characteristics you need in your mock-up tool, a list like this from Cooper will get you to the next step.