If you’re not careful, it’s easy to get trapped in Endless Revision Hell, or even worse, to end up with an app no one needs or wants.
But proper application of screen prototypes can be the key to avoiding that trap. Don’t worry: it’ll be fun.
There are plenty of common tools you can use for software and GUI prototyping, but most of them lack two things: speed and ease of use with paper sketches. (Which you can’t maintain, so they’re not much of a solution either.)
Mockup Screens will let you move on to the real problem: quickly engineering clear requirements for your software application.
Note that it’s also very capable of solving whole categories of tasks quickly and efficiently. You can use it, as many do, quite differently than will be explained here. Put some time into experimenting with screen prototypes to figure out what works for you.
Anyway, here are five easy steps to get started.
1. Recognize scenarios where you need to build a wireframe for requirements.
Think of what your users want from your application: create scenarios that people might find themselves in while using it. Try to work together with your customer. If it works out, keep close ties to them throughout the project: it’s a very effective way to work. But it’s more likely that you’ll have difficulties. That’s fine, though: no need to aim for perfection while you’re still in the prototype stage. Just involve the customer when it counts the most: when you propose the screen prototypes later.
2. Sketch screen prototypes for important situations.
Select the scenario most important scenario and sketch screens for it. Imagine you’re doing it on paper, and remember: You must focus on speed, instead of the minute details of design. Populate your screens with information that will get a reaction. In the words of Todd Grimm, “[Prototyping] is not a tool to prove that we are right. It is a tool to show us where we are wrong.”
Repeat this for the next few important scenarios, copying screens from existing templates of finished scenarios whenever you can. Then choose two or three you want to discuss with the customer. Don’t pick too many or you’ll get poor feedback.
Before the workshop, skim through the scenarios yourself: they’re your prototype. Add marks and comments where you have questions or want to emphasize something. If you want to make interactive changes and work with the customer on experiments, present your prototypes with the “slideshow” option enabled. (Just remember to save a copy of the file first.) If not, just export the scenarios and discuss them in your browser, or over a printed copy.
Of course, the same process applies to web pages and web application prototypes. Liberal use of predefined dummy pictures will really speed things up during this stage.
3. Discuss the requirements implied by screen prototypes.
When working with the customer, present your ideas for each screen, what particular elements mean and why they’re there, what happens when a user clicks on something, and so on. Determine where each piece of data comes from. For example, if the table has a date column, what date is it? Creation date? Date of the last update? Something else entirely?
These are your real software requirements. Nail them. And pay special attention to data that has to be calculated, or that comes from other systems. Finally, let the customer do most of the talking. Your goal is to get feedback. Just moderate a little to make sure the conversation stays on topic..
4. Improve screen prototypes with new requirements.
When you get your feedback, improve your prototypes and requirements accordingly, and send them back to the customer for confirmation. If you get through to the customer, their mind could still be working over your presentation, and they could come up with quite a few surprises.
5. Specify requirements to complement the GUI prototype.
When a scenario’s finished, take five minutes to clear your mind. Go through screen prototypes and document them one by one. Focus on putting everything to paper as soon as it comes to mind. Don’t analyze or structure anything, just let the associations flow and take some quick notes. Apply some minimal structure, but don’t do anything that doesn’t improve the information. With this two-stage method, you’ll be able to get through this extremely fast. One specific way is to export the scenario, print it (the webpage will open automatically), and write notes on the paper copy. Then copy some screens into word and structure your notes while typing.
When you’re finished, you’ll have a large part of both software requirements and user interface specifications. For smaller applications, that could well be all you’ll need.
Conclusion
This article doesn’t cover everything about GUI prototyping, and some important aspects of the software requirements process had to be omitted due to time restraints. But it is effective, and you should find this approach very rewarding. But remember to experiment and find what works for you personally.
And have fun!