Your NOT So Great Design Process

Once upon a time…

Add alt text

“Maybe something with an alternate layout, something that captures a certain feel, something that uses different imagery, something that just… pops…”

With the floodgates opened, the other stakeholders openly share their opinions and constructive criticism. By the end of the meeting, everyone has rambled off their wish list of what they’d like the design to accomplish.

Slightly deflated but determined, the visual designer retreats back to the drawing board to work on the stakeholders’ suggestions. At the next design review meeting, the same scene repeats itself, with stakeholders expressing encouragement and longing for more. “We’re almost there. Could we just…”

Weeks pass and hairs turn grey. Nerves wear thin, and the deadline date looms over everyone’s heads. It’s with a sense of urgency that wesbite_v9_final_for-review_FINAL_chrisEdits_for-handoff.sketch finally gets stamp of approval by the stakeholders.

The visual designer, relieved they’ve finally completed their part of the puzzle, proudly introduces the work to the engineering team. “Can you get this done in three weeks? We’re already behind schedule!”

The front-end development team spends time digesting the high fidelity designs, suddenly a combination of bafflement, rage, and dread sets in. Is something is wrong with the design? Maybe it’s the seven typefaces and nine unique button styles scattered throughout the comps. Maybe it’s the desktop-centric, impossible-to-actually-execute layout. Maybe it’s the perfect-yet-improbable user-generated content.

The front-end developer tries in vain to raise their concerns to the team, but is quickly dismissed as being either incapable or lazy. Alas, it’s too late to make significant changes to the design, especially since it’s already been approved.

So the developer tries their best and bend over backwards to create responsive layouts that still retain the integrity of the static comps, normalize some of the more blatant component inconsistencies, establish pattern states (like button hover, active, and disabled states) that weren’t articulated in the designs, and make some on-the-fly decisions regarding the interactive aspects of the experience. Discussions with designers are strained, but everyone realizes that they need to work through these issues to get the project into production.

After plugging the front-end code into a CMS, frantically finalizing the site’s content, and last-minute QA testing, the team finally launches the site. While no one says it out loud, there’s a tinge of disappointment in the air alongside the joy and relief of getting the project out the door. After all, the live site lacks the glossy polish that the comps promised to the stakeholders, and friction between disciplines has bruised some relationships.

If you’re lucky, this story should read as fiction to you, but based on my own experiences and conversations with others, I’m guessing we all have experienced this at one point or another in our design or development careers. Whether you’ve endured this process firsthand or not, it’s important to recognize that the Henry Ford-esque waterfall process increasingly isn’t likely to result in great digital work.

So how do we improve collaboration and eliminate waste when it comes our design processes?

Read more stories on https://medium.com/@semigrownkid

Story adapted from Chapter 4 of Atomic Design by Brad Frost. Read more.