There’s often a disconnect between the design comp and what the developers want to build. Designs feature elements that differ slightly (or grossly) from previous elements that have been designed.
When this happens, developers have a conundrum. Do they (A) develop a pixel-perfect implementation of the design or (B) use existing patterns that differ from the design in front of them?
What we have here…
If the developers build to the design composition, the code base grows with exceptions and design inconsistencies.
If the developers build using existing patterns, designers might push back on how things don’t match what was designed.
…is failure to communicate
Everything that a designer draws in a Sketch or Photoshop file needs to be turned into code. Code needs to be developed, delivered to the user, and maintained by the team.
That means that complexity in design can lead to complexity in code.
That’s not to say that complexity isn’t allowed. However, it is important to consider what the impact of that complexity is—especially as it relates to your codebase.
The same thing applies to print designers. What kind of paper do you use? Four colour process? Spot varnish? These things all impact costs.
How elaborate are your digital designs? Do you require a lot of individualized art direction for each page? Oversized hero images? Custom interactions? These things impact costs.
For example, having a component look a bit different on different pages can result in extra code to accommodate those differences.
Pattern libraries are one tool in managing project complexity. By grouping like with like, we can see the complexity right up front. It allows both designers and developers to review whether yet another component variation is necessary.
One thing that many pattern libraries don’t have but should is a rationale or explanation as to what problem each component and component variation solves. That way, a rationale is required to explain why the library should be expanded (and why the cost to build, use, and maintain the code should be increased).
Talk, talk, talk
This is why it’s important to have these conversations during the design process. It’s important to understand what the priorities are within your team. It’s important to understand what tradeoffs you’re willing to make. Without consensus within your team, you’ll continue to butt heads as the requirements of the front-end development team conflict with the requirements of the design team.