Functional Design
Master the art of designing how users interact with your Buzzy application. Learn to create intuitive user flows, actions, and interfaces with practical examples and prompts.
What Is Functional Design?
While 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:
Bad Functional Design:
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. User Flows
A user flow is the path a user takes to accomplish a goal.
Non-technical explanation: Think of a user flow like a recipe. Just as a recipe lists ingredients and step-by-step instructions (chop onions, heat pan, add ingredients in order), a user flow documents each step a user takes to accomplish something (open screen, fill form, click button, see result).
Visual example - Creating a Task:
Step-by-step breakdown:
Entry Point: User clicks "New Task" button on task list screen
Display: Form appears with fields (title, description, due date, assignee)
Input: User fills in the fields
Action: User clicks "Save" button
Validation: System checks if input is valid
Success Path: Task created → confirmation message → return to list → new task visible
Error Path: Validation fails → error message shown → form stays open with entered data
Why user 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
Common user flows to map:
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_userShow "Delete" only if
record.owner = current_user OR user.role = adminShow "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 = 0Show "Overdue" label (red) when
due_date < today AND status != 'Complete'Show "New" badge when
created_date > 7 days agoShow "Low Priority" in gray, "High Priority" in red
5. Relationship-based display:
Show "Assign to Me" only if
task.assignee = nullShow "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 nowShow "Business Hours Only" message outside 9am-5pm
In Buzzy: Use condition fields with JSONATA formulas and display formulas.
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"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())
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.
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 delete2. 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 empty3. 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 PDF4. 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 changesSample 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:
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:
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 and sort fields to implement these features.
Design considerations:
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:
List all user types
Define what each type can see
Define what each type can do
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 | YesMobile 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
Mobile-First Design: Design for mobile first, then expand for desktop. It's easier to add for desktop than remove for mobile.
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:
Prompting AI with Functional Design
Bad Prompt: "Build a task app with a list and detail view"
Good Prompt: "Build a task app with:
User 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:
Test the main flows yourself
Identify confusing or clunky parts
Get user feedback
Refine the design
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
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.
Next Steps
See examples: Building Examples
Plan your workflow: Project Workflow
Build something: Start with Hello World
Remember: Good functional design makes users successful without thinking about the app—they just accomplish their goals naturally.
Last updated