Empty, loading, error, denied
Every list has a first-visit state and a slow-network state. Every form has a rejected-input state. Naming these in the design phase keeps them from being improvised in code.
Interface and data, one product
UX/UI Design and Backend Integration
A screen that looks finished in a design file can still fail the moment it meets a real API response. Here is how interface design and backend work connect, and what to settle before a build starts.
Scope of this page
Where interface decisions and data decisions meet
Interface design and backend work are usually described as separate phases, but they meet in the same product and the same user moment. A booking screen, a claims form, an order tracker: each one is a conversation between what the visitor sees and what a server returns. When the two are planned apart, the mismatch surfaces at integration time, which is the most expensive place to find it.
Settle before the build
- Core flows and their decision order
- Who owns each API contract
- Role model and permission states
- Third-party accounts and owners
What UX/UI design covers
More than visual styling
UX/UI design spans the structure of a flow, the order of decisions a user makes, the wording on buttons, and the states a screen can be in. A well-designed booking flow decides what happens when a slot is taken between the moment it is displayed and the moment it is confirmed. That is a design decision, and it has backend consequences.
Studios that separate design from logic tend to produce interfaces that need rework once real data arrives. The visible screen is only the top layer of a set of assumptions about loading, failure, and permission, and every one of those assumptions belongs to someone.
How digital products get builtButton labels carry the decision
Confirm, submit, request, cancel — each label promises a different outcome. Changing the wording can change what the backend must record, so it belongs in the same conversation as the data model.
Why design alone breaks
Invisible in a prototype, obvious in production
If a designer assumes a list loads instantly, the interface will have no loading state. If they assume a payment always succeeds, there will be no failure path. These gaps are invisible in a prototype and obvious in production.
The practical fix is early involvement: whoever owns the API should review wireframes, and designers should see real response shapes, including error responses, before the interface is finalised. It adds a week to design and saves considerably more in rework.
-
Design phase
API owner reviews wireframes
Before flows freeze -
Design phase
Designers see real response shapes
Errors included -
Build phase
Front end and backend run in parallel
Against a mock first -
Integration
Seams tested, not just screens
Slow and partial responses
API contracts
The document that keeps both sides honest
An API contract describes what a request returns, including the fields, the data types, and the error cases. It is not glamorous, but it is the document that lets front-end and backend work proceed in parallel without constant renegotiation. When the contract is agreed early, designers can build accurate states and developers can test against a mock.
When it is not, both sides discover the mismatch at integration time. In custom software development this is the single most common cause of a launch slipping a week, because the correction touches layout, validation and the data model at once.
An API contract should state
- Endpoints and methods
- Request and response fields with types
- Error codes and their meanings
- Authentication method
- Rate limits, if any
- Behaviour on partial failure
Roles change the interface
Admin, staff and customer views diverge early, not at launch.
Authentication and permission states
Most business products have more than one user type
An admin sees different controls from a staff member, and a customer sees less again. These role differences are not just a backend concern; they change the interface. A screen designed for one role will need variants, and a permission-denied state is part of the product, not an edge case.
Deciding the role model during discovery prevents a redesign later, when the interface has already been built around a single user type. It is cheaper to sketch three variants on paper than to retrofit a permission layer into a finished layout.
Third-party services
Scope document
Payments
Messaging and identity
Each integration arrives with its own limits and timelines
Singapore products frequently integrate with local and regional services: payment providers, SMS gateways, mapping APIs, and government identity systems. Each comes with its own rate limits, sandbox behaviour, and approval timelines. A design that assumes instant SMS delivery will look broken during a gateway delay.
The integration list belongs in writing
Name every external service, note who owns each account, and record the approval step that has to happen before anything can be tested live. A vendor cannot apply for a merchant account on your behalf, so that task needs an owner on your side with a realistic lead time attached.
Sandbox behaviour also differs from production. Some gateways return success in test mode for cases that fail in live traffic, which is why the go-live checklist should include one real transaction or message per service rather than trusting the sandbox result.
Failure paths are the design
A declined card, a pending transfer and a duplicate submission all need a screen. If the design only shows the successful receipt, the fallback gets written without a specification.
Delays are normal, not errors
One-time codes and verification steps can take longer than a prototype implies. A resend option and a clear waiting state keep a slow gateway from reading as a broken product.
Testing the seam
Integration testing is not the same as screen testing
Integration testing checks the join between interface and backend, which is where most defects appear. That means testing slow responses, timeouts, partial failures, and duplicate submissions, not just the happy path. It also means testing with realistic data volumes; a list that works with twenty records may behave differently with twenty thousand.
Purrweb's 2026 Singapore roundup highlights Flutter, React Native, UI/UX, and backend as connected parts of full-cycle delivery, which reflects how often these seams decide project outcomes.
Throttle the connection and confirm the loading state still tells the visitor what is happening.
Decide how long the product waits before offering a retry, and what the visitor sees if they walk away.
When one call succeeds and the next fails, the interface has to show a consistent picture rather than a half-saved record.
Two taps on a confirm button should produce one record. That is a design rule as much as a backend one.
Test with the row counts you expect in a year, not the sample set from week one. Pagination, filtering and export all change behaviour at scale, and the fix is usually cheaper in the schema than in the screen.
Handover between design and engineering
Documentation
Components
After launch
What to ask before a build starts
The handover from design to build is a common friction point. Specifications that live only in a design tool can be ambiguous about spacing, interaction, and state changes. Teams that maintain a shared component library reduce this friction because both sides work from the same building blocks. It is worth asking a vendor how they document handover — the answer usually reveals how many projects they have shipped with more than one designer and more than one developer.
How is handover written down?
Ask to see a real specification from a past project: spacing, interaction notes, and state behaviour in one place, not scattered across comments in a design file.
Is there a shared component library?
When design and engineering work from the same building blocks, small changes stop turning into one-off exceptions in code.
Who owns the interface in month six?
A release is not the end of the interface. Confirm who handles small changes, and how those changes reach production without a full re-build.
Frequently asked
Sequencing questions, answered plainly
Two questions come up in almost every scoping conversation about interface work and backend integration. If yours is not here, the contact page is the right place to put it.
- Should UX/UI design finish before backend work starts?
- No, and that sequencing usually causes problems. Structural design and API contract work can run in parallel once the core flows are agreed. Visual design can continue while backend endpoints are built against mocks. What should not happen is freezing the interface before the response shapes are known.
- What should be in an API contract?
- Endpoints, request and response fields with data types, error codes and their meanings, authentication method, and rate limits if any. It should also state what happens on partial failure. If the contract does not cover error cases, the interface will improvise them later.
- How early should a backend developer see the wireframes?
- As soon as the core flows are drawn, before visual polish begins. Their review usually surfaces data the design assumed was available, or a permission rule the screen never accounted for. Both are cheap to fix at wireframe stage and costly once the layout is built.
- Who tests the states nobody designed?
- Someone has to, and the answer should be named in the plan. In practice this is a joint responsibility: the designer writes the intended behaviour, the developer confirms what the API can actually return, and the test pass checks the two against each other before release.
Where to continue
Keep reading, or bring your own list of questions
If the interface and the data model are being planned together, most of the risk in this chapter is already managed. The next useful steps are comparing how a build is delivered, understanding what happens after launch, and asking about your specific screens.
Ask a design and integration question
Send your screen list and the services you plan to connect, and we will come back with the questions worth answering before the build starts. ViewSynapse Digital answers Monday to Friday, 9:00 AM – 6:00 PM.
- [email protected]
- Phone
- +65 6218 1116