Client vs. Developer: Lost in Translation
Developers and clients speak two different languages. No, I do not mean Python and English. I mean something much deeper — two completely different ways of perceiving reality. Where the client sees a "small change," the developer sees three weeks of rewriting. Where the developer says "that's technically complex," the client hears "I don't feel like it."
Over fifteen years, we have collected a gallery of miscommunications that could fill a textbook on communication. Or a comedy show. Depends on your perspective.
"Make It Pop!"
Three words that can paralyze an entire design team. What exactly does "make it pop" mean? For the client, it usually means: "I want it to be visually interesting and modern." For the designer, it could mean anything from animated backgrounds to 3D effects to a bouncing logo.
We once responded to this instruction by adding subtle micro-animations on hover, smooth transitions between sections, and a parallax effect on the hero image. The client saw it and said: "No, this is too calm. I want it to pop."
After two rounds of revisions, we discovered that "make it pop" in his case meant: "I want the page background to cycle through three different colors in an infinite loop." Like a disco. On a law firm's website.
We eventually found a compromise — an elegant color gradient that slowly shifted. The client was happy, users did not get seizures, and we wrote down our first rule of communication: never assume you know what the client means.
Lesson learned: When a client uses a subjective adjective, always ask for specific examples. "Show me a website that pops for you" works much better than three rounds of guessing.
"I Want It to Be Intuitive"
This is a requirement we encounter on practically every project. And at first glance, it sounds reasonable. The problem is that "intuitive" is perhaps the most subjective word in the entire dictionary.
What is intuitive for a twenty-five-year-old designer who spends eight hours a day on a Mac is not intuitive for a fifty-year-old accountant who uses Excel 2010 and Internet Explorer. And both groups are legitimate users.
We had a client who insisted that navigation must be "intuitive." We designed a hamburger menu, which is the standard on mobile devices today. The client said: "But my customers are older, they won't know that those three lines are a menu." He was right.
We ended up running usability testing with five real customers. Two out of five genuinely did not know what the hamburger icon meant. We added the word "Menu" next to the icon and navigation success jumped to 100%.
Lesson learned: "Intuitive" without a defined target audience is an empty word. Always ask: "Intuitive for whom?" And if you are not sure, run a user test. Five people and two hours will save you months of arguments.
"Can You Make the Logo Bigger?"
The classic of all classics. If there were a hall of fame for client requests, "make the logo bigger" would have its own wing.
We once designed a clean, minimalist website. The client's logo was 200x60 pixels in the header. At the first review: "Can you make the logo a little bigger?" We scaled it to 250x75. "A bit more." 300x90. "Hmm, just a touch more." 400x120.
At one point, the logo spanned the full width of the header. Navigation moved below it. On mobile, the logo was larger than the page content. The website looked like a business card from 2003.
Naturally, we stopped and opened a dialogue. It turned out the client had a new logo he was proud of and simply wanted to show it to the world. We solved it with a dedicated "About Us" page featuring a large logo and brand story. The header stayed clean.
Lesson learned: Behind every "make the logo bigger" hides a real need. Sometimes it is brand pride, sometimes fear that customers will not recognize the company. Find the real reason and offer a better solution.
"I Want It Like Apple's Website — My Budget Is $2,000"
Apple.com is the result of hundreds of designers, developers, photographers, and copywriters working with a budget in the millions. When a client says "I want it like Apple," they obviously do not mean an exact copy. They mean the feeling — clean design, beautiful photography, smooth animations.
But even that "feeling" costs money. Professional product photography? Thousands. Custom animations? More thousands. Apple-level copywriting? Let us not even go there.
We once honestly told a client: "For two thousand dollars, we can build you a clean, modern website. It won't be Apple, but it will be professional." The client appreciated the honesty and ended up liking the result more than if we had delivered a cheap Apple imitation that looked like a knockoff from a flea market.
Lesson learned: Instead of blindly agreeing to an unrealistic request, be honest. Show what is realistically achievable within the budget and propose alternatives. Clients appreciate honesty more than you might think.
- ✗Subjective instructions without examples ("make it pop")
- ✗Approvals without actually reviewing the work
- ✗Unlimited revisions without clear milestones
- ✗Delegating approvals to uninvolved parties
- ✗Comparing to Apple on a fraction of the budget
- ✓Visual references instead of vague descriptions
- ✓Regular demos and prototypes
- ✓Formal approval process with sign-offs
- ✓Shared glossary of terms with the client
- ✓Specific questions instead of assumptions
"Just a Small Change"
The three most dangerous words in software development. Every experienced developer instinctively flinches before a "just a small change."
"Can we add just a small change — instead of one address, the user could have multiple addresses?" That means: a new database table, modifications to every form, changes to order logic, invoice adjustments, API updates, admin panel changes. A "small change" worth two weeks of work.
Or our favorite: "Just add social login." Just. Facebook, Google, Apple, and maybe LinkedIn. Four different OAuth APIs, four different response formats, conflict resolution with existing accounts, testing across devices, GDPR compliance. "Just."
The most entertaining case? A client approved the wireframes. Approved the design. Approved the prototype. And at the final presentation said: "This is not at all what I had in mind." After three rounds of approvals.
It turned out his assistant had approved the wireframes. He glanced at the design on his phone in a taxi and said "looks fine." And he "clicked through" the prototype "but didn't really look at it." Three months of work and we were back to square one.
Lesson learned: The approval process must be formal and clear. The person approving must actually see and understand what they are approving. And "signed off" means "signed off" — not "yeah sure, I'll look at it later."
At the very start of a project, agree on clear rules with the client: who approves, how many revisions are included, and how requirements are communicated (ideally visual references, not words). Investing in setting up communication upfront saves dozens of hours of misunderstandings later.
How to Avoid Translations Nobody Wanted
After years of trial and error, we developed a system that works:
- Visual references instead of words — "Send me three websites you like" is better than an hour of explanation.
- Prototypes early and often — an interactive prototype says more than a hundred wireframes.
- A glossary of terms — when we say "responsive," we mean specifically this. When you say "intuitive," what exactly do you mean?
- Signed approvals — every phase has a clear milestone and formal sign-off.
- Questions, questions, questions — it is better to ask ten times and build once than guess and rebuild three times.
Communication between clients and developers will always be a challenge. But with a little patience, a heap of visual examples, and a clear process, even the most abstract requirement can be translated into working code.
And if the client says "make it pop" — show them three options and let them choose. You will save yourself a disco on a law firm's website.
