The Devil’s in the Details

Even with the emerging push to get off paper and on to the screen with the use of rapid prototyping, it is still important to write down what you are going to build before you start building it. There are several strategies for how to communicate to both stakeholders and developers exactly what they’re getting themselves into. Here are a few I use and love.

Wireframe Annotations

I’ve gone on before about lowering the fidelity of your wireframes in order to get them to the screen more quickly.  I still believe in this concept, but the part you can’t skip in your wireframes is the annotations. They should not be formal business-analyst-sounding functional requirements starting with, “The system shall execute the…” mostly because no one will read that. What they should be is a handy reference for clients and developers alike to communicate how the sketches they see will actually get on the page.

The more you write down, the more you are forced to think about how something will work, and it will be easier to see where the holes are. It can be really difficult to decipher precise functionality from wireframes alone. The client/stakeholder needs to have their expectations set in reality. If they’re just looking at a picture, they have no idea how it’s going to work.

This will help the developers out too, because they don’t have to think so much when they are building. For example, you’re creating a news site that has articles on it. The article pages have a box in the right rail for “related headlines”. There are a multitude of ways those headlines can get on this page, but how does the client want them selected? Will they have the staff in place to manually decide which related articles are the most relevant? Do they have a tagging system in place that you can use to automate the selection of the articles? Does the order in which they appear matter to the client? If so, how is it determined? These are just a few questions you’ll ask yourself and your client as you go through the process of annotating your wireframes. In the end, you should have a solid solution for how to proceed with building the page, which will save your developers tons of time and make your project manager love you.

Interactive Mockups

A lot of times clients have already gone through the wireframing and/or design process themselves and hand over a set of comps to start build off of. Inevitably, there are going to be issues that arise as you begin laying out your plan for building the site. A good solution for working through these issues with your clients is to throw the documents into an interactive mockup using a service such as Balsamiq or InVision (or a host of others). This allows you to have a running dialog directly on the comps/wires via a comment/reply scenario.

This is a very simplified version of what you can do using these interactive mockup tools, but it’s still very effective. It enables conversations to happen asynchronously, giving both parties time to think about how they want something to work or offer a better solution.

Write it Down

Sometimes having multiple conversations going via wireframe annotations, interactive mockups, emails, etc. can lead to more confusion than solutions. In this case, it’s often best to write it all out into one cohesive strategy in a centralized location such as a Writeboard on Basecamp or a notebook in OpenAtrium.

Overall, just remember that your life will be easier if you always write it down.