10 KiB

Raw Blame History

Tutorial 06: Platform Architecture

Let Idunn translate your product vision into technical architecture - you speak design, she speaks code

Overview

You've designed the experience. Now you need the technical foundation to make it real. But you're a designer, not a developer - how do you define databases, APIs, and system architecture?

You don't. Idunn does.

You just describe your product in design language. Idunn translates it into Platform PRD.

Time: 30-45 minutes
Prerequisites: Module 05 completed (Trigger Map ready)
What you'll create: Platform PRD & Architecture Document

What You'll Learn

What a Platform PRD is (and why it matters)
How to describe your product's technical needs without being technical
How Idunn helps you think through platform decisions
What questions she'll ask (so you're not surprised)

What is Platform PRD?

Platform PRD = The technical blueprint developers need to build your product.

It includes:

System Architecture: How the pieces fit together
Data Models: What information needs to be stored
APIs & Integrations: How systems talk to each other
Technical Requirements: Performance, security, scalability

Your superpower: You don't need to know how to write this. You just need to know what your product does.

Step 1: Understand Your Role (2 min)

Your job as designer:

Describe what users need to do
Explain what data they create/view/edit
Identify third-party services you want (payments, auth, analytics)
Share any technical constraints you know about

Idunn's job:

Ask clarifying questions about technical needs
Translate your product into architecture decisions
Document data models, APIs, system diagrams
Flag technical risks and recommend solutions

You bring product knowledge. She brings technical expertise.

What to Expect: The Conversation

Here's how a real session with Idunn looks:

Idunn's Opening

Hi! I'm Idunn, your technical architect agent.

I see you've completed your Product Brief and Trigger Map. 
Let's translate your product vision into technical architecture.

I'll ask questions about your product in design language. 
You answer naturally - no need for technical terms.

Ready? Let's start with the basics.

Example Questions Idunn Asks

About Your Product:

Idunn: "What's the core thing users create or manage in your product?"

You: "Users create weekly schedules for family dog care - walks, 
      feeding, vet appointments, etc."

Idunn: "Got it. Do these schedules need to be:
        - Private (only one family)?
        - Shared (multiple families can see each other's)?
        - Collaborative (family members edit together)?"

You: "Collaborative - all family members edit the same schedule."

Idunn: "Perfect. That tells me we need real-time sync and user permissions."

About Users & Authentication:

Idunn: "How do you envision users signing up?"

You: "Email and password should work. Google login would be nice too."

Idunn: "Great! Should users be able to:
        - Invite family members?
        - Have different roles (admin vs. regular member)?"

You: "Yes! The person who creates the schedule is the admin. 
      They can invite family and remove members if needed."

Idunn: "Understood. I'll design a role-based permission system."

About Data & Features:

Idunn: "You mentioned tasks like 'walks' and 'feeding'. 
        What information does each task need?"

You: "Task title, who's assigned, what time/date, and whether 
      it's done or not."

Idunn: "Should tasks repeat? Like 'walk dog every morning'?"

You: "Oh yes! That would be super helpful."

Idunn: "I'll add recurring task patterns. Should we notify 
        the assigned person before the task is due?"

You: "Definitely!"

Idunn: "I'll include a notification system in the architecture."

Built-in Guidance from Idunn

When you're unsure:

You: "I'm not sure if we need that..."

Idunn: "No problem! Let me explain the trade-offs:

       WITH real-time sync:
       ✅ Family sees changes instantly
       ✅ No confusion about who's doing what
       ❌ Slightly more complex to build
       ❌ Requires internet connection

       WITHOUT real-time sync:
       ✅ Simpler to build
       ✅ Can work offline
       ❌ Family might have outdated info
       ❌ Conflicts if two people edit at once

       For family coordination, real-time is usually worth it.
       What feels right for your users?"

When technical terms come up:

Idunn: "I'll use a REST API for communication between app and server."

You: "What's a REST API?"

Idunn: "Think of it as a waiter in a restaurant:
        - Your app (customer) asks for something
        - The API (waiter) takes the request to the server (kitchen)
        - The server prepares the response (food)
        - The API brings it back to your app

        You don't need to know how it works - just that it's 
        the standard way apps communicate with databases."

When prioritizing features:

Idunn: "Based on your Product Brief, I see you want:
        - Task scheduling (core)
        - Notifications (important)
        - Calendar sync (nice-to-have)
        - Vet appointment reminders (nice-to-have)

        For the Platform PRD, I'll design all of these.
        
        But I'll flag which are 'MVP' (must-have) vs. 
        'Phase 2' (add later) so developers know priorities.
        
        Does that split make sense?"

You: "Yes, but actually calendar sync is really important."

Idunn: "Got it - moving calendar sync to MVP. I'll update the 
        architecture to prioritize that integration."

What Idunn Creates While You Talk

As you answer, Idunn is:

✍️ Documenting data models ("Task" entity with fields)
🏗️ Sketching system architecture (app, API, database, notifications)
🔐 Planning authentication flow (login, permissions, roles)
🔗 Identifying integrations (Google Calendar, email notifications)
⚠️ Flagging technical risks ("Real-time sync needs WebSocket support")

You'll see progress updates:

Idunn: "✅ Data model drafted - 3 main entities (User, Family, Task)
        ✅ Authentication flow designed - Social login + email
        🔄 Working on notification system architecture..."

Step 2: Activate Idunn (2 min)

@idunn

I'm ready to create the Platform PRD for [Your Product Name].

I have:
- Product Brief (done)
- Trigger Map (done)

Please help me define the technical architecture.

Idunn will respond and start asking questions about your product's technical needs.

Step 3: Answer Idunn's Questions (20-30 min)

Idunn will guide you through understanding your platform needs. She asks questions like:

About Data

"What information do users create?"
"What needs to be saved vs. temporary?"
"Do users share data with each other?"

Example answers (you don't need technical terms):

"Users create weekly schedules for dog care tasks"
"Schedules need to be saved permanently and shared with family"
"Each task has: title, assigned person, date, completion status"

About Authentication

"How do users log in?"
"Do you want social login (Google, Apple)?"
"Are there different user roles?"

Example answers:

"Email + password, plus Google login"
"Two roles: Admin (can assign tasks) and Family Member (can complete tasks)"

About Integrations

"Do you need notifications?"
"Payment processing?"
"Calendar sync?"

Example answers:

"Yes! Send reminders before tasks are due"
"No payments needed"
"Would be nice to sync with phone calendar"

About Performance & Scale

"How many users do you expect?"
"Any real-time features?"
"Mobile app or web?"

Idunn translates this into:

Database schemas
API specifications
System architecture diagrams
Technical requirements docs

Step 4: Review & Refine (10 min)

Idunn will show you the Platform PRD. Don't panic if it looks technical - you don't need to understand every detail.

What to check:

✅ Does it capture all the features you designed?
✅ Are the user roles correct?
✅ Did she understand your data needs?
✅ Are integrations you wanted included?

Ask questions like:

"Can you explain this part in design terms?"
"How does this support [specific feature]?"
"What if we want to add [feature] later?"

Idunn will clarify and update the PRD until it's right.

Step 5: Save Your Platform PRD (2 min)

Idunn will save the Platform PRD to your project:

/docs/3-platform-prd/
├── 01-platform-architecture.md
├── 02-data-models.md
├── 03-api-specifications.md
└── 04-technical-constraints.md

You now have everything developers need to understand the technical foundation.

Common Questions

Q: Do I need to learn technical terms?
A: No. Speak in design/product language. Idunn translates.

Q: What if I don't know the answer to her questions?
A: Say so! Idunn will explain the implications and suggest options.

Q: Can developers change the architecture later?
A: Yes. This is a starting point. Developers may refine it.

Q: Do I need to review APIs and database schemas?
A: Only if you want to. Focus on whether it supports your design.

What You've Accomplished

🎉 You just created a Platform PRD - something that usually requires technical architects!

You didn't need to:

❌ Learn database design
❌ Understand API protocols
❌ Draw system architecture diagrams
❌ Write technical specifications

You just:

✅ Described your product in design terms
✅ Answered Idunn's questions
✅ Reviewed to ensure it supports your design

That's the WDS superpower: You focus on design. The agents handle the technical translation.

Next Steps

Ready to design the UX?
→ Module 08: Initialize Scenario

Want to skip Platform PRD for now?
You can come back to this after UX design if you prefer.

Pro Tip: Even if you're not building the platform yourself, having this PRD helps you communicate with developers and make informed design decisions. You'll know what's technically feasible without becoming a developer yourself.

10 KiB Raw Blame History