There is a fantastic article at Smashing Magazine about companies’ love of deliverables. Even though it’s talking about the frustrations of designers, it’s entirely applicable to developers, and even the entire delivery team.
In this article, it’s suggested that any design project can be done with just the following four steps:
1. Strategy Document
Distill your research on users and the business down to a short vision statement on what the user’s experience should be like. Add to this a list of design criteria (specific guidelines or principles for the design), as well as success metrics (how you will know that the design is achieving your goals). You should be able to do all of this within just a couple of pages; and keeping it short will help to ensure that everyone reads it.
2. Activity Requirements
Write a list of tasks that users should be able to perform, and functions that the system should perform that will benefit users. Prioritize the ones that will appear on the screen.
3. Sketch
To apply the design criteria and meet (or exceed!) the requirements, sketch a dozen or so ideas — in Keynote, on paper or on a whiteboard — and then take pictures of the sketches. Sketch the toughest, most complicated and most representative screens first. These will frequently determine the interaction model for most of the design.
4. Comp and Code
If you’re not doing the visual design yourself, collaborate with the graphic designer to iron out the details of the most representative screens and any other screens that require graphics. At the same time, collaborate with the developers to identify issues and areas for improvement throughout the process.
Forget the lengthy strategy documentation. Forget the deck of wireframes. Just short summaries (long enough to get the point across, but short enough to be able to do quickly), sketches and comps, limited to the things that need to be brought to a boil in Photoshop. Skimping on the deliverables can save a lot of time.
The first two steps in particular can easily apply to the development stages. I know this is a ‘perfect world’ scenario, but it is possible to build a relationship with the client to allow you to do this.
For a waterfall-agile hybrid model, it would work like this:
1. Strategy Document
Business case, business rules and high-level requirements. Convert these into user stories if necessary. Get all the required functionality captured in a design-friendly format. I also love the idea of including success metrics here too. What does success look like?
2. Activity Requirements
Add enough detail to describe some iterations and to get the developers & designers started. There shouldn’t be any need for a functional requirements document, a detailed test plan, a deployment plan or anything else.
3. Iterate
Kick of the iterations. Keep the client involved and do a deployment at the end of each iteration. These iterations can then be tested and signed off. Each iteration needs to provide useful functionality that people can demonstrate.
This approach relies heavily on a great client relationship. If they don’t trust you, then they will start asking for more documentation and deliverables (such as test results, requirement documents, traceability documents, scope agreements, the list is endless). But the genius of providing useful iterations is that you can demonstrate that you’re working towards the end goal and you’re keeping the client involved in the decisions.
I don’t believe that anyone actually wants reams of documentation and extra deliverables. All they really want is the end product to work as expected.