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:

code

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:

code

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

code

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

code

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:

code

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

code

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:

code

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