Creating storyboards and wireframes for your project

Written by: Jonathan Briggs

October 28, 2008 [4757 views]

Very many projects this year involve using the web and so Mike Goodland asked me to look at the techniques we use to make sure that the projects are delivered on-time and on-budget. Please feel free to ask questions if they will help your own project.

Our projects tend to have the following phases

1. Pitching
2. Research and discovery
3. Specification
4. Creative design
5. Implementation
6. Testing including user testing
7. Delivery
8. Maintenance

So far, this is very standard but web projects tend to suffer from the following problems

1. Clients don’t have a clear idea of what they want, what their customers need (often not the same) or how long things will take
2. Developers always underestimate the work involved in developing new software
3. Testing time tends to get squeezed
4. Testing and particularly user testing tend to reveal misunderstandings, functional changes and improvements that have to be implemented before delivery.
5. Design and implementation interfere with each other with designers making coding difficult or developers forcing redesign to cope with implementation
6. It can be extremely difficult to make money

Prototyping, Rapid Application Development and AGILE

The classic software project management approach is to try and ensure that the research, analysis and discovery phase is so thorough and the specification so watertight that the design and implementation phase becomes straightforward.

This simply does not work for these types of projects.

We therefore try to use a prototyping approach based on the AGILE methodology to flush out likely problems as early as possible within the project. Our first prototypes will be on paper. We create detailed wireframes (in OmniGraffle or Visio) for every interaction to illustrate all the steps in the “customer or visitor journey”.

Example wireframes home (15 KB) confirm (16 KB)

These wireframes are then used with the customer to discuss all aspects of the requirements. Revised diagrams are then drawn reflecting their changes and we iterate towards an agreed set of functionality.

At the same time, the wireframes are used by the designers to initiate the design part of the process. The wireframes are not intended to represent the “look and feel” of the project but simply the functional elements of the design. Designers are free to represent these in any way they like.

The wireframes also provide a specification against which the developers can implement the code. Developers can begin implementation of the site before the design work is finished (if a clear separation model exists between design and code).

Analysis, design and coding are therefore happening simultaneously for some parts of the project with frequent iterations.

1. Prototype the hard bits
2. Prototype early
3. Look for existing code
4. Use the best tools for the job even if they will not be used again
5. Make sure that the client understands the objective of the prototype
6. Don’t be satisfied with the prototype

Advantages of this approach

1. ”Bodies buried” in the project are discovered sooner
2. Client has a clear picture of what the eventual system will do
3. Designers have considerable creative freedom
4. Developers are not waiting on the completion of the designs
5. Wireframes become a reusable asset for common functionality without creating cookie cutter shops, sites & systems
6. Fixed priced projects have the potential to become profitable.

Lessons for final year projects

1. Be clear what does not count as a project and why?
2. Ideal project: Real client, Technologically interesting, Allows you to use what you have learned, Strategic elements for your client
3. Avoid having the university as your client
4. Understand the role of the supervisor
5. Seek out expertise
6. Find ways of showing off
7. Break out of the rules
8. Find an angle on your project
9. Implement prototypes early - right now
10. Learn some new software/languages
11. Understand that your project sits in a technological/business context
12. Value your time (and mine)
13. Consider making your client only a case study
14. Distinguish between passing and doing well
15. Avoid “adapting” or “boilerplating” previous PIDs or projects
16. Make the “review and conclusions” work for you
17. Avoid journalism
18. Don’t plagarise EVER!
19. Finish a first version of your project by the end of January
20. Use a rapid prototyping methodology
21. Create a paper prototype as part of your analysis phase
22. Use it to agree functionality with your client and supervisor
23. Diagrams become part of your documentation.

Feel free to ask questions here.

What do you think?

Add your comments