A clear process, with room for real life.

Good projects need structure. They also need enough flexibility to respond when research changes the brief, a legacy system reveals a constraint or the first prototype shows that an assumption was wrong.

This is the shape we use. The depth changes with the project.

The working model Six connected stages in sequence: listen, frame, design, build, launch, improve, which feeds back into listen for the next phase of work. Listen Frame Design Build Launch Improve
Six connected stages, looping back into the next phase of work rather than ending at launch.
1. Listen

Start with the people who know the problem.

What happens

We speak with the client team, review the current product or process and gather what already exists. That might be analytics, support tickets, spreadsheets, screenshots, old proposals or a brief written the night before the call.

What we need

Access to the people who understand the business and the willingness to discuss the awkward parts, including constraints, internal disagreement and what has already failed.

What comes out

A shared view of the situation and the questions that still need evidence.

2. Frame

Decide what the product needs to change.

What happens

We map users, workflows, systems, content and success criteria. The team separates the first release from the ideas that can wait and records the assumptions behind the decision.

What we need

Timely decisions from the people responsible for the result. A project moves poorly when every stakeholder can add scope and nobody can resolve it.

What comes out

A product brief, prioritised scope, delivery plan and agreed measures of progress.

3. Design

Work through structure before surface.

What happens

Information architecture, flows and prototypes are reviewed before visual design is treated as final. The interface system grows alongside the key screens and states.

What we need

Feedback tied to the brief and the users. Personal preference is part of a design conversation, but it should not be the only evidence in the room.

What comes out

An approved prototype, interface direction and enough system detail to build consistently.

4. Build

Turn the decisions into working software.

What happens

Development runs in visible increments. Responsive behaviour, accessibility, content, performance and integration testing are handled during the build rather than postponed to the last week.

What we need

Content, access, credentials and integration contacts provided early. A payment gateway cannot be tested with a logo and a promise that access is coming soon.

What comes out

A working staging product, reviewed against the agreed scope and tested across realistic devices and states.

5. Launch

Prepare the release, not only the files.

What happens

We check redirects, forms, metadata, analytics decisions, policies, browser behaviour, backups and owner responsibilities. The launch plan identifies who changes what and how the team verifies the result.

What we need

One release owner, final credentials and a clear approval to go live. Design & Code does not make DNS or production changes without that approval.

What comes out

A release-ready package, launch checklist and handover material.

6. Improve

Watch what the live product teaches.

What happens

Early support focuses on genuine defects, confusing content and the changes that become visible only when real users arrive. Ongoing work can then move into planned releases rather than emergency patches.

What we need

Feedback from users and the client team, plus agreement on the support window and what belongs in a future phase.

What comes out

A stable live product and a practical list of improvements grounded in use.

Working principles

Show the work early.

A team should be able to influence the product while change is still affordable.

Write decisions down.

Memory is a poor project-management system, especially once scope and stakeholders grow.

Use specialists with a reason.

We bring in hosting, SEO, AR/VR or other expertise when the product needs it, not to make the team slide look larger.

Test the unglamorous states.

Errors, empty screens, slow networks, expired sessions and missing content are part of the product.

A useful first call is mostly questions.

Start the conversation