Purpose
Design turns Discovery + Onboarding context into the source of truth for Build. Design is where the agent does its heaviest lifting: drafting requirements from workshop notes, flagging gaps before they become rework and translating approved decisions straight into build-ready instructions.
This stage answers: What is the MVP scope? What business process is Pigment supporting? What requirements, assumptions, and open questions need to be documented? What architecture will support the solution? What validation criteria will confirm the solution works? What build-ready Spec is needed before Build begins?
Use the Stencil agent
Ask the Stencil agent to turn Discovery + Onboarding context into the Design Doc, Architecture and Spec that Build will run on. See the Stencil Agent Guide for an example prompt for this stage.
Key activities, ownership, and customer actions
| Activity | Owner | Purpose | Customer action |
| Review Discovery + Onboarding outputs | Solution Architect / Project Lead | Confirm context, assumptions, risks, open questions and readiness inputs | |
| Run Design / Requirements Workshops | Solution Architect / Customer Business Leads | Baseline current process and effort, validate business process, MVP scope, requirements and decisions | Provide current process knowledge, requirements and business rules |
| Confirm data, integrations, access, and security needs | Solution Architect / Data Lead | Define the technical inputs needed for the solution | Review data, integration, access and security needs |
| Create Design Doc | Solution Architect, with customer validation | Document MVP scope, requirements, assumptions, risks, decisions and open questions | Confirm MVP priorities and trade-offs; validate the Design Doc |
| Create Architecture | Solution Architect | Define the technical structure of the solution | Validate the Architecture |
| Create build-ready Spec | Solution Architect / Solution Modeler | Translate approved design into build instructions and verifiable acceptance criteria | Validate the Spec |
| Confirm validation criteria | Solution Architect / Customer Business Leads | Define how completed functionality will be evaluated | Make or coordinate timely decisions |
| Complete Design Sign-Off | Customer Project Owner / Business Process Leads | Confirm agreement before Build begins (see Roles, Ownership & Governance for what this sign-off confirms) | Approve Design Sign-Off before Build begins |
Required outputs and definition of done
| Required output | Done when |
| Design Doc | MVP scope, requirements, process decisions, assumptions, risks and open questions are documented |
| Architecture | Apps, dimensions, data flows, integrations, access, security and model structure are defined |
| Build-ready Spec | Approved design decisions are translated into clear build instructions |
| Validation criteria | Success criteria are defined for each use case or workstream |
| Updated RAID log | Risks, actions, issues, and decisions from Design are captured |
| Design Sign-Off | Complete (see Roles, Ownership and Governance) |
Recommended practices
- Always review AI-generated logic before it ships
- Work with the CSM to define success criteria and link design outputs to it
- Do not start Build without a clear Design Doc, Architecture and Spec.
- Keep MVP scope visible during every design discussion.
- Separate confirmed requirements from assumptions and open questions.
- Use validation criteria to prevent subjective sign-off later.
- Treat Design Sign-Off as real approval, not a checkpoint to revisit major decisions during Build.
Resources
- Design Workshop Guide
- Business Requirements Template
- Requirements, Tasks and Access
- Design Doc Template
- Architecture Template
- Spec Template
- Process Mapping
- User Stories
- Integrations Guide
- Access and Security Guidance
- Workspace Architecture