Boxes And Arrows : The Design Behind the Design

The Power of Process, The Perils of Process

by Erin Malone on 2003/07/28 | [8 Comments]

In my experience, I have found that creating and documenting process has been a good exercise to help institutionalize ways of working, to help educate new team members as well as to unveil the mysteries of what we do for executives, product folks, and development teams.

In my currrent situation, an agreed upon process has helped teams working in multiple time zones and across several locations to get their work done. The process — discovery and exploration, concept UI development, review, creation of wireframes and user interaction flows into a draft UI, review, finetuning into final UI and then creation and finetuning of a functional spec — is the same no matter who is working on the project or what country they sit in.

There is a lot of comfort in this shared way of working. There are fewer concessions that need to be made. Roles and responsibilities are clearly defined and everyone knows what they are going to receive at each point in the schedule. The framework within which we all work allows us to be creative, but also keeps teams on track.

The power of a well-defined process is the creation of order amidst chaos. When it works, it can be like a fine-tuned machine, and our design work is better for it.

On the flip side, problems happen when people get complacent about the structure they are working within. Expanding phases excessively, becoming rigid about the order or duration of each phase, or even over-documenting the elements within a phase can backfire on a team. There are also problems when one team decides to work in a totally different way than another within the same group. Suddenly, no one knows what to expect, what the level of thinking or quality of the product will be, and internal fighting over whose process is best ensues.

There can also be credibility issues surrounding process and how teams work with it and within it. No one wants the reputation of being so bound to a way of working that they lose sight of the reason they are working in the first place.

I was recently called out for rigidness about process by a client who went crazy over a proposed schedule. The client didn’t understand why some of the work couldn’t be done in parallel, and why certain phases of the project couldn’t be shortened. Ultimately, we were under a tight deadline to ship, and to make the deadline we all (design, product, and development teams) had to make compromises. I assured this client that we generally needed to “ask for the moon” at first, and then would pull back to something more realistic given the circumstances.

The conversation got me thinking though about how we work and how structure can overpower the actual needs of the project. If a group is not careful, the process can take on a life of its own and make demands that exceed the requirements of the situation.

For all the benefits a well-documented and richly detailed process has, it should also be a framework that is flexible, that can be adjusted at a moment’s notice to fit the situation at hand, and shouldn’t exist for its own sake.

I like to think of design process as a grand buffet. One that has discrete sections—discovery/early user research, exploration/concept, draft, final—and review checkpoints throughout. I generally like to think of each section as being collapsible or expandable depending on the needs of the project and the time allowed. Ideally, no section would be collapsed down to nothing, but sometimes it might feel that way. I also see each section as having a buffet of tools and techniques available to help solve problems, keeping in mind that just because a tool is available in a particular section doesn’t mean it must be used every time. That’s the beauty of the buffet: the framework and structure are there, but usage of the tools is flexible and can be fine-tuned for the needs of the team and the project.