Adaptive Path’s Take on the Web 2.0 Spec
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.
November 7th, 2006 at 11:50 am
Specs like these are for when you aren’t building the app yourself, which is a situation that we find ourselves in often, working with client development teams.
The low fi animations shouldn’t take long to make, btw. I’ve made them in 20 minutes with animated gifs.
November 7th, 2006 at 1:51 pm
Dan: I totally agree. Re-reading my post, I realized it comes off sounding very “anti-consultant,” “anti-Adaptive Path” and I’d like to apologize for that: I worked previously in a “big consulting company with a funky accent in their logo” and the jaded ex-consultant came through a bit too heavily in certain sections.
I’ve actually been trying to get our product and development teams on board with doing “rich” specs like these. I’ve found a couple sticking points: people tend to believe the extra detail isn’t necessary (against which I argue, how can we design and develop that extra detail if it’s left out of the documentation process entirely), the process is too time consuming (against which I argue that the time is worthwhile and probably not much more than we spend on “flat” specs now), and, finally, that people may not have the background to pull these specs off. It’s this last point that I can’t counterargue.
Working in a very mixed environment where the spec-writers may not have design or development backgrounds, I find that the biggest sticking point to introducing rich specifications is that people are afraid to believe that their design - PPT - HTML - Photoshop - (heck, even Paint) skills are good enough to do prototypes or specs like these. People are reluctant to enter the imagined world of the “designer” or “developer” - “the only people with the skills to do these things” - which makes them reluctant to produce the high-quality documents that you and I believe should be produced throughout a project process.