Ask them to estimate a new checkout screen, and the conversation gets messy much faster. What happens on a phone? How should validation work? What does the user see while the payment is processing? What if the design changes after someone tries the working version? Even when you plan to modernize your web interface rather than build one from scratch, the visible design tells developers only part of what they need to know.
This does not mean frontend development is harder than backend development. A distributed backend or data pipeline can contain far more technical risk than a typical interface. The difference is that interface work carries uncertainty that is difficult to see during project scoping.
That is why frontend estimation based mainly on screen counts tends to disappoint.
One Figma Screen Can Turn Into Six UI States
Take a simple account form. The design shows a few fields and a Save button.
The developer still needs to handle the form before anything has been entered, invalid input, a request in progress, a successful update, a failed request, and possibly existing data loaded from the server. Fields may become available only after another option is selected. The Save button may need to be disabled under certain conditions. Error messages can change the layout.
Those states are part of the feature even if the design shows only the happy path.
Tools such as Figma make it easy to document variants and interaction flows, but teams do not always design every state before asking engineering for an estimate. The estimate covers the screen everyone can see, while development covers the states users can actually encounter.
The Existing Codebase Matters More Than the Screenshot
Suppose two companies want the same settings panel. Same fields. Same interactions. Nearly identical design.
In the first application, the team already has reusable React components for forms, buttons, dialogs, notifications, and validation. Storybook documents how those components behave, and the design system matches what developers use in production. The new panel can reuse most of that foundation.
The second application has three button implementations, old CSS mixed with a newer styling system, several form libraries, and shared components that behave differently depending on where they are rendered.
Those are not remotely equivalent tasks.
This is why an experienced developer will often hesitate to give a firm estimate for changes to an unfamiliar frontend. The uncertainty is not about drawing the interface. It is about discovering what sits underneath it.
There is a tradeoff here. Investigating the codebase before estimation costs time. Skipping that work produces a faster estimate, but one with a much larger margin of error. For established products, a short technical review is often cheaper than discovering those constraints halfway through development. SysGears would rather spend a few days in an unfamiliar repository than quote against a screenshot, which is slower to hear and more accurate to plan against.
“Make It Feel Cleaner” Is Not an Acceptance Criterion
Backend requirements can often be tested against a clear result. Send this input and expect that output. Interface feedback is frequently less precise.
All three comments can be legitimate. None tells a developer exactly how much work is required.
Static designs do not solve the problem. A navigation pattern may look reasonable in Figma and feel awkward once people click through it repeatedly. A dashboard can look balanced with placeholder content and fall apart when production data arrives.
That uncertainty affects estimates because approval does not always end when the design is handed to engineering. Part of the design process effectively continues inside the working product. Teams can reduce that with prototypes and clearer acceptance criteria, but they cannot eliminate it. Users sometimes need to interact with software before they know what they dislike about it.
UI Iteration Is Cheap Until It Starts Touching Everything Else
Moving a button really can take five minutes.
It can also require a layout adjustment at several breakpoints, changes to a shared component, updated visual regression snapshots, and another QA pass. The request itself does not tell you which version you are dealing with.
One revision rarely damages a schedule. The trouble starts when UI iteration becomes continuous. A product manager reviews the implemented screen and changes the navigation. Marketing needs another content block. A stakeholder then asks for a new action that requires another API call. Each request sounds small because people judge it by the visible change, not the code and testing behind it.
At that point, the original estimate is being used to measure a different feature.
There is no engineering technique that fixes uncontrolled scope changes. Teams need a clear point at which a design is considered ready for implementation and a clear way to handle later requests. On SysGears projects that line is drawn before implementation starts, not because revisions are unwelcome but because an estimate stops meaning anything once it is measuring a different feature. Otherwise, developers either absorb the extra work or development timelines start slipping with no obvious single cause.
Responsive Design Is About Behavior, Not Shrinking the Desktop Version
A desktop dashboard has room for a sidebar, a wide table, filters, charts, and several actions. A phone does not.
Developers therefore have to make decisions. Does the sidebar become a drawer? Which table columns remain visible? Do filters move into another panel? What happens to an action that previously appeared on hover? CSS frameworks like Tailwind CSS and Bootstrap make responsive styling faster, but they do not answer those questions. Media queries can change a layout. They cannot decide which information matters most on a smaller screen.
Content creates another set of problems. A component tested with “John Smith” may behave differently when a customer name is 40 characters long. German localization routinely needs more horizontal space than equivalent English text. User-uploaded images rarely arrive in the convenient dimensions used in a mockup.
“Make it responsive” is still too vague for reliable project scoping.
Browser Support Can Quietly Expand the Testing Budget
Chrome held roughly two-thirds of the global browser market in 2025, according to StatCounter, but production interfaces rarely get to assume every user runs the same browser on the same operating system. Safari matters heavily on Apple devices.
Mobile keyboards can resize the viewport. Autofill can alter form behavior. Touch input exposes interactions that mouse-based testing misses. An internal dashboard used on company-issued Chrome laptops has a much narrower compatibility problem than an ecommerce site serving customers across iOS, Android, Windows, and macOS. Giving both projects the same per-screen estimate ignores a large chunk of the work.
Accessibility Work Often Exists Outside the Mockup
Look at a screenshot of a custom dropdown, and you cannot tell whether it works with a keyboard, whether a screen reader can announce its state, or whether focus moves correctly when it opens.
The Web Content Accessibility Guidelines, maintained by the W3C, cover keyboard access, text alternatives, contrast, and focus behavior. Native HTML elements often provide useful accessibility behavior out of the box; custom widgets give designers more freedom but require considerably more engineering and testing.
Problems arise when accessibility appears for the first time during final QA. Fixing a color contrast issue may be quick. Reworking the semantics and keyboard behavior of a custom component may not be. A credible estimate needs to know what standard the product is expected to meet.
Good Frontend Estimates Put a Price on the Unknowns
There is no formula where one screen equals a fixed number of engineering hours. A five-screen workflow built from an established design system, with approved interactions and a narrow browser matrix, can be relatively predictable. Two highly interactive screens in an old application may contain far more risk.
Better frontend estimation starts by asking what is actually known. Are the designs final or exploratory? Are empty and error states defined? Which components already exist? What browsers matter? Who approves UI changes once development starts?
Early in a project, that may mean giving a range instead of a precise number. A range is less satisfying when someone wants a budget immediately, but false precision does not make planning safer. It is why SysGears will give a range early and narrow it later rather than name a figure it would have to renegotiate. As developers inspect the codebase and designers resolve open behavior, the estimate can narrow.
A useful frontend estimate accounts for that reality instead of pretending the approved screenshot is the finished specification.
