The Align-Define-Design-Refine (ADDR) Process is a lightweight approach that guides organization through an intentional, capability-driven design process in a repeatable and scalable way.
The process is comprised of four phases:
- The Align Phase – “Outcomes before endpoints or code.”
- The Define Phase – “Model first to build fast.”
- The Design Phase – “Collaborate around the contract.”
- The Refine Phase – “Fast feedback loops that create confidence.”
Each phase recommends one or two design activities to guide the process.
The process is meant to be iterative, blending feedback and learnings back into the process early and often.
It was created by James Higginbotham to support enterprises, SaaS companies, and individuals as they designed and delivered APIs.
When was ADDR published?
ADDR started in 2014 as a modeling and design process that was delivered globally for over a decade through live workshops and API design coaching sessions. Since then, it has expanded to include requirements definition, capability mapping, and spec-driven design.
The success of ADDR helped to realize the broader application opportunities of ADDR for API platform architecture, business process engineering, digital transformation initiatives, and the agentic enterprise.
ADDR was featured in the book, “Principles of Web API Design: Delivering Value with APIs and Microservices”, published in December 2021.
Over 10,000 individuals and teams have attended our live workshops and self-paced training courses to learn how to apply ADDR within their organization.
How does ADDR fit with an existing agile process?
The ADDR process is designed to be used with most agile process frameworks. The most common approach is to focus first on the detailed Align and Define Phases to establish a clear definition of the outcomes and capabilities required.
After the capabilities are well-defined, iterate on the Design and Refine Phases over time. As learnings are gained along the way, the process may be revisited to improve the capabilities and re-prioritize the roadmap.
Benefits of the ADDR process
There are several benefits to adopting the ADDR process:
- Aligns business and technology by applying product thinking - Successful design processes support collaboration across business, product, and technical teams.
- Improves cross-functional communication - ADDR is an iterative, team-oriented process that improves quality and speeds delivery. ADDR encourages a cross-functional leadership team to deliver early alignment on the scope and goals of the capabilities across business-facing and technical roles.
- Incorporates rapid feedback - ADDR is rooted in good design that relies on both iteration and parallel efforts with fast feedback loops.
- Avoids design anti-patterns - Anti-patterns are usually signs that we learned important details too late. ADDR ensures design considerations and feedback are factored in early, rather than ad-hoc or not at all.
- Delivers a repeatable, teachable, and scalable design process - The ADDR process guides groups through a repeatable, teachable, trackable process that fits easily within an existing agile framework or as its own agile framework.
Key Differentiators
- Capability-Driven — the Align phase focuses on gaining a clear understanding from business, product, and technical leaders on the capabilities that need to be delivered.
- Business‑to‑tech translation baked in — the Define phase forces teams to map business outcomes into digital capabilities and API boundaries.
- Iterative prototyping — the Design and Refine phases encourage mockups, feedback loops, and usability testing before committing to code.
- Lightweight but repeatable — unlike heavyweight lifecycle frameworks, ADDR can be run in hours or days, even for small projects.
How does ADDR compare to other API design methodologies?
When you stack ADDR against other design methodologies, the biggest difference is that it’s a lightweight, outcome‑driven, design‑first framework that explicitly bridges business goals and technical implementation — something many other approaches only touch on or miss completely.
Here’s a side‑by‑side view of some common methodologies with ADDR:
| Approach | Core Philosophy | Strengths | Potential Gaps vs. ADDR |
|---|---|---|---|
| ADDR | Start with business alignment, model capabilities, design APIs, then refine with feedback. | Strong stakeholder alignment, clear traceability from goals to contracts, iterative refinement before coding. | Less prescriptive about post‑launch governance compared to full lifecycle frameworks. |
| OpenAPI‑First / Contract‑First | Define the contract (e.g., OpenAPI spec) before implementation. | Ensures consistency, enables mock servers and client generation early. | Focuses heavily on the contract; may skip structured business alignment and capability modeling that ADDR enforces. |
| Code‑First | Build the solution and iterate. | Fast for small teams or internal APIs; minimal upfront planning. | Risk of poor developer experience, inconsistent naming, and high cost of change over time; ADDR avoids this by front‑loading design. |
| Jobs‑to‑Be‑Done (JTBD) Design | Models solutions around user “jobs” and outcomes. | Deep user empathy, aligns features with real needs. | ADDR incorporates JTBD thinking in the Align phase but adds more structure for technical delivery and business alignment. |
| Formal SDLC Frameworks | Cover the full API lifecycle: design, build, secure, publish, monitor, retire. | Comprehensive governance and tooling integration. | Broader scope; ADDR is more focused on the design slice, making it easier to adopt quickly and use additional SDLC methodologies without considerable change management. |
Get Started with ADDR
- Visit our ADDR playbooks to find out how the process fits into your organization.
- Take our self-paced course to gain hands-on experience using ADDR.
- Schedule a live remote or on-site workshop for your team or entire organization.