I85PREP
⌘ K
PMI CD-P study materials
PMI CD-P study resources

PMI CD-P: Application Design and Build

PMI CD-P · Work through your exam, one topic at a time.

All guide sections

Application Design and Build

Domain 3 - Application Design and Build

This domain tests whether you can turn agreed requirements into a working, maintainable app: data model, screens, roles, rules and build hygiene. Expect questions on data modeling, least-privilege access, validation, UX for the process worker and iterative delivery.

Data model first

  • Identify entities, keys and relationships before designing screens. A wide table with repeated columns usually signals a modeling error.
  • Choose correct field types; store dates as dates and numbers as numbers, not text.
  • Keep one source of truth. Do not copy a value into three places and reconcile it by hand.
  • Use lookups to reference master data rather than free-text entry.

Roles, rules and UX

  • Design for least privilege: requester, approver, administrator, auditor. Test each role, not just admin.
  • Put business rules in one place so the UI and the automation cannot disagree.
  • Screens should follow the task: minimal fields, sensible defaults, error messages that say how to fix the problem.
  • Design for the device the user actually has; check accessibility and keyboard use.

Build hygiene

  • Naming conventions, comments, reusable components, version history.
  • Configuration over hardcoding: environment variables for URLs, mailbox addresses and thresholds.
  • Ship a thin slice, get feedback, then extend. Build in iterations rather than one large release.

Worked example

A leave-request app has Employee, LeaveRequest and Approval entities. Balance is calculated from approved requests, not stored as an editable number, so it cannot drift. Approver routing reads from the employee's manager lookup rather than a hardcoded email. Validation blocks overlapping requests and negative balances. The first release covers request, approve and reject; reporting comes after user feedback.

Traps that cost marks

  • Hardcoded approver emails, site URLs or credentials.
  • Storing calculated values that then go stale.
  • Building every feature before any user sees it.
  • Testing only as administrator, then discovering requesters see the wrong records.
  • Ignoring mobile, accessibility or localization requirements until launch.