The Codification of Design
Jonathan Snook on managing the complexity between what designers make and what developers end up building:
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.
Jonathan continues in that post to argue that designers and developers need to be in a constant feedback loop in order to properly assess whether the complexity of the design is worth the complexity of the engineering solution.
I’ve been thinking about this sort of thing for a really long time as it applies to my work in design systems — I have a feeling this issue stems from the fact that designers and developers are trading with different currencies. Designers generally care about the user experience above anything else while developers may prioritize the code under the hood, willing to over-engineer something for this one tiny detail.
As Snook mentions later in his post, pattern libraries won’t solve this problem entirely:
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.
So, the best way to get those two groups to exchange the same currency is with talking, instead of tools. Or, perhaps by designing with code.
Direct Link to Article — Permalink
The post The Codification of Design appeared first on CSS-Tricks.
