Let me take you back to when I was a junior designer.
I’d put together a sleek design, create a shiny mockup, and send it off to the developers, feeling pretty damn proud of myself.
Did I include error states? Nope.Interaction details? Not a chance.Empty states? Completely forgot those.
Back then, I thought, “If it looks good, we’re good, right?”
Wrong. So very wrong.
Fast forward to today, and my deliverables are night and day compared to those early mockups. I’ve learned—sometimes the hard way—that design isn’t just about making things look great. It’s about ensuring they actually work in the real world.
As both a product designer and now a product manager, I’ve realized that great deliverables do more than just present a vision—they answer questions, anticipate problems, and make life easier for developers.
Here are five lessons I wish Junior Me had known from the start.
1 — Mockups Are Just the Beginning, Not the Final Product
I used to think that once I delivered a polished mockup, my job was done. That was the deliverable, right?
Wrong.
A mockup without context is like a map with no destination. It might look nice, but it won’t actually get anyone where they need to go.
I learned this lesson the hard way when a developer once asked, “What happens if the user deletes all their data? What does that screen look like?” Cue the awkward silence.
Now, every design I create follows a checklist:
✅ What does this screen look like with no data?
✅ What happens if something goes wrong?
✅ How does the user interact with this element? Every screen needs a backup plan. Because let’s be real—users don’t live in a perfect, happy-path world.
✅ What does this screen look like with no data?
✅ What happens if something goes wrong?
✅ How does the user interact with this element? Every screen needs a backup plan. Because let’s be real—users don’t live in a perfect, happy-path world.
2 — Design for When Things Go Wrong (Because They Will)
Junior Me thought design was all about the perfect, polished experience—the beautiful dashboard, the sleek UI.
But real-world design isn’t just about when things go right. It’s about what happens when they go wrong.
🔴 Error States: What happens when a form isn’t filled out correctly? Users need clear messages guiding them on what went wrong and how to fix it.
🟡 Empty States: What does the interface look like when there’s no data? Instead of a blank screen, provide instructions or prompts to guide users.
🔵 Loading States: How does the system communicate progress? Use spinners, progress bars, or animations to reassure users that something is happening. I once had a client look at my mockup and ask, “But what if there’s no data here?” My response? A blank stare. 😳 That was the last time I forgot to design for these scenarios. Now, I make sure to think through every possible outcome before anyone even asks. Golden Rule: If you’re not designing for the worst-case scenario, you’re not designing for reality.
🔴 Error States: What happens when a form isn’t filled out correctly? Users need clear messages guiding them on what went wrong and how to fix it.
🟡 Empty States: What does the interface look like when there’s no data? Instead of a blank screen, provide instructions or prompts to guide users.
🔵 Loading States: How does the system communicate progress? Use spinners, progress bars, or animations to reassure users that something is happening. I once had a client look at my mockup and ask, “But what if there’s no data here?” My response? A blank stare. 😳 That was the last time I forgot to design for these scenarios. Now, I make sure to think through every possible outcome before anyone even asks. Golden Rule: If you’re not designing for the worst-case scenario, you’re not designing for reality.
3 — Interactions Matter (Even If You’re Not a Developer)
One of the biggest lessons I’ve learned? A static design only tells half the story.
How does a button behave when you hover over it?What kind of animation appears when content loads?How does the user know their action was successful?
I used to think, “That’s the developer’s problem.”
Spoiler: It’s not. It’s mine.
Developers aren’t mind readers. If you don’t specify how an interaction should work, you’re leaving too much up to interpretation. That’s why I now:
✅ Use design systems like Material Design or Ant Design whenever possible.
✅ Provide clear notes and quick prototypes for complex interactions.
✅ Avoid assuming developers will “just figure it out.” Taking the time to define these details makes a huge difference in the final product.
✅ Use design systems like Material Design or Ant Design whenever possible.
✅ Provide clear notes and quick prototypes for complex interactions.
✅ Avoid assuming developers will “just figure it out.” Taking the time to define these details makes a huge difference in the final product.
4 — Developers Are Your Allies, Not Your Adversaries
Let’s be real—Junior Me thought developers were the enemy.
They’d push back on my designs, challenge feasibility, and ask a million questions. In my head, I was the creative genius, and they were the ones trying to ruin my masterpiece.
But here’s what I’ve realized: Developers aren’t there to make your life harder. They’re there to make your designs actually work.
One of the best things I did was start involving developers earlier in the process. Before finalizing a design, I now ask:
💬 “What challenges do you see with this?”
💬 “What might be tricky to implement?” This not only saves time later but also builds trust and makes collaboration smoother. When developers feel like they’re part of the process, the entire team wins.
💬 “What challenges do you see with this?”
💬 “What might be tricky to implement?” This not only saves time later but also builds trust and makes collaboration smoother. When developers feel like they’re part of the process, the entire team wins.
5 — Details Show Respect (For Your Team and the User)
I used to think that adding too many details to a deliverable was overkill. But now, I see it differently.
When you hand off a design that anticipates questions, covers all scenarios, and includes thoughtful annotations, you’re showing respect—for the developers, for the users, and for the project itself.
When I started including detailed notes, responsive breakpoints, and edge cases in my deliverables, something magical happened: My developers stopped chasing me for answers.
And guess what? Users noticed the difference too. A well-thought-out design feels polished, intentional, and trustworthy. It shows that we care about their experience—not just about making something portfolio-worthy.
Final Thoughts
If I could go back and give Junior Me one piece of advice, it would be this: Stop focusing on making things pretty and start focusing on making them complete.
Design isn’t just about the happy path—it’s about the messy, complicated reality of how things actually work.
Great deliverables aren’t just about presenting a vision. They’re about making that vision work in the real world. The more thought you put into them, the better your designs will be.
✅ Anticipate problems.
✅ Provide clear guidance.
✅ Never hand off a design without thinking about what happens when things go wrong. Your developers will thank you.Your users will thank you.And Future You will definitely thank you. ✌️
✅ Anticipate problems.
✅ Provide clear guidance.
✅ Never hand off a design without thinking about what happens when things go wrong. Your developers will thank you.Your users will thank you.And Future You will definitely thank you. ✌️
Thanks for reading!
I’m Leo, a product manager with a passion for storytelling. I write about my journey—past, present, and future—while sharing insights to help others navigate their own career paths.
If my experiences help you along the way, well, that’s just a bonus. 😊