Before the handoff: working with designers

The handoff still matters, of course, but it is one moment in a longer conversation. In my experience, that conversation can make a screen easier to build, clearer for users, and easier for the team to maintain.

Start with the shared problem

Before talking about spacing, buttons, or breakpoints, I find it helpful to agree on what the screen is trying to do. What is the user trying to achieve? What does the business need from this flow? Which action matters most, and what might make the experience feel confusing?

Designers, BAs, POs, and frontend developers may answer those questions from different angles. A designer may focus on hierarchy and the feeling of the journey. A BA or PO may hold the business rule or edge case behind it. A frontend developer may see the loading state, a long piece of content, an empty result, or a smaller screen before any code has been written.

• DesignerHierarchy and feelHow the journey should feel, and what people should notice first.
• BA / PORules and intentThe business rule or edge case behind the flow.
• FrontendThe less tidy conditionsLoading, long content, empty results and smaller screens.

Each view adds something the others may miss. Bringing them together early has often given the interface a stronger foundation than treating the design as a finished set of pixels.

Turn the handoff into a conversation

The handoffs that have worked best for me have not been one-way instructions. They left room for questions while the design was still easy to change. As a frontend developer, these are the questions I find myself asking most often:

• What is the primary action on this screen?
• What happens while data is loading, and how does an error appear?
• What should the screen do when there is nothing to show?
• How does the layout change on smaller screens?
• Does a component for this already exist, and how much content does it need to handle?

For me, these questions are part of turning an intended experience into something that can work in the less tidy conditions of a real product.

Technical constraints can belong in the same conversation. Accessibility requirements, performance limits, existing components, and implementation time can all shape a good solution. I have found it easier to share those constraints early, with context and an alternative, rather than as a reason to stop an idea altogether.

Keep the feedback loop open

The conversation can continue after implementation starts. Designers can look at the built screen and notice where the hierarchy or spacing has changed. Frontend developers can bring back edge cases that did not appear in the original flow. BAs and POs can check whether the business intent still holds once the screen meets real data and real rules.

That loop has been valuable in the projects I have worked on. It does not mean everyone agrees immediately. It simply gives the team more context to make a better decision together.

Over time, some of the same questions may begin to repeat: which button is primary, how should a component behave, which spacing value should we use, or does this pattern already exist? For me, those repeated decisions were a useful signal that the team could benefit from a shared language across design and code.

That is where a design system begins. The next post, What is a design system, really?, picks up from there.