The Power of Process, The Perils of Process

Posted by
“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.”Traditionally, information architects and designers (UI, visual, ID) are creatures of process. We generally work in prescribed ways—discover, design, validate, repeat. We sketch first, then create rough flows and then finetuned detailed wireframes and mocks. This usually works well, once accepted, and most companies—whether in-house teams or consultancies—work along similar lines.

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.

Thinking about your work process in this way, getting your team or company to agree upon the framework and toolsets, and then remaining flexible within the overarching process structure will ultimately free you up to apply your skills to the tough problems—the design problems—and not the process.

Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.


  1. I have to agree, it’s a framework/guide, it is not “THE” way to do things. Also a project process, product lifecycle diagrams, are only as good as everyone’s involvement and committment to it.

  2. “We generally work in proscribed…”

    “2 : to condemn or forbid as harmful or unlawful : PROHIBIT”

    “1 a : to lay down as a guide, direction, or rule of action : ORDAIN b : to specify with authority”

    I hope you meant the second word, not the first! 😉


    PS: I hope that this isn’t a smarmy comment. I would have sent this directly to the author, but couldn’t find her email address…

  3. Not too smarmy a comment – and I always appreciate knowing if I have misused a term. FYI for future – all posted comments get sent directly to the author as well as being posted in the discussion area.

  4. Great article! Reminds me of the Buddhist adage: “Religion is a finger pointing at the beauty of the moon. If we focus solely on the finger, we shall miss all that beauty!”

    Or, to put it more tactically, one should never mistake the map for the terrain.

  5. Designers should be sensitive to what and how much detail regarding the proposed schedule or process is released to their clients. Not advocating being deceptive here rather don’t overwhelm with too much information that your customer might not get in the first place. Releasing too much information may leave them with no other option than to balk at activities that they perceive as unnecessary. Nice article, Erin.

  6. Well said, Erin! Your article couldn’t have been more timely, as we are struggling with a process that seems to defy all attempts at actually applying it. I have long advocated a change in names to better describe what it is that we do and you were better able to illustrate my opinions than I. Thank you.

  7. Thanks for the excellent and timely article, Erin. We’ve been struggling with similar issues in our own firm. Perhaps it’s a result of the current economic climate, but we’re finding our clients are increasingly interested in knowing how we get from point a to point b with our creative work before signing on.

    It’s a form of comfort that upper level decision makers are looking for in order to rationalize what may be viewed as an intuitive and subjective process (for brand identity and package design programs anyway).

    However, not *all* our clients are intested in process per se. Some have indicated the reason we were selected over our competitors is exactly because we don’t adhere to any one proprietary process. So your notion of the procedural “buffet” – a series of micro-processes within the larger framework that can be turned on and off according to project/client needs – is very intriguing. Thank you!

  8. I just taught a class on the UCD process, and of course you learn a lot from teaching others… I tell folks that you need to “right-size” phases and activities based on the needs of a project. You usually can’t be rigid — not in most cultures, and even if you CAN be rigid, the rigidity can get in the way of serving the business/client well.

    I also agree with Mike, that many clients don’t need to know all the detailed steps of the process. Of course it depends on what you’re selling. If you’re selling a completed product (e.g. web application), then the client doesn’t need to know about everything that goes into it. It’s much like if you’re paying a builder to build a house — you don’t really need to know about all the steps involved. Of course if you’re just selling one part of the process (e.g. usability testing), then you have to provide enough detail for the client to understand what they are buying and key milestones where they need to work with you.

Comments are closed.