Process, methodology, life cycle: No matter what you call the process of managing your design project from beginning to end, it can save your butt. You land a client or buddy who wants you to design a website. No problem, that’s what you do. Have you experienced the following?
- Scope creep
- Budget creep
- Launch delays
- Maintenance issues
Maybe it’s time to put a process in place that outlines the phases of your web design project. It doesn’t have to be complex. Even a one-person shop can do it.
No two processes are alike
No two web or software design methodologies are alike. I have worked in a process shop for most of my career and each company has similarities and differences in its life cycle outline. In general, the phases are similar and accomplish the same end result: a product that meets the client’s requirements.
If you don’t have anything in place, start with your next project and document as you work through it. Those lucky enough to work with multiple worker bees will appreciate having documentation especially when an employee quits or gets fired. The new employee (or the unlucky employee whose workload doubles by taking on the departed employee’s work) relies on the documentation to pick up what the disappearing employee left behind.
The life cycle is divided into phases because each one has specific activities and deliverables produced from those activities. Before moving ahead to the next phase, make sure all the activities and deliverables are completed. If you don’t, expect to have more problems than usual.
Before working on comps, you want to understand your client’s requirements and the scope. At the beginning of the project, gather information, complete background research, analyze the budget, outline the timeline, review maintenance needs, establish the purpose of the website, and document who is the target audience (you know that it is not the client who’ll put up with the website!).
In most cases, this is part of the project profiler. This is a bare-bones example, and you can modify it as you gain more experience. Identify the client single point-of-contact to avoid nagging from all directions. It’s valuable to clarify and document roles and responsibilities of the players on the project.
As the project progresses, a typical client or co-worker will attempt to add more stuff especially when discovering all those cool, wiggly thingies on the web. Consider explaining to the client that any change during the project requires a change request document. The document spells out the new requirement, modified timelines and approved budget for the changes. Too often, designers find themselves agreeing “to add this little item since we’re working on it anyway.” Those nasty little items add up to continuous sleepless nights.
Beneficial items to include in requirements:
- Technology capabilities
- Maintenance / support
- Site promotion / search engines
- Naming conventions
- Communications checkpoints
When all sign-offs and approvals are done, move forward to Design.
This is not the same thing as development where you begin coding or marking-up. During this phase, develop the architecture of the website using a site map, comps (or storyboards), and / or flow charts.
This is the place to document how the website features will function. Also, outline the procedures or steps the users need to complete a task. For example, a company requesting an online store needs procedures for finding, selecting, and purchasing items. If another company handles the purchasing phase of the store, you’ll be dealing with interfaces. So what do you do? Document how the interfacing will work.
If the project has sound, videos, or multimedia content, this is the time to define the content and gain approval. Again, obtain approvals on all aspects of the design before proceeding with the development. It’s a hell of a lot easier to make changes here than in the development phase.
By now, you should know what your client wants including the look and the feel of the website, the navigation, and functionality. Time to create the puzzle pieces and put them together.
While working through the components, test them. Better to fix a problem in unit testing while it’s at its smallest piece. Also, develop the database and do the back-end work. When the puzzle is complete and the beta design is ready for review, move into testing.
Some argue that testing should not be a phase because it occurs through many phases. While true, there’s a need to test the final product to ensure the whole thing is successfully integrated. Remember that you do unit testing during the development stage. Some shops do component, module, system and acceptance testing.
Not only make sure the website looks good, but also check its performance and back-end functionality. Do try to get the client’s end-users’ feedback since they will be the ones using the website. Try to add user testing to the requirements at the beginning of the project and explain the purpose to the client. Better yet, tell the client that the users aren’t as well informed as the client on the products and services, so you need lesser experienced folk to check it out. It’s perfectly legal to do a little brown-nosing.
Implementation / Production / Maintenance
You finally attack all the bugs, validate the site, and verify accessibility. Time to go live! At the beginning of the project, think about how much maintenance and support you’ll offer, if you’re not responsible for it on the long-term.
Create a style guide and train the client on maintaining the website using the guide. As usual, back up everything in case someone screws up and they almost always do.
When new requirements or change requests come in, repeat the whole cycle. If problems occur that could have been avoided or foreseen, document them in your requirements or design templates to remind you to discuss it with the client next time.
When a client wants to establish a website, his expectations are high thanks to the high quality, well-developed websites out there. It’s our job to educate the client on the costs involved with having a fancy website that can do everything and reality. The biggies have the money and resources to implement every trick in the book and it’s those websites the average Joe or Jane discovers and starts drooling for one.
Before exiting each phase, ensure you have completed all the necessary steps for the phase. Creating a phase exit criteria checklist can provide a sanity check. If you miss something the first time, add it so you’ll remember next time. The beauty of documentation and processes is the ability to adapt, add, and modify as you work through the development cycle.
If nothing else, communicate! In my experience, lack of communication is cause of 75% of the problems in development. Avoid making assumptions unless they’ve been documented. As much we’d like to believe it, we can’t read each other’s minds like they do on Star Trek.