The interface as a spec: including stories inline 30 Dec 2005
69 comments Latest by Geof Harries
Our very first Getting Real post was about saying no to the functional specifications document. We suggest building the interface first and using the actual screens as the functional spec. Read the post linked above to find out why.
There are times, however, when the interface doesn’t provide all the information required for the programmer to hook it up. Designers should always present the programmer with the multiple states of an interface element so the programmer understands what to display when this or that happens. But sometimes designing the static states takes more time, and doesn’t quite represent reality, as well as a brief note about how the functionality works. The key is to make this note in context — right next to the interface element its describing. The combination of real visuals and a brief contextual note shrink the chances of misunderstanding to near zero.
For example, we have tag functionality in the Sunrise app we’re developing. So, in order to fully explain the “entering a tag” functionality, we mocked up the basic UI and then included a story underneath the UI elements.
This helps the programmer understand how the functionality will work when it can’t really be simulated on a static page. Try this technique sometime — you’ll find it saves time and reduces the changes of misunderstanding by a significant degree.