Traditionally we’ve created static wireframes and specification documents to define a clients requirements. There are a couple of issues with this it’s easy to spend too much time on these diagrams and documents but more so these documents can overwhelm a client making it difficult for them to understand what they’re agreeing to. Down the path this generally leads to disappointment, pressure on the team to make last minute development changes, and a whole lot of other unnecessary grief.
Facing an issue like this it’s easy for a software vendor to say things like, ‘well they signed the functional specification document’ or ‘it’s not our problem that they don’t understand their requirements’. I think it makes a lot more sense to ask yourself, ‘what can I do differently to improve the outcome’.
Our plan
Here’s what we’re doing in a current project:
- Skipping the specification documents
- Creating a dynamic set of wireframes
- Getting the whole team involved in the planning and review workshops with the client.
Initial concerns
My concerns going into this were:
- How can ensure that we will capture the full set of requirements without specification documents?
- How will the testing team create their test plans and scripts with no specification documents?
- Will the client ‘get’ the wireframes?
- Is it too full on having the whole team involved in all of the planing and review meetings?
Preliminary results
We’re a fair way down the path with this project, and here are the results so far:
We created an amazing set of wireframes; that is, we did a much better job creating these through a brainstorming process with the whole team (much better than a Business Analyst talking to a client and creating them in isolation).
We have established great dialogue with the client because the client can see how the website will function – this has created a much better understanding of the client requirements – well beyond what the client could have articulated by themselves and beyond what we could have captured in static wireframes and specification documents.
The team feels confident that they can develop a solution that will meet the client needs.
The team is more engaged and motivated. We haven’t had a meeting where anyone has remained silent for the duration of the meeting or where someone has left feeling like a meeting was a waste of time.
Tools
We used Balsamiq Mockups to create the wireframes and Adobe Fireworks to add the hotspots to make the wireframes dynamic. Mark is a superstar at this and it took him next to no time to whip these up. I would like to give Mockflow a go as it looks like you can create dynamic wireframes in one go within this product.
Next time…
Would I give this a go again – most definitely! Would I change anything? The only thing that I would change is to do my best to minimise delays between meetings – this approach tends to work best when the momentum is full throttle. I’m looking forward finishing this one, discussing the results with the client and team, and then rocking on with the next one.
