structure-app

name	structure-app
description	Structure an app around objects when starting a complex app from scratch, existing navigation feels messy, users can't find things, or the IA is getting worse as features are added. Use Object-Oriented UX to design around nouns, not verbs.

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