Structure
- One main heading per screen
- Heading levels that never skip
- Landmarks for header, navigation and main content
Wireframing
Wireframing services
Estimates go wrong when screens are drawn for the happy path only. Agnotic Technologies wireframes every state, rule and role before build, so engineering can estimate from the wireframes and nothing important is discovered halfway through a sprint.
Annotated screensEvery state drawnClickable prototypesBacklog ready
Trusted by global innovators
What is wireframing, and why treat it as an engineering input?
Wireframing is drawing a product's screens in simple boxes and text, before visual design, to agree layout, content and behaviour. Agnotic Technologies treats wireframes as an engineering input: annotated screens that fix every state, field rule and permission, so the user stories and the fixed-scope estimate come straight from them.
A wireframe that only shows the main screen answers the easy questions. The expensive ones are what an empty list looks like, what a viewer cannot click and what happens when a save fails.
Visual design, branding and design systems are separate services. Wireframes stay grey on purpose, so reviews stay on structure and behaviour.
Fidelity decision table
Which wireframe fidelity fits your purpose?
Choose by what the wireframe has to do, not by habit. Each level has limits.
| Purpose | Fidelity to use | What it must show | What it cannot prove |
|---|---|---|---|
| Stakeholder alignment | Sketch or whiteboard | The main screens and the order users move through them | Whether real users can complete the tasks |
| Scope and estimate | Annotated mid-fidelity wireframes | Every screen, state, field rule and role | Visual design effort or brand fit |
| Usability check | Clickable prototype | A handful of tasks with realistic content and paths | Performance, or how real data edge cases behave |
| Investor or sales demo | Clickable prototype with visual design | The core story in a few screens | That the product can be built as shown |
| Developer handoff | Annotated wireframes linked to design system components | States, validation, permissions, analytics events and accessibility notes | Back-end feasibility, which needs an engineering spike |
We often move a project through two levels: sketches to agree the flow, then annotated wireframes for the estimate and handoff.
Annotation checklist
What does every annotated wireframe show?
The checklist we complete for each screen before it goes to engineering.
- Empty, loading, error and no-permission states, not only the filled-in screen
- Validation rules and the exact error message for each field
- Which roles can see, edit or act on each element
- What every button and link does: where it goes, what it saves and what it asks to confirm
- Where each piece of data comes from, and what happens when it is missing or very long
- Focus order, heading levels and labels for assistive technology
- Analytics events the product team wants to track
- Consent, masking and audit-visible actions on regulated screens
Wireframe to backlog
How do wireframes become a backlog and a fixed-scope estimate?
The steps from the first sketch to an estimate your team can plan against.
List screens and flows
From the brief and any discovery work, we list every flow and the screens each one needs.
Wireframe the riskiest flow first
The flow with the most rules or roles is drawn first, so surprises appear early.
Annotate
States, rules, roles, data sources and accessibility notes are added to every screen.
Engineering review
Our engineers check each screen for feasibility, APIs and data the back end must provide.
Write user stories
Each screen becomes user stories, with acceptance criteria taken from the annotations.
Estimate and plan
Stories are estimated and grouped into a fixed-scope first release.
Accessibility at wireframe stage
Which accessibility decisions are made in the wireframes?
Some WCAG 2.2 decisions are cheap in a wireframe and expensive after build.
Keyboard and focus
- Focus order that follows reading order (2.4.3)
- Focused items never hidden under sticky headers or banners (2.4.11)
Targets
- Tap and click targets of at least 24 by 24 CSS pixels, or spaced apart (2.5.8)
Forms
- Visible labels on every field
- Errors that name the field and describe the problem (3.3.1)
- No re-entering data already given in the same process (3.3.7)
Failure points
When do wireframes go wrong, and when should you skip them?
Problems we see in wireframes made elsewhere, and the cases where wireframing is not needed.
Challenge
Only the happy path is drawn.
Agnotic approach
Every screen carries its empty, loading, error and no-permission states before review.
Challenge
Wireframes look finished, so reviews turn into debates about colour.
Agnotic approach
Grey-box styling keeps attention on structure and behaviour.
Challenge
Role differences are missed until testing.
Agnotic approach
A role matrix per screen shows what each role sees and can do.
Challenge
A clickable prototype is treated as proof the back end is simple.
Agnotic approach
Engineering reviews each screen for data and API needs before the estimate.
Challenge
Consent screens and masked data are designed last.
Agnotic approach
Regulated flows are wireframed first, since they shape the screens around them.
Challenge
A small change is wireframed from scratch.
Agnotic approach
Skip wireframes when the change fits existing design system components; design directly with those instead.
Who it is for
Who uses our wireframing services?
Teams that need agreement and an estimate before they spend on build.
Wireframing for startups
Founders preparing an MVP who need a fixed-scope estimate they can budget against.
Product teams adding a large feature
Features that touch many screens, roles or rules in an existing product.
Companies replacing internal tools
Spreadsheets and old admin tools turned into screens that match how staff really work.
Buyers comparing vendor quotes
Annotated wireframes give every vendor the same detailed brief to quote against.
Regulated product teams
Consent, masked data and audit-visible actions agreed with compliance before build.
Scope and cost
What drives the cost of wireframing?
No published rates. The wireframing scope is set by these factors, and the quote is written once we have seen the brief.
Screens and flows
How many flows and screens the product needs for its first release.
Roles
How many user roles see different versions of each screen.
Platforms
Web only, or web and mobile, each with its own layouts.
Fidelity
Sketches, annotated wireframes, a clickable prototype, or all three.
Usability round
Whether the prototype is tested with users before the estimate.
Regulated flows
Consent, masking and audit rules that need review with your compliance team.
Standards
Standards our wireframes follow
Design and accessibility standards we apply before visual design starts.
WCAG 2.2ISO 9241-210Section 508
Facts and sources
Facts behind accessible wireframes
WCAG 2.2 criteria that are settled at the wireframe stage, each linked to the W3C standard.
WCAG 2.2 success criterion 2.4.3 Focus Order (Level A) requires focusable components to receive focus in an order that preserves meaning and operability.
Source: WCAG 2.2, 2.4.3 (W3C)WCAG 2.2 success criterion 2.5.8 Target Size (Minimum) (Level AA) requires pointer targets of at least 24 by 24 CSS pixels, unless they are spaced so a 24 pixel circle around each does not touch another target.
Source: WCAG 2.2, 2.5.8 (W3C)WCAG 2.2 success criterion 3.3.1 Error Identification (Level A) requires that when an input error is detected automatically, the field in error is identified and the error is described to the user in text.
Source: WCAG 2.2, 3.3.1 (W3C)WCAG 2.2 success criterion 3.3.7 Redundant Entry (Level A) requires information a user already entered in the same process to be auto-populated or available to select, with limited exceptions.
Source: WCAG 2.2, 3.3.7 (W3C)
Frequently Asked Questions
A wireframe shows structure and behaviour in grey boxes. A mockup adds the visual design. A prototype makes screens clickable, at either level, so people can try a flow before it is built.
It is quoted from the list of flows and screens. Roles, platforms, the fidelity you need, a usability round and regulated flows add to it.
It depends on the number of flows, screens and roles, so we agree the scope and review dates on the scoping call. Reviews with your team usually set the pace more than drawing does.
Yes. A clickable prototype built from the wireframes is enough for a formative usability test, and testing before visual design is the cheapest time to change a flow.
No. They stay grey on purpose. Visual design and design system work follow once structure and behaviour are agreed, either with us or with your own design team.
Yes. We start by mapping the current screens and rules, including the ones users rely on but nobody documented, then wireframe the new version so nothing is lost in the rebuild.
Yes. That is the main reason to annotate wireframes in this much detail: the user stories and estimate come from them, so the MVP scope is fixed before build starts.