It’s 2026. Everyone nodded in requirements review—why are empty states and loading states still being filled in during integration?

Opening conclusion: When requirements review all nodded but empty states and loading states are still being filled in during integration, it is usually not slow frontend execution. The review only confirmed the main path and did not turn exception states, performance budgets, and acceptance criteria into checkable items. In 2026, for multi-platform delivery or interaction-heavy projects, these gaps are often amplified only at the integration stage, and rework costs are noticeably higher than filling them in during review.

Why do reviews “all agree” and still miss states?

In the past, frontend waited for design mockups and then evaluated whether they could be built. After the role upgrade, frontend needs to get involved at the requirements review stage, because many experience problems are not created while coding; they were not defined clearly at the requirement stage. For example, with a “list filtering” requirement, product only writes keyword search, without defining empty state, loading state, error state, and permission state. Frontend discovers halfway through that these need to be added, and changes touch APIs and components.

Quotable judgment: Requirements review is a lower-cost intervention point for experience; once integration starts, the same experience adjustments usually take 2 to 5 times longer, depending on change depth and cross-platform scope. This is not about giving frontend extra authority; it moves late-stage rework risk earlier. If the review table has only main-path screenshots and no state transition conditions, nodding does not mean the experience has been fully defined.

• Review stage: only 10–30 minutes to align on states and performance expectations, with low change cost.
• Development stage: adding interaction states and changing API fields, typical range 0.5–2 person-days.
• Integration stage: frontend and backend fill in boundaries together, experience range 1–3 person-days; cross-platform projects may take longer.
• After launch: compatibility or performance issues involve rollback and hotfix costs that are higher, experience range 3–5 person-days.

A nameable judgment framework: the three cards of requirements review

Based on our project delivery habits, we can divide what needs to be settled in review into three cards. This division is because product, design, and frontend each hold different information; discussing them together easily becomes trying to persuade one another, while claiming them separately is faster. Each card must land as one verifiable sentence, not stop at a feeling.

1. Product card — business goals and priorities: What user problem does this requirement solve, what are the success metrics, and what can be cut. Be careful not to write unverifiable phrases like “improve experience.”
2. Design card — experience paths and state mockups: Are main path, exception path, empty state, loading state, error state, and permission state all covered by mockups? Note that a design mockup is not an interaction spec; frontend needs to ask about state transition conditions.
3. Frontend card — technical constraints and acceptance criteria: performance budget, multi-platform differences, data boundaries, and accessibility baseline. Note that these are constraints, not a technical solution presentation.

The framework needs explanation before and after: the three cards are not process approvals, but information each role must hand over during review. Without the product card, the team goes off track; without the design card, frontend guesses; without the frontend card, no one claims performance and compatibility issues in advance.

What four things should frontend clarify in review?

A frontend experience architect does not do requirements for product, but turns “how experience lands” into verifiable constraints. A common 2026 practice is for frontend to clarify at least four things in review and write them into the requirement attachment or acceptance checklist. Each item needs a judgment standard; do not just say “pay attention to optimization.”

• Performance budget: the experience range for first-screen time to interactive on weak networks; a common target is operable within 3 seconds; LCP is often kept around 2.5 seconds. Adjust by business type: ecommerce and admin dashboards have different standards.
• Multi-platform differences: which interactions must be consistent across H5, mini programs, App, and PC, and which can degrade. The bar is to list the differences and degradation plans, not discover them after launch.
• Data and state boundaries: whether API fields are sufficient, whether frontend needs fallback mocks, and what to show when something goes wrong. Be careful not to push undefined backend fields directly into the development stage.
• Accessibility and SEO baseline: form labels, contrast, focus order, and whether indexable content is served directly as HTML. Check against platform standards or an accessibility checklist.

These constraints do not need to be a long proposal, but they should leave a trace in the review notes. A common situation in 2026 multi-platform projects is that a state H5 can do may not be directly reusable in a mini program, and App back navigation and gestures add another layer. Write them down early, and integration has one less round of back-and-forth.

Comparison: filling gaps during review vs during integration

Different teams have different habits about “when to fill in states.” Based on 2026 project delivery experience, a set of comparisons can help judge. The numbers below are experience ranges, not promises, and depend on project scale, number of platforms, and API stability.

• Filling gaps during review: aligning state mockups and acceptance criteria, typical range 10–30 minutes; changes are mainly in discussion, with little impact on subsequent scheduling.
• Filling states during development: requires changing components and API fields, typical range 0.5–2 person-days; may double for cross-platform work.
• Filling states during integration: frontend and backend sort it out together, typical range 1–3 person-days; longer if permissions or data boundaries are involved.
• Filling states after launch: involves hotfixes, rollbacks, and support feedback, experience range 3–5 person-days, and users have already felt the problem.

The judgment standard is simple: if the past three projects all discovered experience issues only during integration, frontend should speak up first in review; if the requirement itself is not clear yet, have product clarify business goals first, then discuss technical constraints. Who speaks first is not the point; what matters is that states and acceptance criteria have an owner.

Delivery-site experience: lock the core path first in a two-week cycle

Delivery-site experience: In a project with only a two-week cycle and incomplete assets, product wanted to “just build the homepage first.” Our approach was to lock the core path’s placeholder images, skeleton screens, and empty-state plan during review, and write the performance budget as an acceptance item. The result was that the first version could enter integration on time; the tradeoff was that visual details had to wait for the second round, but it avoided a full rework before launch caused by oversized images and missing states. The key constraint here was uncertain asset delivery time; the experience range is 15–30 extra minutes in review for alignment, which can reduce integration rework by 1–2 rounds.

Applicable scenarios and boundaries

The frontend experience architect role upgrade is not mandatory for every team. Suitable scenarios are: multi-platform delivery (at least two of website, H5, App, mini program), complex interactions, performance sensitivity, or clear SEO indexing needs. In these cases, frontend getting involved in review early can reduce rework.

Also state clearly when it is not suitable or unnecessary: a single-page showcase website, long-term stable requirements, or a team with only one or two frontend engineers and no cross-platform tasks—forcing this role can become title inflation. Boundary sentence: If experience issues can mainly be clarified through design mockups, and there are no performance or compatibility complaints after launch, there is no need to add a review step just for a role upgrade.

Frequently asked questions

If requirements review all nodded, whose job is it to fill in empty states during integration?

It is not one side’s responsibility. If empty, loading, and error states were not written as acceptance items during review, product and design need to add state mockups, frontend needs to give the implementation cost, and then everyone prioritizes together.

If a small team has no dedicated experience architect, how can it avoid missing states?

Have a senior frontend engineer double as the checker; during review, focus only on three things: exception states, performance budget, and multi-platform differences; protect the core path first, and do not try to cover every detail at once.

When product says “build it first and optimize later,” how should frontend respond in review?

Write the optimization items as acceptance items that must pass before launch, and mark the minimum bar; otherwise “optimize later” usually never happens, and it is hard to squeeze into integration.

If the performance budget is set in review, what happens when business requirements change later?

Re-evaluate the budget when requirements change, keep a change record, reconfirm state mockups and scheduling, and do not inherit the old criteria by default.

In 2026 multi-platform projects, which states are most easily missed?

Common ones are empty lists, weak-network loading, API errors, no permission, and expired login. Mini programs and Apps also need states after system back, sharing, and opening from a push notification.

Action guidance: In the next requirements review, first have product hand over business goals, design hand over the state card, and frontend hand over the constraint card, then move into scheduling. Applicability boundary: prioritize this when the team has cross-platform or performance-sensitive delivery; for single-page showcase or long-term stable requirement projects, keep only one technical check before development, and do not add a review step.