Your talent will only take you so far—your ability to collaborate is what will make or break you.
The lone-wolf designer mentality
Once upon a time, I thought I was the shit. As a freelancer, I was the alpha and omega of every project.
The king of Figma. The sultan of wireframes. The deity of drop shadows.
Whatever I said went. After all, I was the “creative expert,” and my clients? Well, they just paid the bills.
Except I was a total asshole.
It took me years to realize that design isn’t just about making pretty things—it’s about collaboration. And if you’re out there thinking, “I’m a great designer, why do I need to care about teamwork?”, then my friend, this article is for you.
Taking feedback without losing your mind
I used to take feedback the way a cat takes a bath — violently and with extreme resistance. The mere suggestion that my masterpiece needed a revision was, in my mind, an act of war.
Clients didn’t understand design. Developers didn’t understand creativity. And my teammates? Clearly blind.
Then I joined a team.
Instead of feeling attacked, I started realizing that not all feedback is an insult. Shocking, I know. In fact, most of the time, my teammates were actually helping me create better work.
The more I leaned into it, the more I realized that good collaboration wasn’t about proving I was right but about getting the best result possible.
At first, I took feedback like a personal attack—like someone had just insulted my entire bloodline. But the truth is, feedback isn’t an ambush; it’s a tool.
Early on, I resisted feedback like it was an unpaid invoice. I’d roll my eyes, argue, and try to justify why my design was actually perfect the way it was. But over time, I realized that pushing back on every critique wasn’t making my work better; it was just making me an insufferable pain in the ass to work with.
Once I started actively listening—asking why feedback was given instead of immediately going on the defensive—I saw massive improvements in my designs. More importantly, I became someone that people actually wanted to work with.
The magic trick? Removing my ego from the equation and realizing that feedback isn’t about me; it’s about making the final product the best it can be.
Thinking clients and developers are your enemies
As a freelancer, I once held the belief that my clients were incompetent annoyances who solely existed to undermine my flawless designs. I believed developers were code monkeys who only spoke in error messages.
Spoiler: I was an idiot.
The reality is, clients and developers want the same thing you do, a successful project. The problem? Everyone sees the goal from a different perspective.
Clients care about business needs. Developers care about feasibility. Designers care about usability and aesthetics. And the key to all of it?
Communication.
One of my biggest wake-up calls was realizing that developers weren’t pushing back just to be difficult; they were trying to keep things functional and feasible.
I also learned that my clients weren’t unreasonable; I was just terrible at explaining why certain design decisions mattered.For the longest time, I treated clients and developers like they were just annoying roadblocks between me and my “perfect” design.
Clients always wanted too many revisions, and developers just kept telling me things weren’t possible. In my mind, they were the problem. But in reality? The problem was me.
The biggest shift happened when I stopped seeing them as obstacles and started treating them as teammates. When I actually took the time to explain my reasoning behind a design decision, clients were much more receptive.
Instead of demanding changes for no reason, they started asking questions, trying to understand the process. And developers? Once I started looping them in early and actually listening to their concerns, we started working with each other instead of against each other.
Collaboration isn’t just some corporate buzzword; it’s the difference between a project that flows smoothly and one that turns into a frustrating mess. The sooner I accepted that everyone has their own expertise and that I could learn from them, the easier my job became.
Dropping design files like they’re grenades
Ever sent a Figma file with zero explanation? Or worse, just tossed over a PSD and ghosted? Yeah, I was guilty of that too. It turns out, that’s not how teamwork works.
I used to think my designs were so clear that they didn’t need further explanation. Developers would magically understand my vision, and clients would simply nod in agreement.
Reality check: They did not.
Without proper documentation, handoff notes, and walkthroughs, my projects turned into flaming train wrecks. Developers got frustrated. Clients felt lost. And I looked like an unprofessional mess.
One of the biggest mistakes I made early on was assuming that my designs spoke for themselves. I would send over a Figma file without any context or walkthrough, and then wonder why the developers appeared to be about to give up.
It turns out, even the most beautifully structured design needs explanation. Developers aren’t mind readers. They don’t automatically know why a certain button has to be a certain shape or why an interaction works a specific way. That’s on you to communicate.
Now, before I hand off any design, I make sure I’ve annotated key elements, recorded a quick walkthrough, or even scheduled a short meeting to walk through the logic behind my decisions.
Ignoring business goals (and designing for Dribbble
Ah, Dribbble — the land of gradient heaven and pixel-perfect perfection.
If I could go back and slap my younger self for designing projects just to look cool instead of solving real problems, I absolutely would.
I used to prioritize aesthetics over function.
If a design looked good, that was enough. But when I transitioned to product management, I realized how stupid that mindset was.
Design isn’t just about making things beautiful — it’s about making things work.
It’s about hitting business goals, ensuring usability, and making decisions based on data, not vibes.
Early in my career, I used to think that if a design looked stunning, that was enough. I’d pour hours into making something visually impressive—bold gradients, intricate animations, sleek typography—only to have it completely miss the mark when it came to functionality.
It took me a while to realize that a good design isn’t just about looking good; it’s about working well and serving a clear purpose.
When I transitioned into product management, I saw firsthand how much design decisions impact business goals.
A button that looks gorgeous but confuses users? Useless.
A layout that wins Dribbble awards but tanks conversions? A waste of time.
I started approaching design differently—not just as an art form but as a problem-solving tool.
The best designs don’t just exist for other designers to admire; they solve real user problems. They make things easier, clearer, and more effective.
Once I shifted my focus from “Does this look cool?” to “Does this help the user?”, my work got a hell of a lot better.
Expecting developers to “just make it work”
I used to hand over my designs like, “Here, build this masterpiece. No questions.” And then I’d be shocked—shocked!—when developers pushed back.
Turns out, developers aren’t just human versions of ChatGPT that magically transform designs into code. They have technical limitations, platform constraints, and scalability concerns.
My designs weren’t impossible, but I made their jobs infinitely harder by not involving them early on.
Once I started inviting developers into the early design phases, everything changed. We worked through technical limitations together, found better solutions, and—most importantly—had fewer fights.
Soft skills matter more than hard skills
You can be the best damn designer in the world, but if you’re impossible to work with, nobody will care.
The older I get, the more I realize that soft skills—communication, collaboration, and adaptability—are way more important than being a Figma wizard.
One of the best pieces of advice I ever got was:
Always give people the benefit of the doubt.
When someone disagrees with you, it’s not always because they’re an idiot (even if it feels that way). By asking “why” and truly listening, you open up real conversations and actually get better solutions.
You can be the most talented designer in the world, but if you’re impossible to work with, nobody will care. Trust me, I learned this the hard way.
Early in my career, I thought my designs were the most important thing in the world. I believed that my talent alone should be enough to carry me, and I didn’t see why I needed to put effort into communication or teamwork.
If people didn’t get my vision, that was their problem, not mine. Unsurprisingly, this made me pretty unbearable to work with.
The reality?
Being a great designer isn’t just about pushing pixels — it’s about working with people.
Good communication, patience, and the ability to collaborate will get you further than any flashy portfolio ever will. I had to learn how to listen, take feedback without rolling my eyes, and make sure that the people I worked with felt valued.
Because at the end of the day, no one wants to work with someone who thinks they’re the smartest person in the room.
Final thoughts: Being a great designer means being a great temmate
If I could go back and give my younger self advice, it would be this: Your talent will only take you so far — your ability to collaborate is what will make or break you.
Good design isn’t created in isolation. It’s built through teamwork, feedback, and a shared understanding of goals. The sooner you embrace that, the better your career (and sanity) will be.
So if you’ve ever wondered why your designs get pushback, why your devs sigh when you send them files, or why clients insist on revisions, you might not be a bad designer. But you just might be a terrible teammate.
And luckily, that’s something you can fix.
Now go be the designer everyone actually wants to work with. ✌️
