# Functional Design

## What Is Functional Design?

While [Data Design](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/design-fundamentals/data-design) answers "what information does the app store?", **functional design** answers:

* How do users get things done?
* What actions can they take?
* What do they see and when?
* How do they navigate?

**Non-technical explanation**: If data design is like designing the filing cabinets where you store information, functional design is like designing the office layout—where the desks are, which doors lead where, what happens when you press buttons, and how people move through the space to get their work done.

**Visual comparison**:

**Good Functional Design**:

{% @mermaid/diagram content="%%{init: {'theme':'default', 'themeVariables': {'fontSize':'16px'}}}%%
graph TD
A1\[Clear Entry Point] --> B1\[Obvious Next Steps]
B1 --> C1\[Easy Actions]
C1 --> D1\[Success!]" %}

**Bad Functional Design**:

{% @mermaid/diagram content="%%{init: {'theme':'default', 'themeVariables': {'fontSize':'16px'}}}%%
graph TD
A2\[Confusing Start] --> B2\[Hidden Options]
B2 --> C2\[Unclear Actions]
C2 --> D2\[Frustration]" %}

**Good functional design makes apps intuitive**:

* Users accomplish goals without thinking about the app
* Actions feel natural and obvious
* Errors are prevented or handled gracefully
* Navigation makes sense

**Bad functional design makes simple tasks frustrating**:

* Users get lost or confused
* Actions are hidden or unclear
* Errors are cryptic or unhelpful
* Navigation feels random

## The Core Elements

### 1. Flows

**A flow** is the path users and systems take to accomplish a goal.

**Non-technical explanation**: Think of a flow like a recipe. Just as a recipe lists ingredients and step-by-step instructions (chop onions, heat pan, add ingredients in order), a flow documents each step needed to accomplish something (open screen, fill form, trigger action, see result).

**Visual example - Creating a Task**:

{% @mermaid/diagram content="graph TD
A\[User on Task List] --> B\[Clicks 'New Task' Button]
B --> C\[Form Appears]
C --> D\[User Fills Fields:<br/>Title, Description,<br/>Due Date, Assignee]
D --> E\[Clicks 'Save']
E --> F{Valid Input?}
F -->|Yes| G\[Task Created]
F -->|No| H\[Show Error Message]
G --> I\[Show Success Message]
I --> J\[Return to Task List]
H --> C
J --> K\[New Task Visible in List]" %}

**Step-by-step breakdown**:

1. **Entry Point**: User clicks "New Task" button on task list screen
2. **Display**: Form appears with fields (title, description, due date, assignee)
3. **Input**: User fills in the fields
4. **Action**: User clicks "Save" button
5. **Validation**: System checks if input is valid
6. **Success Path**: Task created → confirmation message → return to list → new task visible
7. **Error Path**: Validation fails → error message shown → form stays open with entered data

**Why flows matter**:

* **Identify all screens needed**: You can't build what you don't define
* **Reveal missing steps**: What about canceling? Going back? Errors?
* **Ensure logical progression**: Does each step make sense?
* **Find friction points**: Where might users get confused or stuck?
* **Enable clear prompting**: You can tell Buzzy AI exactly what to build

**Related Buzzy docs**:

* [Building Blocks: Flows](https://docs.buzzy.buzz/the-building-blocks/flows)
* [Buzzy AI (Flows in App Definition)](https://docs.buzzy.buzz/working-with-buzzy/buzzy-ai)
* [Datatables, Fields & Data](https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data)

**Common user flows to map**:

| Flow Type              | Example                                                   | Key Considerations                          |
| ---------------------- | --------------------------------------------------------- | ------------------------------------------- |
| **Registration/Login** | Sign up → Enter email/password → Confirm → Access app     | Email verification? Password requirements?  |
| **Core CRUD**          | Create/Read/Update/Delete primary entities                | Permissions? Confirmation dialogs?          |
| **Search/Filter**      | Enter search → See results → Refine filters → Select item | Empty results? Multiple results? Sorting?   |
| **Multi-Step Process** | Start wizard → Step 1 → Step 2 → Step 3 → Complete        | Can go back? Save progress? Abandon midway? |
| **Approval Workflow**  | Submit → Review → Approve/Reject → Notify                 | Who can approve? Comments? History?         |
| **Error Recovery**     | Error occurs → Show message → Offer solution → Retry      | Clear error? Helpful guidance? Easy retry?  |

**Sample Buzzy AI v3 prompt with user flow**:

```
"Create a task management app with this user flow:

Main Flow - Create Task:
1. User starts on Task List screen showing all tasks in a list
2. User clicks 'New Task' button (green, top right)
3. Form screen opens with fields:
   - Title (text, required, max 100 chars)
   - Description (long text, optional)
   - Due Date (date picker, required, default tomorrow)
   - Assignee (dropdown linked to Users datatable, required)
   - Priority (dropdown: Low/Medium/High, default Medium)
4. User fills fields and clicks 'Save' button
5. If validation passes:
   - Create task in Tasks datatable
   - Show success message 'Task created successfully'
   - Navigate back to Task List screen
   - New task appears at top of list
6. If validation fails:
   - Show error message in red below invalid field
   - Keep form open with entered data
   - Highlight invalid fields in red border

Also add 'Cancel' button that returns to Task List without saving."
```

### 2. Display Rules

**Display rules** control what users see based on context. This is how you make your app smart and personalized.

**Non-technical explanation**: Think of display rules like the way a restaurant menu adapts. The kids' menu only shows when you're dining with children. The happy hour menu only shows between 4-6pm. The vegan options are highlighted when you mention dietary restrictions. Your app should similarly show/hide elements based on who's using it and what they're doing.

**Visual example**:

```
Task Detail Screen - What Different Users See:

Admin User:
┌─────────────────────────────────┐
│ Task: Update Website            │
│ Assignee: John                  │
│ Status: In Progress             │
│                                 │
│ [Edit] [Delete] [Reassign]     │ ← All buttons visible
└─────────────────────────────────┘

Task Owner (John):
┌─────────────────────────────────┐
│ Task: Update Website            │
│ Assignee: John                  │
│ Status: In Progress             │
│                                 │
│ [Edit] [Mark Complete]         │ ← Can edit own task
└─────────────────────────────────┘

Viewer User:
┌─────────────────────────────────┐
│ Task: Update Website            │
│ Assignee: John                  │
│ Status: In Progress             │
│                                 │
│ (No action buttons)            │ ← Read-only
└─────────────────────────────────┘
```

**Common display rule patterns**:

**1. Role-based display**:

* **Admin**: Sees "Delete" button, "Manage Users", system settings
* **Editor**: Sees "Edit" button on any content, "Publish" button
* **Viewer**: Sees content only, no action buttons
* **Guest**: Sees public content only, "Sign Up" prompts

**2. Ownership-based display**:

* Show "Edit" only if `record.author = current_user`
* Show "Delete" only if `record.owner = current_user OR user.role = admin`
* Show "Transfer Ownership" only to owner

**3. Status-based display**:

* **Draft post**: Show "Publish" button, "Delete Draft"
* **Published post**: Show "Unpublish" button, "Edit"
* **Archived post**: Show "Restore" button, "Delete Permanently"
* **Under review**: Show "Approve"/"Reject" buttons (for reviewers only)

**4. Data-driven display**:

* Show "Out of Stock" badge when `inventory_count = 0`
* Show "Overdue" label (red) when `due_date < today AND status != 'Complete'`
* Show "New" badge when `created_date > 7 days ago`
* Show "Low Priority" in gray, "High Priority" in red

**5. Relationship-based display**:

* Show "Assign to Me" only if `task.assignee = null`
* Show "Unfollow" if user is following, "Follow" if not
* Show "Add to Cart" only if `product NOT IN user.cart`

**6. Time-based display**:

* Show "Early Bird Discount" only during promotional period
* Show "Expires Soon" when `expiry_date < 3 days from now`
* Show "Business Hours Only" message outside 9am-5pm

**In Buzzy**: Use [condition fields](https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data/filter-controls/condition) with JSONATA formulas and [display formulas](https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data/displaying-a-field-based-on-the-values-of-other-fields).

**Sample Buzzy AI v3 prompts with display rules**:

**Example 1 - Role-based buttons**:

```
"On the task detail screen, add these display rules:

Delete button:
- Show only if user.highestRole = 'admin'
- Use condition field with JSONATA: user.highestRole = 'admin'

Edit button:
- Show if user is admin OR task owner
- JSONATA: user.highestRole = 'admin' or task.author = user._id

Mark Complete button:
- Show if user is assignee, owner, or admin
- JSONATA: task.assignee = user._id or task.author = user._id or user.highestRole = 'admin'

All buttons should be hidden (not just disabled) when conditions aren't met."
```

**Example 2 - Status badges**:

```
"On the task list screen, add status badges with these display rules:

Overdue badge (red background):
- Show when due_date < today AND status != 'Complete'
- JSONATA: $toMillis(due_date) < $toMillis($now()) and status != 'Complete'
- Display text: 'OVERDUE'

New badge (blue background):
- Show when created less than 7 days ago
- JSONATA: $toMillis(created_date) > $toMillis($now()) - 604800000
- Display text: 'NEW'

High Priority badge (orange background):
- Show when priority = 'High' or priority = 'Urgent'
- JSONATA: priority = 'High' or priority = 'Urgent'
- Display text: priority field value"
```

**Example 3 - Dynamic action availability**:

```
"Create a product detail screen with smart action buttons:

Add to Cart button:
- Show only if product.inventory_count > 0
- JSONATA: inventory_count > 0
- Hide completely when out of stock

Notify When Available button:
- Show only if product.inventory_count = 0
- JSONATA: inventory_count = 0
- Replace 'Add to Cart' when out of stock

Pre-Order button:
- Show if product.available_date is in the future
- JSONATA: $toMillis(available_date) > $toMillis($now())
- Show alongside 'coming soon' label"
```

{% hint style="info" %}
**Pro Tip for Beginners**: Map out display rules early in your planning. Buzzy AI often creates static UIs that show everything to everyone. You need to explicitly specify what should show/hide and when. Create a simple table:
{% endhint %}

| Element       | Show When      | JSONATA Formula                           |
| ------------- | -------------- | ----------------------------------------- |
| Delete button | User is admin  | `user.highestRole = 'admin'`              |
| Edit button   | User owns item | `author = user._id`                       |
| Overdue badge | Past due date  | `$toMillis(due_date) < $toMillis($now())` |

{% hint style="info" %}
Then include these in your Buzzy AI prompts for accurate implementation.
{% endhint %}

{% hint style="warning" %}
**Common Mistake**: Don't confuse display rules (what users see) with security (what users can actually do). Display rules hide UI elements, but you still need server-level security using Viewers fields and Team Viewers to prevent unauthorized data access. Display rules are for UX, not security.

See: [Security and Access Control](https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data/security-and-access-control)
{% endhint %}

### 3. Actions

**Actions** are things users can do in your app. Every button, link, or interaction is an action that needs to be thoughtfully designed.

**Non-technical explanation**: If your app is like a car, actions are all the controls—steering wheel, pedals, gear shift, turn signals. Each control does something specific, is available at the right time (can't shift to reverse while driving forward), and gives appropriate feedback (lights blink when you signal).

**Action categories with examples**:

**Create Actions** (Making new things):

* Add new item (task, product, post)
* Upload file or image
* Submit form
* Register account
* Duplicate existing item
* Import data from file

**Read Actions** (Viewing and finding things):

* View details of an item
* Search by keywords
* Filter by criteria (status, date, category)
* Sort (alphabetical, by date, by priority)
* Export data (CSV, PDF)
* Print report
* Preview before publishing

**Update Actions** (Changing existing things):

* Edit existing item
* Change status (draft → published)
* Update profile information
* Modify settings or preferences
* Reorder items (drag and drop)
* Toggle feature on/off
* Mark as read/unread, complete/incomplete

**Delete Actions** (Removing things):

* Delete item permanently
* Archive (soft delete, can restore)
* Cancel operation
* Clear form data
* Undo last action
* Bulk delete multiple items

**Navigation Actions** (Moving around the app):

* Go to different screen
* Open detail view (modal or new screen)
* Return to list
* Access menu
* Open in new tab
* Go back to previous screen
* Jump to related item

**External Actions** (Interacting outside the app):

* Send email notification
* Call external API
* Generate PDF document
* Share via social media
* Trigger webhook
* Export to third-party system
* Send SMS message

**For each action in your app, define these four aspects**:

**1. WHO can perform it** (Authorization):

```
Example - Delete Task action:
- Admins: Can delete any task
- Task Owner: Can delete their own tasks only
- Viewers: Cannot delete any tasks
- Guests: No access to delete
```

**2. WHEN it's available** (Conditions):

```
Example - Mark Complete action:
- Available when task.status != 'Complete'
- Available only to assignee, owner, or admin
- Not available on archived tasks
- Disabled if required fields are empty
```

**3. WHAT happens** (Business Logic):

```
Example - Submit Order action:
1. Validate all form fields
2. Calculate total with tax
3. Process payment
4. Create order record in Orders datatable
5. Update inventory counts
6. Send confirmation email
7. Generate receipt PDF
```

**4. WHERE it goes next** (Navigation):

```
Example - After saving task:
- Success: Return to task list with success message
- Error: Stay on form, show error message, keep entered data
- Cancel: Return to previous screen, discard changes
```

**Sample Buzzy AI v3 prompt with detailed actions**:

**Example - Task Management Actions**:

```
"Create these actions for the task management app:

1. CREATE TASK Action:
   Who: All logged-in users
   When: Always available from task list screen via 'New Task' button
   What: 
   - Open create form screen
   - Collect: title, description, due_date, assignee, priority
   - Validate: title required, due_date required, assignee required
   - Save to Tasks datatable
   - Set author = current user
   - Add current user to Viewers field
   Where: On success navigate to task list, show 'Task created' message

2. EDIT TASK Action:
   Who: Task owner OR admin (JSONATA: author = user._id or user.highestRole = 'admin')
   When: Available on task detail screen via 'Edit' button
   What:
   - Open edit form pre-filled with current task data
   - Allow changes to title, description, due_date, assignee, priority
   - Validate same as create
   - Update task record in Tasks datatable
   Where: On success return to task detail screen, show 'Task updated' message

3. DELETE TASK Action:
   Who: Admins only (JSONATA: user.highestRole = 'admin')
   When: Available on task detail screen via 'Delete' button (red, bottom of screen)
   What:
   - Show confirmation dialog: 'Are you sure you want to delete this task? This cannot be undone.'
   - If confirmed: Delete task record from Tasks datatable
   - If cancelled: Do nothing, close dialog
   Where: On delete navigate to task list, show 'Task deleted' message

4. MARK COMPLETE Action:
   Who: Assignee, owner, or admin (JSONATA: assignee = user._id or author = user._id or user.highestRole = 'admin')
   When: Available only if status != 'Complete'
   What:
   - Update task.status = 'Complete'
   - Set task.completed_date = current date/time
   - Send notification to task owner
   Where: Stay on task detail screen, update display to show new status

5. ASSIGN TO ME Action:
   Who: All logged-in users
   When: Available only if task.assignee = null (unassigned)
   What:
   - Update task.assignee = current user._id
   - Add current user to Viewers field
   - Send notification to task owner
   Where: Stay on screen, hide 'Assign to Me' button, show current assignee"
```

**Action checklist for planning**:

* [ ] Listed all actions users need to take
* [ ] Defined who can perform each action (roles/permissions)
* [ ] Specified when each action is available (display rules)
* [ ] Documented what happens when action is triggered
* [ ] Planned navigation after successful/failed actions
* [ ] Designed confirmation dialogs for destructive actions
* [ ] Considered error handling for each action
* [ ] Planned success/error feedback messages

### 4. Context

**Context** is the information available to the current screen or component.

**Types of context**:

**User Context**:

* Who is logged in?
* What's their role?
* What are their preferences?

**Data Context**:

* Which item are we viewing?
* What list are we browsing?
* What search filters are active?

**Navigation Context**:

* Where did the user come from?
* What was their previous action?
* What should "back" do?

**Application Context**:

* Is the app online or offline?
* What device are they using?
* What time is it (for time-based features)?

**Why context matters**:

* Actions depend on context (can't edit without knowing what to edit)
* Display varies by context (show relevant data, not everything)
* Navigation needs context (return to previous list, not random screen)

**AI's challenge with context**: Buzzy AI often generates screens in isolation without considering how context flows between them. You need to explicitly specify context flow in your prompts.

**Better prompting examples**:

❌ **Bad prompt** (missing context):

```
"Create an edit form"
```

Problem: Which record are we editing? Where did we come from? Where do we go after saving?

✅ **Good prompt** (context specified):

```
"Create an edit form screen that:
- Receives a task_id as context when navigating from task detail screen
- Loads that task's data from Tasks datatable to pre-fill the form
- Shows form with editable fields: title, description, due_date, assignee, priority
- On 'Save': updates the task record and navigates back to task detail screen
- On 'Cancel': discards changes and returns to task detail screen
- Shows loading state while fetching task data"
```

❌ **Bad prompt** (no context flow):

```
"Add a comments section to the task app"
```

✅ **Good prompt** (context flow clear):

```
"Add a comments section to the task detail screen that:
- Shows all comments for the currently viewed task (filtered by task_id context)
- Displays comments in chronological order (oldest first)
- Each comment shows: author name, comment text, timestamp
- 'Add Comment' button opens a form with context of current task_id
- After submitting comment, returns to task detail with new comment visible
- Author context: sets comment.author = current logged-in user"
```

**Visual example of context flow**:

{% @mermaid/diagram content="%%{init: {'theme':'default', 'themeVariables': {'fontSize':'16px'}}}%%
graph TD
A\[Task List Screen<br/>Context: Filter, Sort] --> B\[Task Detail Screen<br/>Context: task\_id]
B --> C\[Edit Task Form<br/>Context: task\_id,<br/>return\_to='detail']
B --> D\[Add Comment Form<br/>Context: task\_id,<br/>return\_to='detail']
C --> B
D --> B
A --> E\[Create Task Form<br/>Context: return\_to='list']
E --> A" %}

### 5. Search, Sort, and Filter

For any list of items, users need ways to find what they're looking for. This is critical for usability once your app has more than a handful of records.

**Non-technical explanation**: Think of search/sort/filter like shopping on Amazon. You can **search** for "wireless headphones" (finds specific items), **filter** by price range, rating, brand (narrows down options), and **sort** by price low-to-high or customer reviews (orders results). Your app needs similar capabilities.

**Three core finding features**:

**1. SEARCH - Find items by text**:

* **What**: Text box where users type keywords
* **How**: Searches across multiple fields (name, description, tags, content)
* **Types**:
  * Real-time search (updates as you type) - better UX, more server calls
  * Submit-based search (click button to search) - fewer calls, extra click
* **Features**: Highlight matching text, show result count, clear search button

**2. SORT - Order items by criteria**:

* **What**: Dropdown or clickable column headers to change order
* **Common sorts**:
  * Date created (newest first / oldest first)
  * Alphabetical (A-Z / Z-A)
  * Priority (High to Low / Low to High)
  * Status (Active first, Archived last)
  * Custom (user-defined order)
* **Features**: Remember user's last sort preference, show active sort direction

**3. FILTER - Narrow down by attributes**:

* **What**: Checkboxes, dropdowns, or range selectors for specific criteria
* **Examples**:
  * By category (Electronics, Clothing, Home)
  * By status (Active, Pending, Archived)
  * By date range (Last 7 days, Last 30 days, Custom)
  * By author (My Items, Team Items, All Items)
  * By numeric range (Price $0-50, $50-100, $100+)
* **Features**:
  * Multiple filters combined (AND logic: status=Active AND category=Electronics)
  * Show count of matching items ("Showing 15 of 234 tasks")
  * "Clear all filters" button
  * Active filters clearly shown (chips/tags)

**Visual example - Task list with search/sort/filter**:

```
┌────────────────────────────────────────────────────────┐
│ [Search: "website"___________] 🔍                      │
│                                                         │
│ Filters:                        Sort: [Due Date ▼]     │
│ Status: [✓ Active] [ Archived]                         │
│ Priority: [✓ High] [✓ Medium] [ Low]                   │
│ Assigned to: [✓ Me] [ My Team] [ Everyone]             │
│                                                         │
│ Active Filters: Status: Active × Priority: High ×       │
│ [Clear All Filters]                                     │
│                                                         │
│ Showing 8 of 124 tasks                                 │
│ ─────────────────────────────────────────────────────  │
│ ✓ Update website content        [High] Due: Oct 10     │
│ ✓ Fix mobile navigation bug     [High] Due: Oct 12     │
│ ✓ Review security patches       [High] Due: Oct 15     │
│ ...                                                     │
└────────────────────────────────────────────────────────┘
```

**In Buzzy**: Use [filter fields](https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data/filter-controls) and [sort fields](https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data/sort-fields) to implement these features.

**Design considerations**:

| Consideration     | Mobile                               | Desktop                                 | Why                               |
| ----------------- | ------------------------------------ | --------------------------------------- | --------------------------------- |
| **Filter Layout** | Collapsible panel or modal           | Sidebar or top bar                      | Limited screen space on mobile    |
| **Performance**   | Backend filtering (server-side)      | Backend filtering                       | Don't load all records to client  |
| **UX**            | Clear active filters, easy to remove | Show filters inline, allow multi-select | Users need to see what's filtered |
| **Defaults**      | Smart defaults (e.g., "My Tasks")    | Allow customization                     | Reduce initial clicks             |

**Sample Buzzy AI v3 prompt with search/sort/filter**:

```
"Create a task list screen with comprehensive finding features:

SEARCH:
- Add a search textbox at the top of the screen
- Search across task.title and task.description fields
- Real-time search (updates as user types)
- Show placeholder text: 'Search tasks...'
- Show search result count: 'Found X tasks'
- Add clear search button (X icon) when search has text

SORT:
- Add sort dropdown with options:
  - 'Due Date (Soonest First)' - default
  - 'Due Date (Latest First)'
  - 'Priority (High to Low)'
  - 'Priority (Low to High)'
  - 'Title (A-Z)'
  - 'Recently Created'
- Remember user's last sort selection in browser storage
- Show current sort option clearly selected

FILTERS:
- Add collapsible filter panel (collapsed by default on mobile, open on desktop)

Status Filter (checkboxes):
- [ ] Active (default checked)
- [ ] In Progress (default checked)
- [ ] Complete
- [ ] Archived

Priority Filter (checkboxes):
- [ ] High (default checked)
- [ ] Medium (default checked)
- [ ] Low

Assigned To Filter (radio buttons):
- (•) My Tasks - shows tasks where assignee = current user (default)
- ( ) My Team Tasks - shows tasks where assignee in user's team
- ( ) All Tasks - shows all tasks user has access to

Due Date Filter (radio buttons):
- ( ) All Dates (default)
- ( ) Overdue - due_date < today
- ( ) Due This Week - due_date within next 7 days
- ( ) Due This Month - due_date within next 30 days

Active Filters Display:
- Show chips/tags above task list for each active filter
- Each chip has X button to remove that specific filter
- Show 'Clear All Filters' button if 2+ filters active
- Show count: 'Showing X of Y tasks'

Filter Behavior:
- All filters use AND logic (must match all selected criteria)
- Filters apply immediately when changed
- Remember filter state in URL parameters for bookmarking
- On mobile, filter panel slides in from side or bottom"
```

**Common mistakes to avoid**:

❌ **Filtering on client-side with large datasets**: Don't load 10,000 records and filter in the browser—use server-side filtering through Buzzy's viewFilters.

❌ **Hidden filters**: Don't hide active filters. Users need to see what's being filtered and easily remove filters.

❌ **No default smart sort**: Don't show items in random order. Pick a sensible default (usually newest first, or most relevant).

❌ **Complex filter UI**: Don't overwhelm users with 20 filter options at once. Start with 3-5 most important filters.

✅ **Best practice**: Start with simple search + 2-3 key filters. Add more based on user feedback. Every filter you add makes the UI more complex, so only add what provides clear value.

## Designing for Different Users

### User Roles and Permissions

Most apps have different types of users with different capabilities.

**Common role patterns**:

**Admin**:

* Full access to all features
* Can manage users and settings
* Sees all data across users

**Creator/Editor**:

* Can create and edit content
* Sees own content and maybe team content
* Limited settings access

**Viewer**:

* Read-only access
* Can view but not modify
* No admin features

**Guest/Public**:

* Very limited access
* Often not logged in
* Can view public content only

**In your design**:

1. List all user types
2. Define what each type can see
3. Define what each type can do
4. Specify exceptions (e.g., editors can only edit their own content)

**Document as a matrix**:

```
Feature          | Admin | Editor | Viewer | Guest
-----------------+-------+--------+--------+-------
Create Project   | Yes   | Yes    | No     | No
Edit Own Project | Yes   | Yes    | No     | No
Edit Any Project | Yes   | No     | No     | No
Delete Project   | Yes   | No     | No     | No
View All Projects| Yes   | Team   | Team   | No
View Public      | Yes   | Yes    | Yes    | Yes
```

### Mobile vs. Desktop Considerations

**Design differences**:

**Mobile**:

* Smaller screen (prioritize essential info)
* Touch interface (bigger tap targets)
* Often slower connection (minimize data)
* Used on the go (quick interactions)

**Desktop**:

* More screen space (can show more at once)
* Mouse/keyboard (more precise interaction)
* Usually faster connection (richer content okay)
* Longer sessions (complex workflows okay)

**Functional design implications**:

**Navigation**:

* Mobile: Hamburger menu or bottom tabs
* Desktop: Sidebar or top nav bar

**Forms**:

* Mobile: One question per screen or short forms
* Desktop: Multi-column forms okay

**Lists**:

* Mobile: Cards with key info, tap for details
* Desktop: Tables with multiple columns

**Actions**:

* Mobile: Swipe actions, context menus
* Desktop: Always-visible buttons, keyboard shortcuts

{% hint style="success" %}
**Mobile-First Design**: Design for mobile first, then expand for desktop. It's easier to add for desktop than remove for mobile.
{% endhint %}

## Common Functional Patterns

### 1. Master-Detail

**Pattern**: List of items → Click item → See details

**Example**: Email inbox (list of emails → click → read full email)

**Considerations**:

* How to return to list?
* Remember scroll position?
* Previous/next navigation in detail view?

### 2. Create-Read-Update-Delete (CRUD)

**Pattern**: Standard operations on data

**Screens needed**:

* List view (Read all)
* Detail view (Read one)
* Create form
* Edit form (often same as create)
* Delete confirmation

**For each, specify**:

* Who can access
* Validation rules
* Success/error messages
* Where to navigate after

### 3. Multi-Step Workflows

**Pattern**: Complex process broken into steps

**Example**: Checkout (cart → shipping → payment → confirmation)

**Considerations**:

* Progress indicator (step 2 of 4)
* Can user go back?
* What happens if they abandon midway?
* Save partial progress?

### 4. Approval/Review Workflows

**Pattern**: Item goes through states requiring different people

**Example**: Document review (draft → submitted → reviewed → published)

**Considerations**:

* Who can transition between states?
* Notifications when state changes?
* Comments/feedback during review?
* History of state changes?

### 5. Dashboard/Overview

**Pattern**: Summary view of important information

**Example**: Admin dashboard (users count, recent activity, pending items)

**Considerations**:

* What metrics matter most?
* Real-time updates or periodic?
* Drill down to details?
* Customizable by user?

## Functional Design Checklist

Before building, verify:

* [ ] **User flows mapped**: Documented main user journeys
* [ ] **Actions defined**: Listed all things users can do
* [ ] **Display rules specified**: Defined what shows when
* [ ] **Context planned**: Thought through context flow between screens
* [ ] **Search/sort/filter**: Planned how users find items
* [ ] **Roles and permissions**: Defined who can do what
* [ ] **Error handling**: Specified what happens when things fail
* [ ] **Mobile considered**: Thought through mobile vs desktop
* [ ] **Success states**: Defined confirmations and feedback
* [ ] **Empty states**: Planned what shows when no data exists

## Prompting AI with Functional Design

**Bad Prompt**: "Build a task app with a list and detail view"

**Good Prompt**: "Build a task app with:

**Flows**:

* List tasks → Click task → View detail with edit button → Edit form → Save → Return to list
* List tasks → Click 'New Task' → Create form → Save → Return to list with new task visible

**Display Rules**:

* Show 'Edit' and 'Delete' buttons only for task owner or admin
* Show 'Assign to Me' button only if task is unassigned and user is not a viewer
* Show 'Overdue' badge in red if due\_date < today and status != 'Complete'

**Actions**:

* Create task (all logged-in users)
* Edit task (owner or admin only)
* Delete task (admin only)
* Assign task (owner or admin only)
* Mark complete (assignee, owner, or admin)

**Search/Filter**:

* Search tasks by title and description
* Filter by status (All, Pending, In Progress, Complete)
* Filter by assignee
* Sort by due date, priority, or created date

Make it mobile-responsive with card layout on mobile and table on desktop."

**Result**: AI generates much closer to what you actually need.

## Iterating on Functional Design

Functional design evolves as you build and learn:

**After initial build**:

1. Test the main flows yourself
2. Identify confusing or clunky parts
3. Get user feedback
4. Refine the design
5. Prompt AI to update specific flows

**Common refinements**:

* Reducing clicks for common actions
* Adding missing error messages
* Improving mobile navigation
* Adding confirmation dialogs
* Better empty states

{% hint style="warning" %}
**Don't Over-Design**: You don't need every detail figured out before starting. Define core flows, build, test, and refine. Iteration is normal and healthy.
{% endhint %}

## Next Steps

* **See examples**: [Building Examples](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples)
* **Plan your workflow**: [Project Workflow](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/project-workflow)
* **Build something**: Start with [Hello World](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/hello-world)

Remember: **Good functional design makes users successful without thinking about the app—they just accomplish their goals naturally.**