Low fidelity in UI development: is it incomplete annotations or incorrect slice exports?

The frequent "low fidelity" in the UI design-to-development phase is mostly not a matter of aesthetic disagreement but incomplete handoff information. According to 2026 project handoff practices, the design file itself is not a construction drawing; only when annotations and slices are complete can developers obtain accurate dimensions, spacing, color values, and states. In other words, define the handoff criteria first before discussing visual optimization.

Why do developers always say they can't reproduce it? First distinguish annotations from slices

A developer's "can't reproduce it" can correspond to completely different reasons. Annotation issues typically manifest as: spacing differs from the developer's calculation, font size and line height not provided, color values written as "dark gray"; slice issues often include: blurry icons, incorrect transparent areas, missing assets at multiple scales, and Chinese naming. The diagnosis method is simple: first check whether the annotations cover every interactive element in the interface, then check whether the slices are clear and usable at the required scales.

Common pitfalls include: annotating only dimensions without states; exporting only 1x slices; using PNG instead of vector icons; and slicing the entire design into one large image. These practices will amplify problems across various platforms in 2026, especially in cross-platform scenarios where developers need configurable atomic assets, not a single bitmap. So instead of dwelling on whether the developer is careful, make the deliverables something they can efficiently verify.

What exactly should be annotated? Use the "three-step annotation verification method" to check everything at once

To prevent annotations from becoming a flood of markers, I use the "three-step annotation verification method" to control the scope. After completing the three steps, the information developers need to check is basically complete.

The three steps follow the order of "layout → text & color → states", which corresponds to the sequence developers follow when looking up information while coding. Because the essence of annotations is to let developers self-verify before implementation, not to design for them.

1. Verify the layout skeleton: Confirm spacing, alignment, and grid baseline for each section. Provide key spacing based on an 8px or 4px grid; you don't need to annotate every spacing, but mark exceptions that don't follow the baseline.
2. Verify text and colors: Provide font size, line height, weight, and color value for each text level; use HEX or RGBA for colors, not descriptions like "dark gray". Also give values for background, border, and shadow colors.
3. Verify states and edge cases: Include default/focus/disabled for input fields, hover/pressed for buttons, list load more, and layout behavior for maximum and minimum text lengths. This step is most easily missed and has the greatest impact on development fidelity.

Note that step 3 sometimes requires interaction notes or reference mockups, but annotations only need to provide the visual result; there's no need to include the full interaction flow, otherwise it becomes overloaded. After this verification method is completed, developers should be able to describe the size, color, and state of each element based solely on annotations, without looking at the original design. If developers still have to ask "what is this spacing?", the annotations are not yet adequate.

How should slices be exported so they aren't wasted? Size, format, and naming cannot be arbitrary

The core of slice export is not "exporting an image", but providing developers with usable assets on the target platform. Based on common cross-platform project experience, iOS typically requires @2x and @3x, Android groups by density, and Web prefers SVG, with 2x PNG as a secondary option.

• iOS: Provide @2x and @3x; prefer SVG for icons (supported in iOS 13+), and export bitmaps at 2x and 3x of design size.
• Android: Provide by density (mdpi/hdpi/xhdpi/xxhdpi, etc.), but for daily projects you can start with xxhdpi (i.e., 3x) and scale, or use VectorDrawable.
• Web: Prefer SVG to avoid blur; for image slices, provide 1x and 2x sets. A common practice is 1x and 2x, and add 3x if compatibility is a concern.

Common pitfalls include: slices containing transparent padding causing alignment issues; icons not sliced to the actual visible area; Chinese or versioned naming; and exporting a single size for an icon that appears at different sizes across screens. According to common collaboration habits in 2026, naming should follow the English lowercase format "module_component_state@2x", e.g., "nav_home_active@2x.png".

How to judge slice quality? Place the slice over the design, set opacity to 50%, and check if edges align; then test in a code environment to check clarity at different scales. Doing this basically eliminates repeated rework. If you provide a naming example table at the start, it saves development communication cost. In real projects, checking the slice size alone can filter out half of the fidelity issues.

Experience and boundaries at handoff: what counts as qualified?

In project handoffs, the typical budget is within 100,000 (experience range), and the development cycle is two to three weeks (experience range). Clients often insist on "design files only, no annotations", resulting in developers doing things their own way and most spacing being wrong during review. Later, we would review the annotation checklist with the development lead before exporting slices, confirming key spacing and states are complete. This usually controls rework to within one round (experience range). Conversely, especially when a page has more than a dozen custom controls, developers can only guess, and revisions are basically unavoidable.

Complete annotations and slices are not required for every project. For quick prototypes, user test scripts, or one-time landing pages, you can annotate only key pages and save time for visual polish. But for products that require long-term iteration, especially those involving multiple platforms (iOS/Android/Web), failing to establish a delivery checklist will significantly increase maintenance costs later. So the criteria is: as long as developers need to build from the design, annotations and slices should cover at least the main pages and all interactive states. If the project is very small, say two or three pages, you can annotate only the homepage and main flow pages; if there are only static display pages, you can even just use an online design handoff tool for developers to pick colors themselves, without extra slices.

Common Questions

Even if the design annotations are very detailed, developers still do it their own way. What to do?

Align on the delivery standard with developers before starting. Write a brief agreement covering the annotation checklist and slice naming. If necessary, use a design annotation tool so developers can pick colors and measure dimensions themselves, which avoids most cases of "not reading annotations".

Is it better to export slices as PNG or SVG?

Prefer SVG for icons and graphics—vector formats are sharp and lightweight. Use 2x PNG for complex gradients or photographic content. In 2026, mainstream browsers and systems have good SVG support, so there's no need to sacrifice clarity for compatibility.

Developers say "I can draw icons with CSS", do we still need to export slices?

If the icon geometry is simple and the team is familiar with SVG, you don't need to export slices. But for complex icons or cross-platform projects, it's recommended to still provide an SVG asset for consistent reference, avoiding inconsistent rendering from different developers' CSS.

Should annotations include interaction notes?

Annotations should only provide visual results; interaction logic should be supplemented by separate notes or prototypes. Mixing interaction notes into annotations distracts developers from finding dimensions and can cause key states to be missed.

For small projects with only two or three pages, is complete annotation necessary?

No, you don't need the full set. Clearly annotate pages and components that involve interaction; for static pages, just provide color values and overall spacing. Prepare slices based on actual content, and the key is not to miss button and input field states.

When moving from design to development, first verify annotations using the three-step "layout → text & color → states" check, then export slices according to platform requirements and inspect edges. If budget is limited or timelines are tight, prioritize annotating interactive pages and simplify others. The above is an experience range; the specific details should follow the project's actual agreement.