Over the past year, I’ve worked with a bunch of clients looking to translate their ideas into something others - specifically, their developers - can understand. The process is difficult for a number of reasons, but I’ve found a few methods for making life easier.

In the past, I have used written specs with spreadsheets for verification of requirements. Sometimes, this is adequate, especially after launch when requirements are small changes. Supplementing written specs with images is a good idea, too.

But I often find that clients want more: they want to be able to show the developer their ideas on how the website should “flow”. After all, this is often a key aspect of their product, and thus, their competitive advantage.

There are a couple of methods I’ve used that do ok at communicating a website’s flow. Firstly, one can use sitemap diagrams and these do a great job, especially when supplemented by the written spec. It’s difficult to give a complete expression with a sitemap, however, as it displays only the primary parent-child relationships in the site heirarchy. And there is no real feel for the end-user’s experience.

Another method for elucidating flow is the production of paper prototypes. I actually quite like these because there is a lot more information about how the website will look to the end-user; there are basic details about page elements and how each element contributes to the application. The primary disadvantage of paper prototypes is that they are unwieldy and it takes a good deal of concentration to follow paths through them.

I’ve also tried wireframing, which is a good means of expressing the flow, the experience of the user, quite quickly. Jumpchart.com is a good online collaborative wireframing tool that uses Textile. I tend to think, however, that one could get equally good results using Wiki software (yes, you can even get the export to HTML function from Wiki scripts), and I’ve satisfactorily used this method. I was even able to incorporate user stories into the interface which was a great bonus, and the tool allows iterative elaboration, lending itself to Agile projects. Overall, though, there are drawbacks to using JumpChart or wikis: clients will find them time-consuming and a little ugly.

37signals, creators of Basecamp, advocate using the interface as the spec: creating paper prototypes, then jumping straight into coding the HTML/CSS and using that as the specification for the back-end code. I really like this idea because it is unambiguous and all stakeholders can see exactly what will happen in the final website. Sadly, though, this is pretty difficult for outsourced development projects where clients rarely have the skill or time to manipulate HTML. Still, I think there is a lot to this idea and I expect I’ll talk more about it.

For the moment, I’m sticking with wireframes, sitemaps and supplementary written specs. Taken together, this provides a good way to ensure contracted developers understand client requirements reasonably efficiently.