Task 1 (Data Structure) Task 2 (Terminology standardization) Task 3 (impact of change) Mission 1 (Decision Making) Mission 2 (Exception Scenario) 📊 View Summary ← Classroom
Day 5 Mission 01 Decision logging

Mission 01. Become a first-time design user (Design Decision Log)

Automatically creates a standard Design Decision Log (Why) report that records database normalization methods and architecture decisions.

Mission 1 Become a first-time design user Practice guide

📥 Practice Input

  • • day5_signup_flow.md (meeting conversation transcript)

💾 Practice output (Output)

  • • design-decision-log.md (Become a first-time user document)

1. Story and practice background

Although it is possible to send messenger messages or read the news using a smartphone, there are self-employed users in their 50s who have hardly ever filled out a new mobile sign-up form or navigated the complex procedures of scheduling a time.

The development team carelessly designed the validity conditions for password registration, but novice customers are frustrated by missing the ID duplicate check button, having problems recognizing font size, and losing all input when an error occurs.

In this mission, the background of data normalization and architecture decision made in the technical design stage was standardized using Codex. Design Decision Log Learn how to safely manage a system's historical assets and design rationale (why) by documenting them.

2. Learning objectives

  • Normalization and database structure design decisions can be accurately extracted from meeting minutes.
  • Decision items, background reasons, review of alternatives, approvers, and possibility of future changes can be specified.
  • By recording the history (why) of design decisions, you can prevent duplicate meetings and mistakes by new team members.

🛠️Practical guide to follow along

  1. Create file for practice: Click the download button below day5_signup_flow.md file automation/ Save it within the folder.
  2. Codex logging delegation: Build by sending the **Codex request prompt** below to the Codex Client prompt input window.
  3. log check: In the printed report, review whether the decision ID (DEC-003), decision background, review alternative (reason for rejection), and approval entity are structured correctly.

Download practice materials

Codex request prompt

Mission 01 Prompt
You are a self-employed person in your 50s who is somewhat unfamiliar with using digital smartphone apps. While looking at the membership registration and first screen UI specifications written in the provided day5_signup_flow.md specification, please write down your emotional reaction and improvement requirements about what is most confusing and difficult when signing up from your perspective.

4. Example results

Codex documents the architectural conclusions and the basis for compromise in the conversation history as follows.

[Decision ID: DEC-003]
• decision: Reservation cancellation history is designed to be separated 1:N into a separate Reservation_Histories table instead of accumulating it directly in the Reservations table.
• Vivid user first reaction and feedback (Pain Point): Prevents write lock bottlenecks on the main table due to frequent reservation status changes and meets history tracking requirements by date and agent.
• review alternatives: Directly add canceled_at, cancel_reason to the Reservations table (dismissal: cannot record multiple cancellation history and risk of table bloat)
• approval entity: PM and Lead Engineer (Approver: Dev_Lead)
• Possible changes in the future: When large-scale traffic occurs, history may be transferred to NoSQL Document DB.