In previous positions, where I've filled the role of analyst and UI designer, there has been times I've needed to capture this type of information in a single document. In larger teams, I rely on my data and systems folks to fill that role.

Perhaps with this example I did not intend to say that specifying forms in such detail is a necessity. Instead, I wanted to increase some sensitivity to such things as validation, values, max lengths, default values, etc, which somewhere one way or another could be considered.

Perhaps with this example I did not intend to say that specifying forms in such detail is a necessity. Instead, I wanted to increase some sensitivity to such things as validation, values, max lengths, default values, etc, which somewhere one way or another could be considered.

I think a more useful thing at this stage is to document how it might behave – eg: the text "includes meals and drinks" appears in the field, but disappears when you click in it.

We've found things like default state, values etc are best put directly in to a prototype. Depending on the development framework, things like what's in a dropdown become less relevant as they can be sorted out in the data model (eg: in an MVC framework like Rails)