Paul Stovell says…

Darren has a good post about why mockups are valuable, from his own view as a customer. For budding mockup creators, Mitch has written up a walkthrough of how he creates them using ArtRage.

To me, the primary purpose of mockups is to help close the feedback loop. Customers will always offer feedback on UI. The earlier the customer can see the design, the earlier they’ll be able to offer feedback. The earlier they can offer their feedback, the easier and cheaper it will be to revise your designs, or reach a compromise.

An analogy I used today was that mockups are like the scale model diagrams they create for large building developments. As a builder, imagine spending three years building a skyscraper. Then, on opening day, imagine the customer remarking that they wanted the building to face in the opposite direction!

The situation is worse for software, since we so often build in complete darkness. Usually, the customer can’t "drive by" the software each week and notice obvious things. The first time they see the design is often the day after the functionality is fully implemented. This is another reason for iterative development, parallel UAT cycles and nightly automated deployments!

Mockups will need to be revised

One common approach people take to mockups is that they should be reusable. Why spend all this time creating mockups, when you’ll just have to throw it away? They then set out to use development tools - Visual Studio, HTML, ASP.NET, Dreamweaver, or others - and spend days perfecting the mockup to create something that can be reused.

After spending so long creating mockups, it is finally presented to the customer. This is where problems can start:

• They may decide to revise it, in which case more time is spent undoing and revising the changes.
• They may decide not to revise it, because they don’t want to lose another day working on it. Instead, they decide to just "go with it", and leave out minor changes. This leads to an inferior product.
• They may decide not to revise it, but instead to make changes during development. This cancels out the reason for doing the mockups in the first place!

I would rather a low-medium quality mockup delivered in an hour versus a high quality mockup that takes a day, since I can revise the one hour mockup 8 times.

Tools like Microsoft PowerPoint and OneNote are good for creating UI mockups quickly. Just grab a screenshot of an existing system to start with (almost no-one starts with a blank canvas), and drag shapes and text and tables over the top until you have something close to what you plan to build. A good suggestion from my current client was to use Excel for report mockups - their tabular nature makes Excel a great choice, and the technique worked very well for us. Of course, the tool you use will depend on the experience of your team and what you’re building; just make it quick!

Napkins versus Scale Models

The type of mockup that Mitch creates is what I hereby call "Napkin Mockups". Of course, they take more thought and care than what you’d scribble on a napkin over lunch, but they have similar characteristics:

• Mitch likes to convey the idea of the UI, not an exact image of what will be built.
• It is more of a conceptual design than an implementation specification.
• It is usually not to scale, uses different colors, and he rarely capitalizes things correctly.
• They are quick to create (once you decide what to create).

Napkin mockups work well to get the team’s creative juices flowing, triage UI approaches, and get a "yes/no" decision as to whether you are heading in the right direction.

For some projects, it is worth taking napkin mockups a step further by creating "Scale Model Mockups". Once a few ideas have been thrown around and napkins scribbled on, you can set out to create something that looks a little more realistic. These may have the following characteristics:

• They are usually to scale - often at the lowest supported resolution to ensure everything "fits" on screen. For something like the home page of a web site, you might create mockups for various resolutions.
• Colours, fonts and imagery are closer to what the real implementation will use.
• You include surrounding features like menus, structure, vertical and horizontal grid alignment, and non-core elements

We found Scale Mockups do a better job of communicating to a team exactly what to build, giving the customer a better sense of what the UI will look like, and force you to consider a few more issues ahead of time.

Whether you need Scale Mockups or just Napkins is up to you. It will depend on the complexity of the UI you’re designing, the needs of your customer, and your time. You may use a mix - one scale "master" mockup with lots of napkins for individual pages, or a single mockup that blends the two. Napkins seem to work well for Mitch, because as soon as they are done, he seems to go straight into creating a working prototype and aims to get it into the customer’s hands ASAP.

I like whiteboards, pencils, and real napkins for napkin mockups, unless I want to make them redistributable, in which case I’d probably use OneNote or ArtRage. As above, I reckon PowerPoint and similar tools works better for scale mockups.

In summary, allow me to present Paul’s golden rule of mockups:

You are not creating a mockup to show the customer what your design is. You’re creating it so they can tell you how to revise your design before you implement it.

If you don’t revise a mockup at least once, they aren’t paying close enough attention

Filed under: Mockups