Design Phase of SDLC: Steps, Deliverables and an Example

The design phase of the SDLC is the third of the seven SDLC phases. It takes the agreed requirements and decides how the software will meet them, from the screens down to the data.

You're done when an engineer can estimate the work and the person who'll use the software has tried a prototype of it.

What the design phase is for

The design phase exists to make the expensive decisions while they're still cheap to change.

Moving a button on a wireframe takes a minute. Changing a database table that already holds a year of invoices takes a migration and a weekend.

Requirements said what the software must do. Design says how, and it comes in two halves.

Product design is the screens and flows, including what happens when something goes wrong.

Technical design is everything underneath, and it has two levels. High-level design is the architecture: the parts of the system, how they talk to each other and where the data lives. Low-level design goes inside each part, down to the tables, the fields and the exact request and response of every API call.

On a waterfall project the two levels are often separate documents, signed off in order. Agile teams tend to settle the high-level design early and do the low-level design one story at a time.

Inputs and deliverables of the design phase

The design phase starts from what requirements handed over and ends with documents an engineer can build from.

Inputs

• A ranked backlog - User stories with acceptance criteria, or a requirements document that does the same job.

• The project brief - Its budget, what's out of scope and the success measure.

• Constraints nobody wrote as stories - The systems you have to connect to, and who may see what.

Deliverables

• Wireframes and a clickable prototype - The main flows, tried by at least one real user.

• A design document - The data model, an architecture sketch and the API contract between the parts.

• Decision records - A short note per hard-to-reverse decision, with the reason.

Who leads the design phase and who takes part

Two people lead the design phase, the product manager and the engineering lead, and each owns a different half.

The PM owns the screens and flows, usually with a UI/UX designer doing the drawing, and the engineering lead owns the data model, the architecture and the API contract.

A PM doesn't draw the data model, but should be able to read it. That's part of the first layer of code fluency I expect from a PM, being able to query your own product's data.

I'd get four more people into the design phase, even on a small team.

• The user - The person who does the job, or someone close to it, tries the prototype.

• QA - Reads the design to plan the tests. In the V-model each level of design is paired with a level of testing.

• Whoever runs it in production - Checks the architecture can be deployed and monitored.

• Security, if you have it - Reviews every flow that touches money or personal data.

When the engineering lead says a screen can't be built as drawn, I'd settle it with a small proof of concept, the way I'd handle a feasibility dispute with developers. Then the PM decides.

Steps in the design phase

I'd run the design phase in six steps, with the screens and the data model drawn side by side.

1. Walk the backlog together. Read the top stories with the designer and the engineering lead, and mark the risky ones, such as a new integration or anything that moves money.

2. Sketch the flows and wireframes for those stories. Low fidelity first, so nobody gets attached.

3. Draft the data model and the architecture. The engineering lead names the entities, how they relate and the parts of the system.

4. Write the API contract between the screens and the server, so front-end and back-end work can start in parallel.

5. Put the prototype in front of a user and change whatever they trip over.

6. Hold a design review. Engineers estimate the top stories against the design, QA asks how each one will be tested, and every hard-to-reverse decision gets written down.

Design in agile versus waterfall

Waterfall runs the design phase once and signs it off before coding starts. In agile it happens every sprint, a little ahead of the stories being built.

Winston Royce's 1970 paper, the one Barry Boehm cites for the waterfall model, put design early on purpose. His first step is headed "program design comes first". The second, on documenting the design, says "The first rule of managing software development is ruthless enforcement of documentation requirements."

He saw the catch too. Under one of his diagrams he wrote that "the design iterations are never confined to the successive steps."

The principles behind the Agile Manifesto say "The best architectures, requirements, and designs emerge from self-organizing teams", and that "Continuous attention to technical excellence and good design enhances agility."

In practice a lot of agile design happens in backlog refinement, before a story meets the team's Definition of Ready. The screens for next sprint's stories get drawn this sprint.

What I wouldn't leave to the sprints is the data model for the first release. It's the hardest part to change later, so I'd settle it before the first line of code. For that stretch an agile project behaves like the waterfall model.

The invoicing tool at the design phase

The example running through this series is a made-up invoicing tool for a plumbing firm with a dozen staff.

Requirements ended with a ranked backlog. Its top story lets the office manager turn a completed job into an invoice without retyping the customer's details, with the right tax rate, sent as a PDF by email.

The designer draws wireframes for three screens: the job list, the invoice editor and a payment status view. They become a clickable prototype, and the office manager tries it before anyone writes code.

In the engineering lead's design document, the data model has four entities: customers, jobs, invoices and payments. Three decisions in it come straight from earlier phases.

• Each invoice keeps the tax rate it was sent with - The acceptance criteria ask for the right tax rate, and an old invoice mustn't change when the rate does.

• An invoice can have more than one payment - Some customers pay in parts, and the payment status view has to show what's still owed.

• Jobs store the date they were completed, and payments the date they arrived - The brief's success measure is days from job complete to payment received. You can't report a number you never stored.

The architecture sketch has a web app, a database, an email service and a payment provider.

The API contract lists what each screen asks the server to do: create an invoice from a job, send an invoice, record a payment. Payments get their own part of it, so the invoice editor can ship before the payment link does.

The diagram as text

• Screens and flows, from the designer and PM: the job list, the invoice editor and a payment status view.
• The API contract, what each screen asks the server to do: create an invoice from a job, send an invoice, record a payment.
• The architecture sketch, from the engineering lead: a web app, a database, an email service and a payment provider.
• The data model, the hardest part to change later: customers, jobs, invoices and payments.

Common mistakes in the design phase

The two design phase mistakes I'd watch for first are screens nobody outside the team has tried and a data model nobody designed.

• No user on the prototype - A prototype only the team has clicked through tests the team's assumptions. Get the person who does the job to try it for ten minutes.

• A data model by accident - If nobody designs it, the first database migration does, and every later feature works around it.

• Designing for scale you don't have - A plumbing firm with a dozen staff doesn't need a message queue and five services. The KISS principle applies to architecture before anything else.

• A design document too big to keep current - Michael Nygard, proposing architecture decision records in 2011, wrote that "Large documents are never kept up to date." Keep the design document short, with a record per decision.

• Security left for testing - OWASP's Top 10:2025 keeps insecure design as its own category and says "An insecure design cannot be fixed by a perfect implementation". For the invoicing tool, that means deciding in design who can see which invoices and what the payment link exposes.

What AI changes in the design phase

AI makes the first drawing of a screen or a diagram cheap. It doesn't know your users or your data, so the decisions stay with people.

Figma's First Draft turns a prompt into editable wireframes. Its help article lists a checkout page for a store that sells BBQs among the prompts that typically generate strong outputs, and a flyer in the shape of a fish among those it might struggle with. It also says First Draft can't generate designs using your own design system.

Figma calls Figma Make a prompt-to-app tool that can turn an existing Figma design into an interactive app, which gives the office manager something closer to working software to try.

Eraser says its AI creates cloud architecture and database diagrams "just by describing it or pasting in some code". Describe customers, jobs, invoices and payments, and the engineering lead has a first diagram to argue with.

The use I'd add is review. Paste the design document and the backlog into a model and ask which acceptance criteria the design doesn't cover. Expect some of its answers to be wrong, and check each one against the backlog.

If the software you're designing has an AI feature in it, the design document needs one more section. I'd want an evaluation section with real deliverables, a fixed set of test inputs with their correct outputs and a metric you track, agreed before the build starts.

A design phase checklist

Before the design review signs the phase off, each of these should be true.

• Every top story has a screen or a flow drawn for it.

• A real user has tried the prototype.

• The data model covers every acceptance criterion and the success measure.

• Every outside service appears on the architecture sketch.

• Both sides of the API contract have read it.

• Each flow that touches money or personal data has a threat model.

• Hard-to-reverse decisions each have a short record.

• Engineers have estimated the top stories against the design.