Wrong Tool

Choosing the Right Mockup Tool

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

Over the years, I have used many of the packages available, and what I have found is that two general capabilities make or break the effectiveness of any mockup tool:

  • The speed with which you can crank out results.
  • Ease of use.

Raw speed is a prerequisite to using mockups effectively, as mockups are strongest when used in short iterations. They allow you to test your ideas and quickly discard what doesn’t work. Often, you do this together with your customer, so the process must be smooth.

  Raw speed is a prerequisite to using mockups effectively, as mockups are strongest when used in short iterations.

The ease of use should be the same as making old paper sketches. In real life, you can rarely utilize a tool that requires a three-day course just to begin using it. Also, people that communicate with the customer are often non-programmers, so a complex tool simply won’t do.

No effective mockup tool can be deficient in these two aspects. You want to focus on the work you are doing, rather than on the tool itself.

  You want to focus on the work you are doing, rather than on the tool itself.

Also, you need to be aware of your specific requirements. With the increasing number of available tools comes specialization as well. Since most tools target specific problems, you are much better off when you already know in advance, what you want the tool for:

  • High fidelity or low fidelity?
  • Do you want to prototype right there in live workshops? The tool needs to be fast enough for that.
  • What’s your target platform, i.e. the platform of the system that you are developing? Desktop, web, smartphone, etc.?
  • Will you aim for presenting real-life scenarios? If so, you need to be able to populate each element with real-life data easily.
  • Do you need some basic interaction capability from your mockups? Most tools provide “links”, so you can click on a button, etc., but some tools are almost fully interactive.
  • Will you have a lot of screens? If you are fully simulating real-life scenarios, you could end up with hundreds. At that point, you really need a tool that makes the maintenance easier: structure, templates, masters, custom widgets, etc.
  • Do you need to refine your spec even further? The only viable option for this I’m afraid, is still to export to MS Word.
  • Do you need to present your mockups in live workshops? You need to get your mockups in a slideshow somehow, preferably at the touch of a button.
  • Do you need non-programmers to use the tool? This may include analysts, interns, consultants, or even your customers. In addition, a tool aimed for designers may be very different from a tool aimed for developers.
  • Good annotation facilities are crucial for either live workshops or for creating a specification.
  • Does the tool have a sketchy or black-and-white look and feel? This is the single most important thing early in the project for initial mockups.
  • Do you need the look and feel of a particular system? This may be Mac, Windows 8, Linux, or even a web theme.

  Most tools target specific problems, so you are much better off when you already know what you want the tool for.

The choice is easier if you have a concrete project in mind. Then just test a couple of reputable tools that match the above requirements for that project, and choose one that you feel comfortable with. After all, you will be the one spending time with it.

Even if your next project is completely different, any adequate mockup tool would have already paid for itself many times over. Thus you can easily afford another one, if absolutely necessary. But the chances are, any reputable mockup tool can be used for many different project types.

On the other hand, you might be looking for a one-size-fits-all package. Then you should be more careful, because in the end, every person and every team works in different way.

  Follow the tool that matches your style best, and you will be fine.

Follow the tool that matches your style best, and you will be fine.

Now, there are several questions that I haven’t included in the above list, but they are queries that I hear quite a lot. I haven’t included them above because I consider most of them invalid, for one reason or another, at least in terms of quickly capturing software requirements. Before we discuss the available mockup tools, let’s get those questions out of the way.

Generating Code from Mockups?

Some people wonder why almost none of the available mockup tools create actual code. Their argument is that this additional functionality would help jump-start development even faster.

One part of the answer is that there are dozens of major GUI frameworks. Therefore, such a tool would need to cover most of them, unless very narrowly specialized.

  In the early stages, you want to focus entirely on a clear understanding with your customer.

However, the main reason is usually entirely different. You want to focus entirely on a clear understanding with your customer in the early stages, which is hard enough by itself.

I have seen mockups go bad in countless projects because people are worried about producing “proper HTML” (or whatever), rather than simply focusing on the fundamental functionality that a mockup represents.

Creating Fully-Clickable Prototypes?

Some mockup tools produce fully clickable prototypes. Most don’t, however, and there is a good reason.

You don’t want to spend hours specifying how each element on your screens should behave. Instead, you want to focus on what those elements are and what they are used for. You really don’t need a working prototype to discuss what fields and actions your client expects on a particular screen.

  You want mockups that you can completely rework as fast as possible.

What you do need are mockups that you can create lightning fast while focusing on your customer’s specific problems. You want mockups that you can completely rework in very little time whenever you test a different approach.

Why Not Use a Real GUI Builder?

With time, this particular discussion seems to have been settled on its own, so I’ll just repeat the main points here.

Real GUI builders are:

  • Much slower.
  • Only programmers can use them – try explaining to an analyst how to populate a table in VB.
  • They don’t let you annotate your mockups on the fly.
  • They don’t have skins (e.g. black & white) to create screens that can’t be mistaken for an “almost done” application.

Yes, QT Designer and several others do have skins, but 99% of them don’t.

Specialized mockup tools are usually:

  • Communication-oriented, including slideshows, annotations, etc.
  • They can print or export your mockups, and compile them with your notes into most standard formats, including PDF, HTML, DOC, etc.
  • Better ones have some variant of “masters”, so you can derive dozens of mockups from only a handful of basic application screens.
  • Fast enough that you can prototype real-time in a meeting.

Why Not Simply Use Plain Old Pen and Paper?

You can do that; it definitely works. However, when you get to the point of changing, tweaking, or maintaining these types of mockups, then you may really get stuck.

  If you only need a few quick sketches, then pen and paper are perfectly fine.

Thus, if you only need a few quick sketches, then pen and paper are perfectly fine, but be aware that this approach tends to get messy very fast.

List of Available Tools

It doesn’t seem like too long ago when I first became frustrated with the tools that were available. I was so frustrated, in fact, that I developed my own tool back in 2004.

It’s called MockupScreens, as you might be aware. It has actually become quite popular since it was first released. Its strongest points are that it doesn’t require any learning and it produces results at a lightning-fast speed. People do use it as a general-purpose mockup tool, but it’s best suited for quickly capturing requirements during early project stages.

Axure was always a solid tool for wireframing websites and web applications. It got even better; it can mockup desktop and mobile applications now, but it comes with a hefty price tag. In addition, this might be just my opinion, but it has started to show the symptoms of bloating. However, only time will tell.

Balsamiq came onto the scene and its author quickly became a star. The Internet was literally full of links to Peldi’s great posts about starting his business, which happened to be a mockup tool. He did create a tool that was functional and sexy, could be used both on the desktop and online, and actually did the job it promised. That being said, although it’s a very capable tool, it doesn’t suit everyone’s taste.

There are many other tools as well, almost a hundred at last count. Some limited packages are even free, but most of the free and commercial options are simply no good. The problem is both good and lousy tools look the same when you compare their websites and look at their screenshots. Unfortunately, for obvious reasons, I can’t comment on what tools are worthless in this public space. In addition, because of their sheer number, I rely more and more on other people’s experiences, so it wouldn’t exactly be fair to judge harshly.

The List

Below is the most comprehensive list of mockup and wireframing tools of which I am aware. Free and commercial tools are listed, as well as short informational sections and links:

http://c2.com/cgi/wiki?GuiPrototypingTools

Remember, there is no tool to fit the precise needs of every person, so do your homework, and find the best match for your project or business.


What now:

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

5 comments

  • Jose Coronado

    Great summary of questions. May I suggest a few points that have been critical for me when choosing tools for Requirements and Design–
    – Support collaboration? Multiple designers or analysts working on the same project.
    – Reusable Assets?
    – Shared Repository? For reviewers, analysts, designers and developers (shared repository instead of local repository, only available to the mockup producer.

    I like your short list of available tools. I was not aware of your own tool until I read your book and reviewed your profile.

    I am a big supporter of iRise (www.iRise.com). I have been using it for several years now. It actually supports several of the points you raise in the “Choosing the Right Mockup Tool” and the three points I suggest for adding to your list were particularly critical for me.

  • igor

    Jose,

    Thanks for great suggestions, I’ll definitely address them when updating the article.

    By “Shared Repository”, have you meant code repository (cvs, svn, and similar) or something more specific?

    Btw about iRise: I’ve decided to omit it from the shortlist, because it’s almost exclusively aimed at large companies. Apart from that, it is the major tool for the job, of course.

  • Pranay

    Hi Igor, Hope you are doing good.

    I read this article of your and its very useful.Even i used the trail version of the Mockup screen. Its fabulous, extremley user friendly and fast. I didn’t even had to open a help file once for reference. Everything was so readily available.

  • Annabelle

    Hello Igor – hope all is well.

    Your documentation has been extremely useful – I keep a copy of it at work so I have a quick and easy reference when needed.
    It has been an invaluable tool for me – and it shows in the quality/suitability of my mockups.
    Thank you again for sharing this with everyone!

  • Igor

    Thanks Annabelle, glad it worked well for you. I’m struggling with making time to add examples and rewrite the book into 2nd draft :)

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>