"Build it first and we will see whether it works" is the most expensive sentence in the vocabulary of product development. Wireframing and prototyping turns that sentence around: we let people test the structure and behaviour of a screen on a real handset in week two, instead of discovering the problem on a production server in week eight. At PBDP the wireframe grows out of the information architecture, and the interactive prototype becomes the basis for stakeholder sign-off, engineering estimates and support-team training.

How wireframes differ from prototypes and from visual design

A wireframe is the skeleton: block placement, information hierarchy, empty and error states — no colour, no photography, no decorative type. It answers one question only: does this screen do its job properly? A prototype is that skeleton with time added to it: taps, movement between screens and the states that matter, such as loading, network failure and restricted access. Visual design is the highest fidelity layer and belongs last, because confirming behaviour first stops colour and typography from inflating the redesign bill. The order never changes: structure first, then web and mobile UI design, then code.

Why modelling work lowers the total project cost

There are three economic mechanisms. First: changing a wireframe takes ten minutes; the same change in shipped code takes three days and a full regression test. Second, the phrase "that is not what I meant" — the root cause of most software disputes — disappears when stakeholders can click through the thing: they sign off what they have seen, not what they imagined. Third, estimates become accurate, because when every state of a screen is visible, the front-end and back-end team quotes from evidence rather than assumption. This is what product management calls the cheapest possible test.

What you receive

• A complete wireframe set: including every state of every screen — empty, error, loading, limited permissions, offline.
• Documented user flows: the path from entry to final action, derived from user research and analysis and the agreed personas.
• A clickable prototype: at a fidelity matched to the project phase, viewable in a desktop or mobile browser.
• A test-ready link: something you can put in front of five real users during usability testing and watch where they stall.
• Screen logic documentation: form validation rules, conditions for showing each block and exact error copy, so support knows what to expect.
• Developer handoff pack: dimensions, spacing and component names — a base that later earns its keep inside a design system.
• Feedback and revision report: problems found, their priority, and the changes made before visual work started.

The process, step by step

1. Brief and success definition: audience, problem, technical constraints and the number the result will be judged against.
2. Sketch and structure: rough layouts on paper converted into digital wireframes, screen by screen.
3. Interaction: screens linked together, states defined, short motion added so behaviour can be understood rather than described.
4. User testing: the prototype runs on the audience's own devices and we record every hesitation, error and question.
5. Revision and freeze: one or two structured feedback rounds, then a locked reference version for visual design.
6. Handover: files, logic documentation and a joint session with engineering before coding begins.

Choosing the right level of fidelity

The rule is simple: the artefact should answer the question you actually have and nothing more. If the question is "can people find the right place", a grey wireframe is enough — colour distracts the tester and pushes feedback toward taste. If the question is "will this convince a board or an investor", you need real content and brand. If the question is "how much work is this", medium fidelity built from standard components is the honest answer. Over-modelling early is investment in something you will discard tomorrow; under-modelling moves the discovery cost into development. We settle both in the project brief, so the ceiling on spend is visible from day one.

Frequently asked questions

We are using a template — do we still need wireframes?

Yes, arguably more. A template fixes the layout in advance, which is precisely why your real need may not fit inside it. The wireframe shows which parts of the template have to change, and whether changing them is worth more than replacing the template. In CMS-based projects this small document prevents months of expensive trial and error; the full scope of what we offer is listed on our services page.

Can the prototype run on a phone?

It does. You receive a shareable web link that opens on Android and iOS handsets with nothing to install. For touch-specific judgements — tap target size, keyboard behaviour, long scrolling — testing on a device is standard here, because a desktop monitor will never tell you whether the bottom button is reachable with a right thumb.

A stakeholder approved the prototype and then changed their mind. What happens?

This is what happens without documentation, and it stays manageable with it. Every approved version is numbered and dated, and changes after sign-off are logged so their time and cost consequences are visible. That single mechanism moves the conversation from "I feel like something different" to "this change costs this much and takes this long".

If you want a clickable version on the table at your next meeting, contact PBDP. Send us the product brief and we will return a prototyping schedule within two working days.