4.1 KiB
Module 05: Platform Requirements
Time: 30 min | Agent: Saga | Phase: Strategy
What You'll Learn
How to define the technical boundaries that inform your design decisions before you start designing.
Why This Matters
Imagine designing a beautiful real-time collaboration feature... then learning the backend can't support WebSockets.
Or specifying an offline-first mobile experience... when the client only has budget for a web app.
Knowing the tech stack is a necessity for UX work — not optional.
You can't design well in ignorance. The platform shapes the experience.
Not Architecture — Boundaries
You're not designing the database. You're not specifying API endpoints. That's development work.
You're understanding what's possible so your designs are grounded in reality.
What You'll Discover
1. Platforms
Where will this product live?
- Web only?
- Mobile (iOS, Android, both)?
- Desktop application?
- All of the above?
Each platform has different capabilities and constraints.
2. Integrations
What systems must we connect to?
- Authentication (OAuth, SSO, custom)?
- Payment processing?
- Third-party APIs?
- Legacy systems?
- External databases?
3. Constraints
What's technically impossible or expensive?
- Hosting limitations?
- Budget constraints?
- Team expertise?
- Timeline restrictions?
- Regulatory requirements?
4. Complexity & Challenges
Investigate integrations from a strategic standpoint:
- How complex is this integration really?
- What's the challenge level?
- Is this well-understood or experimental?
- Are there unknowns that need research?
5. Knowledge Gaps
What do we not know yet?
- Unproven technology?
- Missing documentation?
- No team expertise?
- Needs a spike or proof-of-concept?
Surface these gaps explicitly. They become tasks for Idunn to investigate in parallel.
The Saga Method
Saga helps you think through boundaries conversationally:
"What platforms are we targeting?" "Are there any systems we need to integrate with?" "What technical constraints should I know about?" "Is there anything that feels risky or uncertain?"
She'll probe deeper where needed, ensuring nothing gets missed.
Output
A-Product-Brief/platform-requirements.md
This document lives with your Product Brief because it's part of the strategic foundation — not a technical specification.
Handoff to Idunn
Once platform requirements are documented, you can send them to Idunn immediately.
While you continue with UX design (Freya), Idunn can:
- Research knowledge gaps
- Spike complex integrations
- Set up the development environment
- Validate technical assumptions
Parallel work. Design and platform prep happen simultaneously.
What's NOT in This Document
- Database schemas
- API specifications
- Code architecture
- Technical implementation details
Those come later, in BMM's architecture phase.
Connection to Design
Every boundary you discover shapes your design:
| Boundary | Design Impact |
|---|---|
| Web only | No native mobile gestures |
| No real-time | Polling instead of live updates |
| Tight budget | Simpler interactions |
| Legacy integration | Work within existing patterns |
Practice
Think about your current project:
- What platforms are you designing for?
- What integrations are required?
- What constraints exist?
- What feels risky?
Document these before you start designing.
Lessons
Lesson 1: Why Boundaries Matter
Designing in reality, not fantasy
Lesson 2: Defining Platform Requirements
How to document the boundaries that shape your design
Tutorial
Tutorial 05: Create Your Platform Requirements
Hands-on guide to documenting technical boundaries with Saga
Next Module
Now understand the user psychology that drives behavior.
Part of the WDS Course: From Designer to Linchpin