Why Engineers Still Have Questions After Design Handoff
By Onyi N. — Product Marketing Manager
A feature can look ready for engineering once the Jira ticket is written, the Figma file is linked, flows are mapped out, and the designs have been reviewed.
But when the engineer starts building, they have questions the final design doesn't answer. He might wonder whether the interaction is intentional or how it ended up in the mockup. Why did the team choose this flow? What should happen in a case that was not covered in the design? If there’s something the team expects to add later that should affect how this should be built now?
The engineer has the design but not all of the decisions and discussions that explain why the feature looks and works the way it does.
It is easy to miss this because most handoffs transfer the output of the design process: screens, flows, specifications, and tickets, but don’t transfer decisions, assumptions, and conversations that become important when they run into a question the final design does not answer.
In this article, we look at what gets lost between design and engineering, and how Miracle uses Quely to keep that information with the work.
Why Design Handoffs Need More Than the Design File
This gap shows up in how designers and engineers describe handoffs.
In one r/UXDesign discussion, a developer shared that when a designer drops a Figma link into Slack with no explanation, they end up “guessing at hidden things” while trying not to break the intended flow.
The responses in that post show that most people add extra explanation around the design so engineers can understand the decisions and details that are not obvious from the screens alone. One designer said handoffs should include a walkthrough of the Figma file, where the designer and engineer can go through the design together and discuss how it should work. Another said they record walkthrough videos that engineers can return to later instead of having them remember everything from the handoff call or ask the same questions again.
A recent discussion shows the same problem from the designer’s side. The poster had started prototyping in code and was trying to work out what to give developers instead of recreating everything in Figma. Their concern was that handing over the prototype alone could leave out the reasoning behind design decisions, along with edge cases and state changes.
Both examples point to the same issue. The handoff can include the design, the prototype, and even detailed specs, but some of the decisions behind the work still need to be explained separately. That becomes more important once the engineer starts building and runs into a case the design did not cover.
Once implementation starts, engineers often have questions about details or cases that weren’t covered during design. A technical constraint might affect how an interaction can be built, an edge case might come up that the team had not considered, or the engineer may need to decide whether something planned for later should affect how the feature is built now.
In those situations, knowing what the team decided to build may not be enough. The engineer may also need to know why that approach was chosen, what alternatives were considered, and whether there are assumptions or dependencies that should influence how they build it.
That information is not always in the ticket or the design file. It may have come up in a Slack thread, a design review, a conversation with the PM, or somewhere else while the team was working through the feature.
Miracle described a very similar problem in his own design-to-engineering workflow.
Before Quely, he said the information around a feature was spread across different tools. The design was in Figma, the tickets were in Jira, and conversations about the work happened in Slack.
How our Product Designer Keeps the Thinking Around the Work
Miracle ran into this same issue in his own design-to-engineering workflow. The problem was not just that the information existed in different tools, but that the developer had to piece it together to understand the work.
Quely changes where the work and the information around it come together. Every task can have its own Space, where the team can discuss the work, add designs and other supporting material, and schedule any meetings or workshops needed around it. What comes out of those conversations stays in the same Space.
For a design task, that means the developer is not looking at the Figma file in isolation. They can see the design alongside the conversations, estimates, feedback, assumptions, and dependencies that have come up around the work.
That gives the developer more than the current task or design. Miracle said they can understand the intent behind the feature, why the team is building it, what assumptions they are working from, and what has already been discussed about how it should work. Some of that intent, he said, would otherwise have to be passed to developers through a design KT.
Miracle also talks about information that may never make it into the current ticket or design. A designer might already see an opportunity to improve the experience later, even if that idea has not been formally documented as future work.
For him, that still matters to the developer building the feature now. If they know where the experience may go next, they can take that into account when deciding how to build the current version.
That is where his point about thinking in systems comes in. He contrasts this with relying only on comments around the current Figma work, which tend to focus on the feature as it exists now. When the developer can also see the assumptions, dependencies, feedback, and future considerations around the work, they have a wider view of what they are building and where it may need to go.
Miracle also said the team can use Quely’s AI Agent to pull out important information from everything around the work and create tickets from it, making the direction of the work clearer.
For him, this goes beyond design and engineering. His broader point is that when the information around a piece of work is connected to that work, the whole team has a clearer reference point for understanding what the feature is, why it is being built, and what has already been discussed around it.
Conclusion
A design handoff works better when the engineer gets more than the final screens and ticket. They also need enough of the decisions, assumptions, and discussions behind the work to understand how to build it well.
Quely keeps that information connected to the task, so the developer can see not just what the team decided to build, but the thinking that shaped it.
When something unexpected comes up during implementation, the engineer can refer back to the decisions, assumptions, and discussions behind the work instead of having to piece them together later.
See how Quely helps product and engineering teams keep the decisions, discussions, and supporting information around a task connected to the work.