My role: Product Designer, responsible for strategy and end-to-end design
Team: Myself, Product & Design team, Head of Design
Duration: Ongoing
Deliverables: Discovery workshops, design process planning, interface patterns, prototypes, collaborative critiques, documentation system, living design system
When I joined netshow.me: developers working in silos, product stuck in decision loops, and CS buried in tickets about bugs and delays.
There was talent :strong backend, frontend, PMs, and CS. The group was amazing, but no share work or knowledge.
Design was seen as decorative, decisions came top-down, and every change required long meetings. It was a frustrating, inefficient process.
I felt the urgency: ship quickly, but without sacrificing quality. We were failing on both fronts.
During my first week, I had 1-on-1s with devs and CS to understand the real internal pain points.
One dev told me, “Most tickets we ship never get fixed.”
CS and Sales were promising customers improvements that never happened.
I noticed each UI squad used their own visual patterns and surprisingly, there was consistency. Showing how talent was not scarce in the company.
A new Design Manager had just joined and proposed a lean design system in Figma and embraced my plan of culture changes.
My job was to structure the habits, flows, and rituals that would support the Design System and Design team practices.
With this manager, I shared the insights we had gathered before him. I was on the right track just needed help.
We established a weekly Design Guild: seniors and juniors working together to review improvements and update the library in real time.
We also included cross-functional teams. Within two sprints, we already had standardized buttons and error feedbacks, which boosted the team’s confidence.
We also launched a “living documentation” hub inside Figma and the design system. Every dev question like “Why is this like that?”, could be answered by a nearby sticky note or reference. This clarity reduced rework by ~30% and accelerated decisions without sacrificing quality.
Beyond prototyping, we created a shared mural in FigJam showing flows from different squads and real user questions. This became the foundation for internal Design Critiques.
These sessions changed how others saw the design team (once blamed for delays), and made them co-creators. We started receiving richer, more contextual feedback.
I joined every ceremony: PM planning, dev dailies, CS reviews.
When front-end suggested “simplifying the logic,” I shared user feedback showing how those changes would hurt trust. When PMs challenged deadlines, I’d walk them through the journey maps we had created together.
This way of working dissolved silos: instead of “my code” or “my research,” it became “our product.”
From there, we iterated, ran alignment sessions, and started holding weekly mini-discovery workshops where we’d bring up one blocker and leave with a clear action plan.
Instead of waiting for full deployments, we agreed to ship improvements incrementally, with each squad taking care of specific flows (aligned with PM priorities).
Every update was tested by five internal users ( CS, devs, even a pilot customer, etc) before going live.
This constant validation reduced drop-offs, helped devs understand business needs, and gave visibility into the “why” behind design decisions.
The impact wasn’t just metrics. CS stopped receiving basic usability questions. Analysts started using refactored screens in sales demos, saying: “It’s already built by the team, just needs a few tweaks.”
When I heard that, I knew we had done more than improve UX. It was still early, but the cultural shift had started.
A Design System only works if it’s alive . Product and data evolve in small pieces, and live iteration is key.
Most importantly: clarity for the team means clarity for the user.
Let’s build a website that grows your business
Book a free call to get a site that builds trust, attracts leads, and converts clients.