One of my most dreaded tasks as a program manager has been writing product specifications. It seemed unintuitive that, after brainstorming and discovering the details of the user interface and interaction, the best way to describe it all would be screenshots and endless pages of pre-conditions, action, post-condition, edge cases, etc…
I wasn’t surprised that developers didn’t like reading them. Spec review meetings used to feel like one of the scenes from office space – and I didn’t even have my red stapler.
An interesting shift happens when a fellow PM started prototyping instead of writing specs. And because we were basically creating a prototyping tool, he was testing the tool along the way. Dog-food’ing, as we used to call it at Microsoft. I followed his footsteps immediately. And not only I was having a lot of fun creating prototypes instead of writing requirements, developers were having fun using them and providing feedback, and spec review meetings went by like a breeze. Instead of spending time on making sure everyone understand the description of the interaction, everyone was on the same page much faster.
Needless to say, the final product matched the interactive requirements far more than it ever did with written spec documents.
As I recently started using Keynote to create interactive prototypes, I found more startups teams willing to use the prototype as their requirements. I realized that Keynote is ideal for this task.
Here is how I use Keynote to capture and communicate requirements
I won’t go through the detail of creating an interactive prototype in Keynote, as this has been covered in several previous posts. Once you’re done iterating on the prototypes, it’s very easy to annotate them in Keynote using comments and presenter notes.
Comments are sticky-notes that you attach anywhere on the slides to indicate a special case for user interaction or a message for development or testing teams.
And presenter notes are great way to track discussions on a specific screen or interaction.
The best thing about this workflow is that neither presenter notes nor comments show up in slideshow mode. So they won’t be interfering with the actual interaction when the prototype is being tested.
You can also export to PDF with presenter notes included, and still maintain the interaction within the prototype – in this case, the sticky notes will not hide/show nicely in slideshow mode as they do in Keynote. This is a screenshot of the PDF export:
If you’ve been writing long spec documents, give Keynote a spin. This is the lean approach to capturing and communicating requirements. And you don’t need to use different tools to create your prototypes, take screenshots, embed them in documents or wiki, and make sure the screenshots are synchronized with written requirements.
If you’ve been using better tools/techniques for faster requirements, please let me know about them in the comments.