Mockups as a Spec?
Good mockups accurately describe system behavior and its outputs. However, screen sketches are not the specs by themselves. There are additional details that developers need to know. For example, system constraints and other non-functional requirements are important, as well as exact algorithms and calculations.
What your developers need from you is the complete and accurate representation of the system, both in terms of its function and its behavior.
What your developers need from you is the complete and accurate representation of the system.
With that in mind, go through all of your mockups and notes in order to assess what you have. Then, add the information from another important source: your own solid understanding of the system and its details.
Emptying Your Head
There is a quick way to connect all the dots at this point. I call it the “one-two approach”:
- Empty your brain onto paper.
- Structure and compile all the information together.
First, you methodically go through everything you have accumulated – every screen and every note, one by one. As you examine each of them, various thoughts on those ideas or issues will likely jump out anyway, so write them down. This requires no order and no structure. Just put everything on paper as fast as you can.
First, you methodically go through everything you have accumulated. Various thoughts on those ideas or issues will likely jump out anyway.
Why not structure or analyze the information? Because you need to keep your associations coming without stopping or becoming distracted. This way, you will be able to do this first pass far more rapidly pour out more information at one time.
Compiling the Information
When you have finished “emptying your head”, the resulting mess of information might not look very nice. However, you will be surprised at the sheer quantity of information that you have poured out.
Now, export your mockups to your favorite word processor, compile all the info into a spec, structure everything and present it logically.
Compile all the info into a spec, structure everything and present it logically.
Please don’t add anything that doesn’t improve the information. I have lost count of how many times I have seen a genuinely priceless piece of information polluted with piles of useless fluff. This excess is usually used for the sake of “completeness” or to adhere to company templates. If you positively must do it, try to separate all the extraneous material into appendices.
Don’t add anything that doesn’t improve the information. Keep your main document light and clean.
Keep your main document light and clean. This way, you are actually encouraging people to read it.
Now, all of this information sums up this process in an ideal world. For most projects, everything mentioned can be done in a relatively short time. The whole procedure explained above, from first mockups to the compilation of all the information, has evolved throughout the course of many projects with that precise goal in mind.
The Fireman’s Approach
However, what if you can’t go for the accurate and complete spec, for some reason? Perhaps you were called in only after developers realized that the spec was not up to par. Maybe deadlines were so menacing that everything blurred into a mad dash of overlapping activities that were difficult to organize or record appropriately.
Exporting your generously annotated mockups will give you “something like a spec” in no time.
When you find yourself between a rock and a hard place, even rough mockups are better than nothing. These are better when presented with a generous amount of on-screen notes, especially in such complex situations. This way, exporting your mockups into a .doc or .pdf will give you “something like a spec” in no time.
In that case however, be prepared for some significant multi-tasking for yourself.
You will need to clarify each tiny detail for your developers as you go along, especially the workings “under the hood”.
Keep one-step ahead of development
You can’t do everything at once, so you will be doing quite a lot of triage. For modules that need to enter development, tweak the rough mockups until they are confirmed. For modules that are already in development, focus on detailing the main outputs. At the very least, plan to start early in order to give your customer time to decide on any ambiguities in the business process.
Be available, keep one-step ahead of development, and have your customer dedicate people for this.
Since you have two simultaneous goals here, it’s strongly suggested to have two people (or teams of two people each) on this. One person should focus on the workflow (rough mockups), and the other on the outputs.
Have your customer dedicate people for this
Needless to say, fast and functional communication with your customer is a must. Insist that the customer dedicates people to help you and that they have the appropriate authority.
In short, mockups can also work as a spec if you have no other option or don’t mind living on the edge.
- Check out my book “Mockups 101: Help Your Customers Understand What They Are Going to Get.”
- Leave a comment, I’ll be glad to know what you think.
- You can share this article with others. To do that, just use the social buttons below.