Process, Methodology, Life Cycle, Oh My!

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#section2

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.

Requirements#section3

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:

• Message
• Audience
• Action
• Content
• Technology capabilities
• Maintenance / support
• Administration
• Site promotion / search engines
• Schedule
• Naming conventions
• Communications checkpoints

When all sign-offs and approvals are done, move forward to
Design.

Design#section4

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.

Development#section5

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.

Testing#section6

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#section7

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.

Final Nags#section8

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.