You know the feeling. That knot in your stomach right before you call the developer — again — to fix something on the website. It’s already the 42nd round of feedback, and every time they tweak one thing, something else mysteriously breaks.
In our previous article, we unpacked the full journey of how a creative vision becomes a design, and then (sometimes painfully) becomes a live website. We explored how the design abstraction and the development abstraction often drift apart — and how that disconnect leads to frustration, mismatched expectations, and yes... that infamous stomach knot.
The best solution is to involve the developer during the design process.
In this article, we’ll walk through practical tips that will help you:
- reduce friction,
- avoid the infinite feedback loop,
- and actually enjoy working with your developer.
You’ll get the most out of this if you read the previous post too — but this one stands on its own. Let’s dive in.
How Can You Actually Solve the Communication Struggles?
After enough projects — and enough feedback loops — your natural immune response might have become:
Fine. I’ll just design everything. I mean literally everything…
You provide detailed designs for
- all states,
- edge cases,
- numerous screen sizes,
- animations.
You define every tiny detail. And yes — this approach does drastically reduce misunderstandings.
But.
It also drastically increases the workload.
And with that, your quote might just take off into low-Earth orbit 🚀
So... How Do You Design Less, but Say More?
No matter how many details you design, some information will be lost along the way.
The solution isn’t to overdesign.
It’s to communicate logic — so developers can reconstruct what’s missing, in a way that still aligns with your vision.
As we said in the previous article:
The goal is to bring the developer's abstraction closer to the design abstraction.
That’s how you fill in the gaps with shared understanding.
Here Comes the Practical Part
Developers tend to start with edge cases. That’s just how their brains are wired — they look for structure, rules, and patterns.
So if you want them to resonate with your design here are the areas where your background logic matters the most — and where a little extra clarity can prevent a lot of chaos down the line.
🎨 Color Systems
Designers often pick colors by feel. “Let’s make this one a bit warmer.”
Meanwhile, developers are like:
Cool… so what hex code is ‘warmer’?
Color plate
Create a color palette with actual names, based on the color itself — e.g., red-100, red-500, red-900. This immediately signals relationships between shades, and allows developers to do things like pick a slightly different shade for a hover state — without guessing.
You don’t need to fill the entire scale. Just use the numbers to indicate position and intensity. Also you can squeeze in a red-150 later if needed.
Flexible and future-proof.
Opacity
Also — don’t define lighter colors by adjusting the opacity of a base color unless you intentionally want that color to blend with the background. And if you do, comment it — so the developer knows it’s not a mistake. Otherwise, extract the final hex value.
Trust me: this is not something you want the developer to guess 😅
Colors by function (optional)
Define functional color tokens using values from your palette:
- primary:
blue-800, - secondary:
orange-600, - error:
red-500, etc.
This becomes essential if your design uses multiple themes (like light/dark mode) or if functional colors vary by context (e.g. each blog category has its own color). Even in simpler designs, define what text colors are used on light vs dark backgrounds.
📏 Spacing
Random paddings like 17px, 31px, or 53px — what should we do with them? Should we round them? Or were they intentional?
Developers try to create rules and proportions. If values have no logic, they’ll struggle to scale them across screen sizes.
Use a spacing scale
Multiples of 4 or 8 work well: 4, 8, 16, 32, 40, 80, 120...
They’re easier to work with, more predictable to interpolate, and lead to more consistent layouts.
This is just a recommendation — you can totally go custom. The important part is to share the logic with the developer and agree on it upfront. For example:
- Option A: “Here’s my spacing scale. If I deviate from it, feel free to round to the nearest step — and I’ll leave a comment for any intentional exceptions.”
- Option B: “Please use the spacing values exactly as designed — I’ll make sure every single one is deliberate.”
Pick one, communicate it clearly, and stick to it. Your dev (and your layout) will thank you.
🔠 Typography
Typography is one of those tricky areas where it’s hard to define strict global rules — because there are always exceptions.
At the very least, define your base styles for:
- Headings (semantic HTML tags like h1, h2, etc.)
- Headlines (visual styles used in hero sections or cards)
- Body text (default paragraph styles)
Include variants for:
- Different screen sizes (mobile, tablet, desktop)
- Different contexts (e.g. blog vs landing page — maybe smaller headings on blog, different line height in articles, etc.)
When these basics are clear, a cohesive page can be assembled even from a wireframe and some copy.
Just like with spacing, what matters most is setting expectations:
- Which values are the defaults?
- How should they handle exceptions?
If this is clear from the start, they’ll know when to stick to the system — and when a deviation is intentional.
🧩 Component States
Buttons, cards, links, forms — they all need states: hover, active, disabled.
Don’t skip these. Don’t assume “they’ll figure it out.” Even a few comments are better than silence.
Think of edge cases
If the content is dynamic or user-generated, components like article cards raise questions like:
- With and without images
- Short vs long titles
- Optional descriptions
- How will different versions look side by side?
True story
We once had a beautiful column of three service cards. With the word “Sustainability,” it looked elegant. Then came the German translation:
NACHHALTIGKEITSBERATUNG.
Let’s just say… it didn’t quite fit the original design anymore 😅
Animations
Is that dropdown fading, sliding, or spinning into view? Comment where animations are required.
Different animations can have wildly different dev cost and complexity.
📱 Responsive Layouts
Yes, you’ve designed desktop, tablet and mobile. But that’s still static.
Here are a few important questions to ask:
- Are your designs meant for the top or bottom of each breakpoint range — or somewhere in between?
- What happens between those sizes? (e.g. do cards scale fluidly, or do they reflow?)
- Does the logic still hold at the breakpoint edge? (e.g. if desktop starts at 1024px, does the tablet layout still look good at 1023px?)
- Which containers scale infinitely, and which have a max width? (There’s always a bigger screen…)
- Do components fundamentally change at certain breakpoints? (This often doubles the dev effort.)
Keeping these questions in mind can make things much simpler.
✏️ Content Editing Logic
This one’s relatively simple — until it’s not.
You think it’s obvious what the client can edit. The dev thinks they know. The client assumes they can edit everything.
Talk it out. For every editable section, agree on:
- What lives in the CMS
- What’s fixed
- What limitations apply (e.g. max 5 nav items — what happens if there are 8?)
Editable content means dynamic layouts. That means more logic, more edge cases, and more tension if expectations don’t align.
So align them early.
Final Thoughts
A great developer can build a site that looks exactly like your design.
An excellent developer will also understand your logic — and help build a scalable system around it.
But even the best devs can’t read your mind.
So whether you choose to design more, communicate better, or find your balance somewhere in between — the real key is this: Align your abstractions early.
If you’re a design studio looking to work with developers who speak your language and respect your craft, we’d love to talk.
👉 Check out our Mindful Development for Design Studios service page
or
👉 Book a free consultation to chat about how we can avoid the nightmare — together.
Let’s build something beautiful. And maintainable. And… stomach-knot-free.