Start from the materials and how the teams are split. Choose design, a revision, or front-end implementation, then confirm the pages, interaction states and what is handed over.
From the page list, users and sample data, complete the prototype, visual files, component states or development annotations as agreed. When the existing team builds it, align components and the handover format first.
Prepare first: A page list, users, sample data and the target device.
Coordination and handover: Align components, source files and annotation format, and agree design questions and development support.
Review the current process, role permissions, interface fields and operating habits that must stay. Revise one set of search, filter, loading, failure and confirmation states, then check page by page that old and new tasks still correspond. Changes to business or control logic are listed separately.
Prepare first: Authorized screenshots, frequent tasks, interface fields and the problems to improve.
Coordination and handover: Record the original actions and exception states, and check the same task page by page. Other business changes are confirmed separately.
Add front end, interface fitting and device testing for the agreed pages. Whether the back office, 3D models and deployment are included is confirmed item by item. The same roles, samples and actions are used to check the design and the running page.
Prepare first: The design and page scope, interface material, a test environment and the target device.
Coordination and handover: Confirm front-end implementation, interface fitting and device testing. Back office, models and deployment are agreed item by item.
When software is already in use, read theguide to revising old software and host interfacesand check the page baseline, feedback for key actions, and how replacement is phased.
Seeimage and result review on an inspection workbenchandparameters and alarms on an equipment circuitfor how specific states are organized. For business features, continue tocustom software. Screenshots, frequent actions and the target device are enough for a first conversation.
Confirm the modeling and cleanup scope from the objects to show, the materials on hand, and the device that will display them.
3D modeling and cleanup can be agreed by building, equipment or space. Using plans, site photos or existing models, confirm the priority objects, the precision and the target device first. Scene interaction, point binding or business-data linkage is added to the development scope separately.
What is handed over for models and source files, the rights, and how they are checked should be confirmed on their own.
A project with a clear user, page goal, data sample and target device can enter prototype and visual design. If the business scope, data definition or who decides is not confirmed, review the requirements first instead of drawing a full visual.
Scroll the table sideways to see the full comparison.
| Judgment | Typical situation | Suggested action |
|---|---|---|
| Suitable | An executive cockpit, operations monitor, showroom briefing, back office or 3D project already has a page goal, core data and a target screen. | Freeze the first page list, confirm a prototype and one visual reference page, then expand the full pages. |
| Suitable | An old system or reference pages exist, and the information hierarchy, component states, brand and multi-resolution fit need to be unified. | Inventory the current pages, reusable components and operating habits that must stay. |
| Not yet | The only brief is to “make it look more technical,” with no user, indicators, data sample, screen size or person who accepts it. | Start with a requirements interview and a material list, so a direction problem does not become endless revisions. |
| Not yet | The core of the project is process, interfaces, permissions or control logic, but the budget so far is only a visual file. | Complete the product and technical scope first. UI does not replace system analysis, data governance or control-system design. |
List deliverables by page, state and file type. Design source files, front-end code, 3D models and third-party assets are different rights and different work. “Deliver the design” does not cover all of them.
Scroll the table sideways to see the full comparison.
| Delivery category | What can be agreed | Boundary that must be explicit |
|---|---|---|
| Pages and states | Overview, topics, popups, filters, alarms, empty, loading, exception and permission-limited states. | Counted against the page list. A new page or a new business state is not included by default. |
| Rules and assets | Color, type, spacing, components, icons, exports, annotations and interaction notes. | State the source format, export size, and whether editable charts or motion files are included. |
| 3D interface | Model viewport, equipment labels, point overlays, alarm states, camera views and 2D panels. | Model production, lightweighting, engine development and data linkage are not automatic parts of a UI file unless listed. |
| Development handover | Page names, component states, sizes, interaction notes and a record of questions answered together. | Design-only delivery is not front-end code, a deployment package or an interface implementation. |
| Rights record | Source and license notes for type, icons, images, map bases, plugins or assets. | Purchase, renewal, territory and redistribution of third-party assets are set in the contract. |
Split confirmation into four points: requirements and prototype, a visual reference page, the full pages, and handover acceptance. Collect feedback at each point and keep a confirmation record, so an agreed direction is not reopened without a boundary.
Freeze the page goal, information hierarchy, indicator names, key actions and the first page list.
Use one representative page to confirm color, type, charts, density and how the 3D viewport is combined.
Local adjustments follow the agreed rounds. A new page, a process change, a new direction or added motion is recorded for its effect on schedule and cost.
On the agreed resolution and representative devices, check pages, copy and data, component states, overlap, exports and handover material.
A design file needs to be checked against the real business path. See how awastewater-plant digital twin solutionorganizes process and maintenance objects, then the page structure of theintegrated water and energy storage platform, together with thereclaimed-water cold-storage interface guideand thelarge-screen environment checklist. For progress, safety, quality and inspection in a spatial interface, compare thesmart construction BIM page. For passenger flow, routes and emergency dispatch at a scenic site, see thesmart scenic-area operations page. Those solutions and cases explain how an interface is organized. They are not proof of a named customer’s project result.
The answers below also state the boundary among design, development and third-party rights, so a quote can be compared.
Yes. A company can commission only the interface for a data dashboard, a back office or a 3D project, or combine design with front-end development, a software system or a digital twin. Whether a prototype, interaction notes, exports and development support are included is confirmed item by item in the scope table.
Users, the business process, a page list, indicators and sample data, the target resolution, brand rules and a reference direction. For a 3D scene, also CAD, plans, existing models, equipment points or site photos.
Usually the confirmed pages, component and state files, color and type rules, exports or icons, size annotations, interaction notes and a page list. Whether the source is Figma, Sketch, PSD or another format follows the contract and the delivery list.
Whether design source files are handed over, and whether front-end code and 3D models are included, are written separately in the contract. Fonts, icons, images, maps or plugins record their source, the license scope and who renews them. Third-party rights that are not in scope are not transferred by default.
Confirm at three points: prototype, visual direction and full pages, and agree the revision rounds at each point. A local change to confirmed work can stay inside those rounds. A new page, a process change, a new visual direction or a new interaction state is assessed before it is scheduled.
On the agreed resolution and representative devices, check the page list, information hierarchy, copy and data, component states, interaction notes, whether exports are complete, and whether development can build it. A 3D interface also checks the model viewport, overlay overlap, point states and readability in different scenes.
A design-only project is not deployment or long-term operations. A question period, correction of design defects, version archiving and handover of the final source files can be agreed. Server deployment, code warranty, third-party renewal and a later revision are stated separately when development is included.