The Benefits of Process
April 20, 2005 | 
9 Comments
A few days back Garrett wrote a great post that got people thinking about how ideas are presented to clients. He makes some awesome points. The idea that your clients are paying you, as a consultant, to direct and advise them is a solid one that I’ve thought about quite a bit in my newish agency career.
I think one of the reasons why designers go with more than one direction is as a safety net. It may be uncomfortable for a designer to go with one direction because they might not have the confidence or be informed enough to bet the house on one direction.
This is where a good, and easily explainable process can step in and work wonders.
What’s the point of process?
I used to ask myself that question. I’ve worked on many projects that seemed to be quite bogged down in process and I used to blame (at least partially) many of the problems I’d run into on an awkward or inflexible process.
I’ve since learned that, much like design, a process can be overdone. You can over-process just like you can over-engineer. Especially with the Web, your process needs to be flexible and easily adjusted to the needs of your project and your clients.
It’s important to remember that a good process helps to inform as it goes along. It should provide you with the direction, evidence and confidence you’ll need to get to the best possible solution. If it’s not doing that, it’s not working right.
As well a good process for Web is once that can be broken when needed. But don’t tell anyone I told you that. ;)
A good process is hard to find
At PBDH I came into a situation where they had a pretty good process in place, so I was lucky in that. However, it wasn’t (and still isn’t) perfect. A good process takes lots of work, and needs to be adjusted as lessons are learned. As well, it needs to be open enough to account for the unseen and flexible enough to fit many projects.
In order to find a process that works for you, you need to put quite a bit of thought into it. I’ve spent hours re-thinking and re-working our current process and while I think I’ve improved on it, and the changes I’ve made seem to be working well, I still feel it can be improved upon.
To give you a frame of reference our typical process consists of four phases that don’t always run in a linear fashion: Scope Assessment, Information Design, Interaction/Visual Design, and Code Design/Production. The key to note with this process is that it’s not exactly linear and there are many bits within each phase that overlap. User testing and research, for example, would ideally run through all of these.
This makes it a bit tricky to show and/or explain.
A good process is explainable
One of the values of a good process is to inform the project, the other is to help guide your clients and stakeholders toward the best possible solution. Having a process that is explainable and understandable is key.
This is much easier said than done. We’ve spent lots and lots of time trying to come up with visual aids and elevator summaries that relate to our process. How do you explain, for example, how a Page Description Diagram works in relation to a wireframe and design comp in such a way that a CEO can easily grasp the value of the deliverables?
One thing I did was write and re-write analogies, sound bites and pitches for each step in our process as well as each deliverable. This was time consuming and it hurt my brain, but I can now explain how and why each step and each document is of value.
This should help when guiding your stakeholders to the best possible solution. Thus making your job easier while ensuring the best possible end result.
A process should help, not hinder
If you’ve got a process that’s causing more harm than good, my advice would be to lose it. The last thing you want to do is spend valuable time struggling with your process. A good process should become almost second-nature with the majority of work involved relating to helping your client understand it and buy into it.
A good process should inform your work, give you confidence in your decisions and give your clients and stakeholders faith in you.
Filed under: Web Design
Keyword Tags: web design process clients
Comments
1. Kevin said:
It’s funny. I was just thinking about processes and workflows and their effect on web design projects. My take is that “process” means something different to different people. Toa manufacturing manager a process is really an algorithm — a series of repeatable steps a that guarantee an expected outcome.
For many designers a process is really more of a workflow. It is meant to provide direction but it is flexible and does not guarantee a successful outcome. You can follow the same steps on two projects and create the same deliverables but one may be more usable, more accessible, or simply more esthetically pleasing.
I think that the disparity between the two definitions for process is what leads to many of the problems we have in explaining to clients in other industries how we work and why we work that way.
Posted on April 20, 2005 03:08 PM | #
2. Kyle said:
Iteresting, thanks. Any plans to put your process online for us to take a peek at?
Posted on April 20, 2005 11:49 PM | #
3. Oto said:
In my Web development company we have spent the past couple of years devising and refining a Web development process that would work for any type of site. As a matter of fact, we have started a blog targeting this very problem at www.webassemblyline.com. The entire blog can be summarized in the following words:
Like the rest of the IT industry, HIGH-QUALITY Website will also have to become a commodity soon. If a Web development company wants to sustain their profitability and not OVERSHOOT their clients’ needs they need to implement a rigorous, efficient Website Production process with great Quality Assurance. To establish a Website Assembly Line every project needs to start with a blueprint.
We truly believe that each Website development project can be guided by a standardized development process.
Posted on April 21, 2005 05:52 AM | #
4. Keith H. said:
I agree with Kevin here. Process means different things to different people, and even in the world of web design/development it can mean different things. For the creative side of things, it is more of a loose set of guidelines. A framework that helps us and our clients to communicate. Creatives are a bit of a different breed. We need tools that will help us generate those big ideas without boxing us in.
On the more technical side of things, process is more like Kevin’s definition of the manufacturing process. A less flexible set of rules that tell us when we should do what, and how things should interact like design patterns. It’s like the difference between cooking and baking. In cooking you can throw spices in here and there, perhaps cook things a little under or a little over and still have a delectible product. Baking requires more precision. Too much baking soda or not enuff time in the oven and your creation is ruined.
In my experience, process is a sliding scale in relation to your task. For example, while programming is more like a manufacturing process, it still requires some flexibility for creative innovation. And while creative design is much more amorphous and allows for more experimentation, when we get down to the specific techniques we use it can be more stringent.
Lastly, the processes you use are also dictated by your client’s needs. Many smaller clients may not have the budget for long drawn out processes. For them, we must pare things down, yet still provide a high quality product. So maybe you don’t give Joe Schmoe’s Widget Company three design concepts. Maybe he only has budget for one very well thought out concept. No harm, no foul.
Posted on April 21, 2005 06:41 AM | #
5. Krista Stevens said:
Hey Keith,
Thought provoking post, as usual. I’m curious about the analogies you’ve come up with to illustrate steps in the Web design process and communicate the value each step provides. Can you share?
Btw, love the redesign. ;)
Posted on April 21, 2005 07:51 AM | #
6. Zelnox said:
One thing I find hard to do is measurement (for metrics). How can you improve from one project to another if what you want to compare is only qualitative? Metrics allow us to see more clearly and adjust at a finer level. The methods for capturing metrics have to be refined too.
And yep, a good process should not hinder.
Posted on April 21, 2005 09:17 AM | #
7. John Zeratsky said:
Hey Keith: I’d love to hear more about your base workflow (Scope Assessment, Information Design, Interaction/Visual Design, and Code Design/Production). Where do you draw the line between info design and interaction/visual design? Where does IA fit into this? How much time (relative to the project) do you spend on scope assessment?
I realize a workflow/process is a starting point, so it’s different every time. But it would be cool to hear how things usually shake out for you.
Posted on April 21, 2005 10:45 AM | #
8. Keith said:
Krista – As far as analogies I’ve used go the one I’ve been trying out here at PBDH is a house analogy. Mainly because we work in a house, but it does fit. You’ve got plans, a process, standard materials and best practices. You can explain some of our development methodology this way as well CSS=wallpaper or paint, etc.
John – It’s funny you mention drawing a line between those areas. This is what makes process hard. They overlap quite a bit. We’re not done but we’re working on a way to show this and explain it to clients. IA, for example, fits into the first three areas a few ways. Once we’ve got it a bit more worked out I’ll do my best to share! ;)
Posted on April 21, 2005 03:20 PM | #
9. jennifer said:
Hi Keith,
Amen.
It’s nice to see that your process and mine are similar. Although, the desktop wallpaper on my Mac is a photo of a brickwall…
I think one of the more important things to keep in mind with a process is making sure everyone involved understands it. If it needs to be scaled up or down, people still know which way to turn. Of course, each project, each client is different. The confidence and efficiency lies within knowing the steps or phases of the process, regardless of how compact or how iterative they can become.(Or not.)
Have you read the publication “Clients vs. Developer Wars?” It addresses the process issue. Sounds like we all sing a similar version of the same song. :-)
Here’s the link:
http://www.newfangled.com/background/book.php
Some interesting ideas for helping the client understand the shift between static comps and the actual web dimension. (aka: “Kill me know” phase)
Cheers!
Posted on April 22, 2005 03:43 PM | #
New Comments Disabled
About The Author
is a writer, designer, etc. in Seattle, Washington.
Hire me
Links
Home | Search | Archives | Subscribe
Warning: include(/home/.idol/dkr/7nights.com/asterisk/includes/old.php) [function.include]: failed to open stream: No such file or directory in /home/dkr/7nights.com/asterisk/archives05/2005/04/the-benefits-of-process.php on line 329
Warning: include() [function.include]: Failed opening '/home/.idol/dkr/7nights.com/asterisk/includes/old.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/dkr/7nights.com/asterisk/archives05/2005/04/the-benefits-of-process.php on line 329
Hosting provided by:
The highly recommended Dreamhost!
