How to Turn a Business Workflow into a Buildable UI Prototype
Start with one real task, not a collection of attractive screens. A buildable UI prototype shows how each role enters, completes and exits that task, including field rules, permissions, error states and device layouts. Hand the editable design files and acceptance examples to developers alongside the screens.
On this page 5 sections
Start with one real task before arranging screens
Ask a business user for a frequent task, such as finding a pending record and submitting it for review. Put its entry point, user role, required inputs, decision rules, system response and completion condition on one task card. These verbs and decisions tell you more about screen structure than a request for “a home page and several lists.”
Record what happens when the user cancels, lacks permission, loses connectivity or sees no data. Navigation and visual styling can follow. If the core task has no clear starting point or return path, a polished mockup can hide the actual work.
Document roles, screens and states together
A clickable prototype should answer what happens after each important action. Build a screen list from the task path; then annotate controls with visibility conditions, authorized roles, validation rules and feedback. Review four connected layers:
Scroll horizontally to view the complete comparison.
| Layer | What the prototype must answer | How to review it |
|---|---|---|
| Task path | How do search, details, editing, submission and return fit together? | Have the intended user complete the actual task. |
| Fields and permissions | Which fields are required, visible or editable, and which role may act? | Compare at least two roles using a sample record. |
| Screen states | What appears during loading, empty results, validation errors, saving, success or an unknown outcome? | Trigger each state instead of checking only the default screen. |
| Target devices | What reflows on desktop, touchscreens or phones, and which actions remain available? | Check the agreed device sizes and input methods. |
A disabled button alone does not explain lack of permission. Developers also need to know who determines access and what feedback the user receives. For web interfaces, WCAG 2.2 provides useful guidance on errors and reflow, while the W3C guidance on status messages covers feedback after an action. Apply the requirements agreed for the project and target device.
What should a development-ready design handoff include?
Organize the handoff around behavior to be implemented, not the number of exported images. Editable source files and screen mockups are only one layer. Business users, designers and developers need to see the same scope:
- Screens and flow: a screen inventory, transitions, return paths and the start and finish conditions for each task.
- Components and states: rules for tables, forms, dialogs, notices, empty states and errors, including copy, icons and feedback.
- Data and permissions: field names, meanings, example values, view and edit rights, and items to confirm with the API owner.
- Adaptation and assets: layouts for target devices, image and icon assets, typography, annotations and editable design files.
- Acceptance examples: the roles, inputs and outcomes used to compare the implementation with the prototype, plus versioned changes.
The scope may cover UI design alone, UI plus frontend implementation, or the full software system. If an existing system's APIs, components or source code are unavailable, a design file alone cannot prove that its frontend can be replaced directly. For existing software, use the existing-interface redesign checklist to assess the current behavior.
Test the prototype with one representative task
Suppose a purchasing manager must review an order with an unusual amount. The prototype should support four steps: find the order in the pending list, inspect the amount and source data, enter a review decision, and confirm the resulting state. If the process permits return or reassignment, test those paths in the same task.
During development review, ask more than whether the screen looks right. Will details from the previous order remain after switching records? Will a second click after a save timeout create a duplicate? Can an unauthorized user open the record directly by URL? Some answers belong in UI specifications and others in API or backend behavior. Assign each responsibility in the handoff.
How can you accept a UI design that can actually be built?
Have the intended user complete the agreed task in the clickable prototype. Record where they stop, misclick or need an explanation. Then have developers check fields, states and device conditions against the same example. Verify that editable files open, components have consistent names, and copy and states include exceptional paths.
Keep design acceptance separate from software acceptance. Design review can confirm the screen and interaction agreement; saved results, permission enforcement and data correctness must be verified after implementation and integration. When APIs are not ready, identify simulated prototype feedback clearly rather than treating a clickable demo as a working system.
Before commissioning design or development, compare the UI design service scope (Chinese) and software development service scope (Chinese). If requirements are still taking shape, use the software requirements checklist to clarify roles, fields and acceptance conditions.