Broken Process

Here’s a story we’ve seen play out a few times.

A hypothetical designer at a hypothetical organization is tasked with mocking up some new design element, which the development team will convert to front-end code.

After some iteration, the mockup looks like this:

It seems self-explanatory to the designer, so they throw it over the wall to the devs with the obligatory “let me know if you have questions” sign-off before moving on to other tasks.

A developer is assigned. They are well-regarded for their HTML, CSS and JavaScript skills, but they are not a trained designer. No questions arise as they execute on the design as they see it.

A week or two later, the designer is asked to check the QA site for visual bugs. They spot the new element:

Though the execution is faithful to the overall hierarchy and layout of the mockup, many of its undocumented subtleties (full-bleed image, unique icon, consistent gutters, etc.) have been unintentionally overlooked.

The designer opens an issue, attaching a detailed spec which takes longer to prepare than the original mockup:

The developer sees the issue and squints at the seasoning of 8px type. Though the details are helpful, they pose a few problems. The sizes and weights in the spec differ slightly from those used in the rest of the project’s styles. To make matters more complicated, other developers have already started to rely on the existing implementation in different parts of the site.

The developer knows they should reach out to coordinate with the designer and affected developers to form a plan and maybe agree on some reasonable compromises. But that would be time-consuming, there’s a pile of other bugs that need squashing, and the project lead won’t budge on this deadline.

With a sigh, they start a new rule at line 4,051 of their CSS file:

#showcase .related-stories .box a > img.splash-image {
  margin: -1em -1em 0 -1em !important;
}
Code language: CSS (css)

At the next design check-in meeting (with no developers present), the designers agree to start producing detailed specs to accompany every mockup they produce from this point forward. Though this may decrease the team’s velocity, the sacrifice is worth it to be sure the design vision is executed faithfully.

Shortly after the new feature ships, a user in Indonesia maxes out their data plan while attempting to load the organization’s 5MB homepage.

Though they may not know it yet, no one in this story gets what they want. The designers devote hours to mind-numbingly detailed specifications. The developers accumulate technical debt with each and every hack they’re pressured to write. The user struggles to load a bloated product that is likely riddled with inconsistent design elements. And the organization slowly leaks users and talent because of these problems.

Luckily, there are solutions:

• Designers and developers (and content strategists, too!) should be collaborating early and often so they can provide feedback, communicate intent and prioritize their efforts seamlessly and efficiently. Specs are fine, but they pale in comparison to the benefits of true collaboration.
• Abandoning the “one comp per feature/page” approach in favor of a unified design system (ideally a pattern library with an accompanying style guide) would promote consistency, focus the efforts of designers and prevent developers from needlessly reinventing the wheel.
• Adopting a strictly-enforced performance budget could help protect the end user from unwieldy load times as a result of overly aggressive project schedules.

More good news: We’ve helped teams adopt these sorts of changes. It may seem daunting, but we know it can be done!