Sunday, July 6, 2008

Napkin Specification

When building systems, we've always got to watch out for the infamous 'Napkin specification'. This kind of spec looks good and simple, but when you start to build you would notice some detail missing.

For instance, consider a case where you're building the user interface for an application using a user interface wireframe and the business components have already been provided to you. At first glance, you might think, "How hard can it be? We've already got the screen design and have the business components built." As development begins, you start to build the user interface by disabling buttons that the user should not have access to (for whatever reason) and when you're demo-ing the system to the customer, the customer asks why the buttons are even on the screen when the user shouldn't be able to use them.

I wouldn't say there was no design here - there was a design specifying which screen element should go where, but there was no specification for the behavior of the elements. How much data should be allowed in a particular field before displaying an error to the user? What kind of data is considered invalid? For some people, "cooldude@localhost" is a perfectly valid email address but others would want a check for a dot in the domain name.

No comments: