Wireframes, prototypes, research, systems, and tests are separate scopes — pick the card that removes your current risk.
When UX / UI is bought as a discipline — not a buzzword
UX / UI is not one deliverable. Teams stall when they ask an agency to "do UX" without saying whether the blocker is structure (IA), behaviour (flows), evidence (research), consistency (design system), or validation (usability tests).
This discipline page separates those outcomes. Each card below is its own statement of work, timeline, and price — you can buy wireframes without committing to a full visual redesign.
How to pick between wireframes, prototypes, research, systems, and tests
Choose wireframes when stakeholders disagree on page structure or nav. Choose prototypes when you need to validate flows before dev estimates. Choose research when you lack evidence on what users actually need. Choose a design system when multiple squads ship inconsistent UI. Choose usability testing when you have a live or high-fidelity UI and need a ranked fix list.
Still unsure? Book a 30-minute scoping call. We will recommend a single starting leaf — not a bundle — based on your launch date and risk.
What procurement should see in a UX / UI SOW
Each leaf includes: discovery inputs, revision rounds, acceptance criteria, file formats (Figma/FigJam), and accessibility expectations. We do not lump research and build into one vague "UX phase".
NDAs, GDPR documentation, and vendor onboarding are standard for enterprise buys. Mention procurement requirements in the contact form.
Outcomes across the UX / UI cards
Shared goal: reduce rework downstream. Wireframes cut visual design churn; prototypes cut dev change orders; research cuts feature guesswork; systems cut UI drift; tests cut post-launch support tickets.