If you’re not working with a professional designer, we have found that using these rules for defining specifications helps developers deliver your product as fast as possible. All specifications should be written
An image should be included to supplement the written spec, with the change pointed out
Images alone are not sufficient
If there is a change to an existing specification, then send it in writing, with an image included pointing to the changes.
Here are some examples
Bad specification:
“Make it look like this.”
Why is this bad? This is an existing page. We have to look all over to find what changes were made. You know those puzzles where you have to find the hidden images? That’s what this is like.
Bad specification:
1) Change the phone number to (970) 305-6305
2) Put a border around the button that says “Explore our services”
3) Make the logo bigger
4) Change IGNITION to be all caps
Why is this bad? Which logo should be increased?
How big should the logo be?
We have to search the code for where Ignition is
What pages are affected by the phone number change? We will have to spend time searching this.
Good specification:
1) Change the phone number to (970) 305-6305
In the header of all pages (see screenshot)
On the contact page
In the footer
2) Put a border around the button that says “Explore our services”
3) Increase the logo size to 35px
4) Change IGNITION to be all caps
Why is this good? All of the changes are described in writing, and they are pointed out on the picture, so if there is more than one spot that has the logo, we know which one to change, and there is no question about it.
We are given a specific size for the logo. No guessing or going back and forth about what it should look like.
All the pages affected by the phone number were listed out, so we know all the areas that should change. There is no worry of us missing one.
We can get to work on it right away, instead of spending 30 minutes or more sending emails back and forth trying to clarify the uncertainties.