At Framna, I Drove The Shift To A Uniform Web Design Workflow

Flow efficiency is the share of total project time spent on productive work versus waiting. Higher flow efficiency reduces idle time, shortens lead times, and smooths delivery.

Work / Work + Waiting * 100% = Flow Efficiency

For Framna, this matters commercially because we are in the business of selling hours. Waiting between handoffs is often non‑billable time that erodes profitability. Reducing these delays lets us deliver faster, utilise teams better, and increase billable hours without extending timelines.

What may seem like a quick solution today can become a significant technical debt problem tomorrow. Front-end developers frequently create custom components when existing design system components don’t meet their specific requirements.

While it may appear as a quick solution, building custom components often results in long-term losses for the team, users, and organization. Initially, the first 80% of the development process seems swift. It aligns with the design and interactions function correctly. However, the final 20% is where the true engineering work begins.

Accessibility, responsiveness, keyboard interactions, focus management, edge-case handling, cross-browser rendering, and theme support are not merely cosmetic enhancements. They distinguish a component that operates effectively during development from one that performs reliably in real-world scenarios. Constructing a functional and “good enough” component can take up to 10 hours.

• Hardening it for production? At least 5x more effort.
• Making it truly accessible? Conservatively, 10x more effort.
• Maintaining it over years amid constant change? Easily 20x the effort.

The exact numbers may vary, but the pattern remains: the effort grows exponentially. It’s a cost curve we often overlook when we say, “I’ll just build it myself.”

This initiative was off the books, so we had to find ways to make it work while working on other projects. With limited time and resources, we opted for an incremental approach instead of trying to redesign everything at once.

We started small, building the first version of the system and its core components alongside a new client web project that was kicked off around that time. This way, we could test and refine the system in a real-world context from day one.

By working side-by-side with an active project, we quickly uncovered real user needs and technical challenges. These real-world constraints helped us prioritize what mattered most, avoid over-engineering, and adapt the system bit by bit to fit our team’s workflows and client demands.

As designers, we all want to create beautiful, polished work. But here’s the hard truth: even the most stunning mockups don’t mean much if they never make it into production code. It’s all too easy to spend weeks or months perfecting components in Figma, only to have them stuck in a bubble, never fully realized in the final product.

Setting up a design system isn’t just about how it looks—it’s about how it’s built, maintained, and evolves over time. That’s why implementation strategy matters just as much as design quality. You need both to succeed ².

By prioritizing implementation alongside aesthetics, we created a strong foundation that allows us to gradually refine and elevate the visual design over time. This principle ensures our work is both impactful and sustainable, enabling continuous improvement without sacrificing delivery.

Design handoff is often the most stressful phase of the process, quickly creating friction and back‑and‑forth among team members. This friction usually stems from treating handoff as a one‑way transfer rather than a collaborative exchange.

A subtler issue is that designers often create in unconstrained canvas tools, like Figma or Sketch, that don’t fully capture the rules and interactions developers must implement, leaving it to production to resolve the gaps ³. These tools can obscure many important design properties from the designers themselves.

To tackle these challenges and foster more dynamic collaboration, our small two‑person team adopted the “Hot Potato Process”, a method ⁴ popularized by Dan Mall and Brad Frost. Named after the children’s game where an object is passed rapidly and no one holds it for long, this approach replaces traditional handoffs with continuous, bidirectional exchange. Designers and developers refine product ideas together in real time.

The artifact we work on becomes the living specification for the project. Because we interact so regularly, we start speaking the same language when discussing the product. Design informs development, and development informs design, in a seamless, ongoing loop.