Designers Asking Engineers Questions: How to Stop the Slack Tax
By Fahad Ijaz · · 6 min read
Every designer has the same workflow problem. They're working on a flow, they need to know how the existing version actually behaves in edge cases, and the only source of truth is the code. So they ask in Slack. The engineer who answers loses 23 minutes of focus. The designer waits 90 minutes for a reply. Multiply by every designer, every day. That's the Slack tax.
Why 'Just Read the Code' Doesn't Work
Designers can read code. The problem isn't comprehension, it's locating. A senior engineer knows that the password-reset email template lives in services/auth/templates/reset.tsx. A designer doesn't, and finding it requires either grep skills they shouldn't need or guessing through the file tree. The information cost is in the search, not the reading.
Why Documentation Doesn't Fix It Either
The standard answer is 'write better docs'. Three problems with this. One: docs go stale within a sprint. Two: the questions designers ask are too specific to anticipate ('what happens when a user with no avatar opens the profile menu on mobile?'). Three: maintaining a doc that answers every possible question is a full-time job nobody has.
What Actually Works: Searchable Code Behaviour
The fix is making the codebase itself queryable in plain English. When a designer can ask 'what does the empty state of the inbox look like for a new user?' and get a cited answer pointing at the actual component, the question never needs to land in Slack. The engineer keeps their flow. The designer gets the answer in seconds instead of hours.
What to Tell Your Design Team
Don't tell them to stop asking. They're asking because the information exists nowhere else and your engineers are the bottleneck. Give them a tool that answers the same questions without an engineer in the loop, then watch which questions still come through Slack. Those are the ones worth a real conversation.