Our process
Prototyping and specification writing, before the expensive part
A working prototype and a written specification cost a fraction of a build, and they are the cheapest place to discover that the plan was wrong.
The situation
Everyone agreed, and everyone meant something different
Written requirements read as though they are precise. Put a screen in front of the same people and the disagreements appear within minutes — which is exactly what you want, before the build rather than after.
- A requirement everyone approved but describes differently
- Quotes from suppliers that vary by a factor of three
- No agreement on what the system should do at the edges
- A previous build that met the specification and missed the point
- Stakeholders who will not engage with a document
- Estimates nobody has confidence in, including the estimator
What it covers
What this stage produces
Clickable prototype
Screens people can walk through, which surfaces disagreement that a document never will.
Written specification
What the system must do, precise enough to build from and to test against.
User testing
The prototype put in front of the people who will actually use it, before anything is committed.
Technical approach
How it would be built, what it would integrate with, and where the risks are.
Estimates worth the name
Costs based on a design that exists rather than on a description of one.
A procurement-ready brief
Documentation you can take to any supplier, including a competitor, and get comparable quotes.
How we work
How this stage runs
Short and self-contained — usually weeks. Specification that outlasts the appetite for the project has failed at its own job.
Understand
The objective, the users and how the work runs today, established by observation as well as by interview.
Prototype
Build the screens quickly and deliberately roughly, so people critique the design rather than the styling.
Test and revise
Put it in front of real users, watch where they hesitate, and change it. Repeat while it is still cheap.
Specify
Write down what the tested design implies, including the edge cases the prototype exposed.
Outcomes
What you are left with
- A design tested with real users before it was built
- Disagreements surfaced while they cost nothing to resolve
- Estimates based on something concrete
- A specification you can test the delivered system against
- A brief that gets you comparable quotes from any supplier
- The option to stop, having spent a fraction of a build
Common questions
Questions we are usually asked
For a small, well-understood change, often yes. For anything substantial it is usually a false economy — the cost of discovering a design problem during development is many times the cost of discovering it in a prototype.
No. The specification is yours and is written to be taken to any supplier. That is also the fairest test of whether it is any good: a brief only we could quote against is not a specification, it is a sales document.
Usually weeks rather than months, and it should be tightly scoped. If specification work is running long, that is normally a sign the objective itself has not been agreed.
Because a polished prototype invites comments about colours and fonts, while a rough one invites comments about whether the flow makes sense. The second kind of feedback is what this stage exists to collect.
Then it has more than paid for itself. Some of the most useful outcomes here are a decision to buy a product, change a process, or do nothing at all.
The people who will use the system, not only those who commissioned it. The gap between how a process is described by management and how it is performed on the ground is where most specifications go wrong.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Working with usWhat an engagement looks like from first call to live system.
- Rapid application developmentGetting something usable in front of people quickly, without disposable code.
- Business analysisMapping how the work actually runs before anything is built.
- Agile software development methodologyHow we actually run delivery, and where we depart from the textbook.
- Bespoke business applicationsSoftware shaped around how you work, when nothing off the shelf fits.
- Web application developmentBrowser-based applications for work that outgrew a spreadsheet.