majiayu000 Structure App Around Objects (OOUX)
When to Use
Activate when the user describes:
- Starting a new complex app
- Apps with multiple related data types
- Products where users manage "things"
- Navigation feeling messy
- Users can't find things
- Information architecture getting worse as features are added
- Features scattered across the interface
- Same data shown inconsistently across screens
- Rebuilding a messy existing app
Skip when:
- Building simple single-purpose tools
- Creating marketing/content sites
- Hierarchy matters more than objects
Instructions
The Core Idea
Design around NOUNS (objects), not VERBS (tasks).
Bad: "What screens do we need?" → disconnected features Good: "What objects exist?" → coherent structure
Step 1: Extract Objects
List every NOUN in the product. These are the "things" users think about:
OBJECTS IN THIS SYSTEM:
- [Object 1] (e.g., Project)
- [Object 2] (e.g., Task)
- [Object 3] (e.g., User)
- [Object 4] (e.g., Comment)
- [Object 5] (e.g., File)
Tip: Look at database tables, user stories, or how users talk about the product.
Step 2: Define Each Object
For each object:
OBJECT: [Name]
Core Properties:
- [property]: [type]
- [property]: [type]
States:
- [state 1] (e.g., draft, published, archived)
- [state 2]
Actions:
- [action] (e.g., create, edit, delete)
- [action] (e.g., assign, share, duplicate)
Step 3: Map Relationships
RELATIONSHIPS:
[Object A] ──has many──▶ [Object B]
[Object B] ──belongs to──▶ [Object A]
[Object C] ──can attach to──▶ [Object A] or [Object B]
Types:
- Has many / Belongs to (Project has many Tasks)
- Has one / Belongs to (Task has one Assignee)
- Many to many (Users ↔ Projects)
Step 4: Identify Core vs Supporting
CORE OBJECTS (get their own screens):
- [Object]: [why it's core]
- [Object]: [why it's core]
SUPPORTING OBJECTS (appear within core screens):
- [Object]: [supports which core object]
- [Object]: [supports which core object]
Step 5: Derive Screens from Objects
For each CORE object:
OBJECT: [Name]
SCREENS:
- LIST VIEW: See all [Objects], filter/sort/search
- DETAIL VIEW: Everything about ONE [Object]
- CREATE/EDIT: Form to make or modify
DETAIL VIEW CONTAINS:
- All properties
- Related [Other Objects] (inline or linked)
- Available actions
- State indicators
Step 6: Define Navigation
PRIMARY NAV (Core objects):
- [Object 1 list]
- [Object 2 list]
- [Object 3 list]
CONTEXTUAL NAV (when viewing object):
- Related [Object A]
- Related [Object B]
- Actions for this object
Output Format
IMPORTANT: Always use this exact format:
OOUX STRUCTURE
OBJECTS IDENTIFIED:
| Object | Type | Key Properties |
|--------|------|----------------|
| [Name] | Core | [props] |
| [Name] | Core | [props] |
| [Name] | Supporting | [props] |
RELATIONSHIPS:
[Object A] ──relationship──▶ [Object B]
[Object A] ──relationship──▶ [Object C]
SCREEN STRUCTURE:
- /[objects] → List of [Object]
- /[objects]/:id → [Object] detail
- /[objects]/:id/[related] → Related items
NAVIGATION:
Primary: [Object 1] | [Object 2] | [Object 3]
Contextual: Defined by object relationships
The "OOUX Structure" with Objects/Relationships/Screens is the signature of this methodology.
Anti-Patterns to Avoid
- Feature-based nav: "Reports", "Analytics", "Settings" as top-level
- Verb-based screens: "Create Task" as destination instead of modal
- Orphan data: Showing data where users can't act on it
- Inconsistent objects: Same object looking different in different places