How do you make product specifications comprehensive enough for AJAX, Web 2.0 apps? Simple boxes and arrows aren’t going to cut it: your spec must talk about complex interactions and behaviors, timings (of updates or polling), and application states. In short, you’re not just writing a document that talks about how code should work; you’re writing a document that talks about how people should work with your code.
Adaptive Path took a stab at the Web 2.0 spec and what’s beyond wireframes and came up with a three-pronged approach to documenting Web Twenty apps. Their approach is as comprehensive as any I’ve seen. However, cranking out specs like this seems like a product of having a lot of time (read: billing clients for hours worked) and may only play out will on large, highly interactive projects. (On short projects, these specs might take longer to build than the actual end product).
Specs really do help development, and Adaptive Path’s spec helps capture all of the important pieces of end-user interaction that make or break an app. Ultimately, these things are only as good as your product team: the people responsible for building the spec must have comprehensive knowledge of what can happen in an application for them to document that behavior or they must be willing to work with, and adapt their ideas to, the knowledge of practicing developers or designers whose knowledge of possibilities is greater. In all, writing specifications should be an iterative process with input coming from across all disciplines, a change advanced web applications are forcing to happen.
technorati tags:specs, product, design