Research with the actual users
Not a focus group of managers. We sit with the people who will do the daily work, watch where they hesitate, and find out which of their workarounds protect them from a real problem.
Digital Product Development
Discovery, analysis, UI/UX design, an MVP and the full build as one engagement, with the same team across every phase, including the gaps between them where most products fall apart.
You have a product to bring to market, or to your own staff, and no complete team to build it. Or you have one in pieces: a design agency, a development supplier, a QA vendor, and a growing sense that the product is getting lost between them. We take it on as one engagement, from the first open question to live users, with one team answerable for the result rather than for its own part of it.
Products break between disciplines, not inside them
Products rarely fail inside a single discipline. The design was good but couldn’t be built as drawn, so it was simplified during a sprint without telling the designer. Requirements were signed off, but they listed features people wanted rather than the work they actually do. And the architecture was sound until a new requirement arrived after the schema went live.
One team across every phase closes these gaps, because the same people live with the consequences of their decisions. The analyst who wrote a requirement is there when it gets tested, and designers sit with the engineers who build their screens. We also build and run products of our own, Matefield and Q-Zone, so we know these trade-offs from the owner’s side of the table.
The whole lifecycle
One team, from first question to live traffic
The lifecycle looks much the same from one product to the next. What differs is who is accountable at each handoff, and whether anyone is looking at the product as a whole. Every phase ends with something you can review.
- 01Phase 1
Discovery and analysis
We follow real cases through with the people who will use the product, including the parts that happen over email and on paper. You get the riskiest assumptions named, requirements traced to a reason and an owner, and the first architecture decisions in writing.
- 02Phase 2
Design and prototype
Designers work under the same constraints as the engineers, so the screens you approve can be built as drawn. AI tools make it cheap to try several versions of a flow, and real users test a clickable prototype before production code exists.
- 03Phase 3
The first release
The smallest version that answers the question the business cares about most, built properly along one journey, with measurement in place from the start. You then decide on evidence whether to continue, change direction or stop.
- 04Phase 4
Build and harden
The product grows in releasable pieces, in your repositories and cloud accounts. Automated checks grow with the code, and the harder work is the cases nobody specified: the duplicate submission, the abandoned payment, the user with no permissions.
- 05Phase 5
Launch and beyond
Launch is the middle of the work, not the end. Runbooks and dashboards ship with the release, and what users actually do in the first weeks shapes what gets built next, rather than the original wish list.
Design inside the team
Where the real design decisions are made
Design here is mostly evidence and decisions. Drawing the screens comes last, and it goes faster once the questions behind them have been answered by the people who will use them.
Flows before screens
Where things live, what they are called, and how many steps separate a user from what they came to do. Most of the improvement people actually feel comes from here.
Prototypes that settle arguments
A clickable version where real users complete real tasks. It replaces debate by seniority with evidence, and a confusing flow costs an afternoon to fix here instead of a sprint in code.
Components, not pictures of screens
Designs arrive as components in your repositories, each with its empty, loading, error and overflowing states. New screens are then assembled rather than redrawn, and your team can keep adding them without us.
Accessibility from the first brief
Contrast, focus order, labels and keyboard navigation belong in the brief from day one. Added after an audit, they produce an interface that passes the checklist and is still unpleasant to use.
Two readings of MVP
Most MVPs never answer a real question
The cut-down product
A smaller version of the full product, shipped fast to see what happens. It is cheap to start, easy to explain to a board, and sometimes exactly right.
- Scope is whatever fits the budget and the timeline
- Every feature is present, but each one is thinner than planned
- Done means shipped, so success is hard to measure afterward
- Works well when the market is proven and the build is the risk
Built around one question
Name the assumption the business cannot afford to get wrong, then build only what is needed to test it. The answer is the deliverable.
- One user journey built properly, everything around it left out
- The result that would kill the idea, agreed in advance
- Manual work behind the scenes wherever a person is cheaper than code
- Ends in a decision: continue, change direction, or stop
What you hold before the full build
| Artifact | What it contains | Approved by |
|---|---|---|
| Process map | Current flow, handoffs and exceptions | Process owner |
| Requirements catalog | Numbered requirements with priority, reason and source | Business sponsor |
| Data model | Entities, ownership, valid states, retention rules | Data owner and architect |
| Clickable prototype | Key journeys, tested with real users | Product owner |
| Acceptance criteria | Testable conditions for each requirement | QA lead and sponsor |
| Scope options | First release options with estimates | Sponsor and procurement |
What buyers ask first
The difference is how much of the product one team carries. A supplier usually builds what it was asked to build. Here the same people work from the first open question through design, build and launch, so a decision made in discovery is still owned by someone when its consequences show up in production. There is nobody between phases to pass the problem to.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.