Pre-Development | Project Asset Review Checklist

Objective

---

1. WHY

Rationale	Benefit
Mitigate Rework	Catching inconsistencies between the PRD and design (e.g., a feature described that is missing from the UI) saves days or weeks of rework later in the sprint cycle.
Accurate Estimation	A thorough understanding of complexity (especially regarding edge cases in user/process flows) leads to more precise task estimations and better sprint planning.
Technical Clarity	Identifying data requirements (Datasheet) and complex backend interactions (Process Flows) upfront allows for correct database architecture and API design from the start.
Alignment	Ensures the team's technical implementation perfectly matches the intended business goals (PRD) and user experience (UI/UX).

---

2. HOW

Step 1: Product Requirements Document (PRD) Review

• Goal: Understand the "What" and "Why" of the feature from a business perspective.

• Procedure:

  1. Read for Goal: Identify the core business goal or problem the feature is solving.

  2. Define Scope: Clearly delineate which requirements are in scope for the current iteration and which are out of scope.

  3. Cross-Reference: Ensure every functional requirement mentioned in the PRD is represented visually in the UI/UX designs.

  4. Identify Ambiguity: Highlight any vague terms (e.g., "fast," "secure," "easy to use") and translate them into measurable technical criteria.

• Deliverable: A list of PRD Clarification Questions for the Project Manager.

Step 2: UI/UX Designs Review (Figma)

• Goal: Understand the "Look and Feel" and user interaction model.

• Procedure:

  1. Review States: Check all critical component states (hover, active, disabled, error, empty state) for every screen.

  2. Responsiveness Check: Verify how the layout adapts across all specified screen sizes (mobile, tablet, desktop).

  3. Accessibility: Flag any potential issues (e.g., low color contrast, missing focus states for keyboard navigation).

  4. Handoff Details: Verify all necessary specs are available (e.g., component properties, colors, typography, spacing/layout constraints).

• Deliverable: A list of Design Questions/Issues tagged directly in the design file (e.g., Figma comments) for the Designer.

Step 3: Datasheet / Data Structure Review

• Goal: Understand the data model and all data endpoints required.

• Procedure:

  1. Identify Data Points: List every single piece of data required on the screen (e.g., User ID, Product Name, Price, Date Created).

  2. Source Check: Determine the origin of each data point (API endpoint, local storage, external service).

  3. Structure Alignment: Ensure the proposed API/database structure is efficient and supports the UI/UX needs (e.g., avoiding N+1 problems).

  4. Validation Rules: Note all required data validation rules (e.g., max length, data type, required fields).

• Deliverable: A documented plan for necessary API Endpoints or Database Query logic.

Step 4: User Flows and Process Flows Review

• Goal: Understand the complete journey, including happy paths, error paths, and non-linear interactions.

• Procedure (User Flows):

  1. Happy Path Walkthrough: Follow the primary successful path step-by-step to confirm flow continuity with the UI designs.

  2. Error Case Mapping: Identify possible user input error, server error, and failure state, and verify a corresponding recovery screen or clear message exists in the UI.

  3. State Management: Track how user state (logged in, logged out, data saved) changes at each step.

• Procedure (Process Flows - Backend Logic):

  1. System Handoffs: Clearly map out interactions between microservices, external APIs, and the database.

  2. Asynchronous Tasks: Identify any long-running or background tasks (e.g., email sending, data processing) and how the user is informed.

• Deliverable: Confirmed Flow Logic and a list of identified Edge Cases that require additional handling.