Progressive Disclosure
Progressive disclosure is a design pattern where forms start simple and reveal additional fields only when relevant. This keeps forms clean and focused while capturing all necessary data.
Dynamic Screen Rules enables progressive disclosure by showing or hiding fields based on user selections, issue context, or user permissions.
Why Progressive Disclosure Matters
The Problem
Long, cluttered forms overwhelm users and lead to incomplete or incorrect data.
Users face dozens of fields they don't need, making it hard to focus on what matters.
The Solution
Show fields only when they're needed. Users see a focused form that adapts to their choices.
Forms become intelligent guides instead of overwhelming questionnaires.
Benefits:
⚡ Faster Completion
Users aren't distracted by irrelevant fields. They complete forms quicker with fewer decision points.
✅ Better Data Quality
Users fill fields when they understand the context. Right information at the right time.
🎯 Reduced Errors
Fewer fields mean fewer opportunities for mistakes. Simpler forms = fewer errors.
😊 Improved Experience
Adaptive forms feel intelligent and helpful. Users appreciate forms that respond to their needs.
Basic Pattern: Show Field When Condition Met
The simplest progressive disclosure rule shows a field when a specific condition is true.
Example 1: Root Cause for High-Priority Bugs
Requirement: Show Root Cause field only for high-priority bugs
Rule Configuration:
Screen: Global Issue Create
Target Field: Root Cause
Scope: Bug
Condition: Priority = High OR Priority = Critical
Action: Show field
User Experience:
User creates Bug with Priority = Low → Root Cause hidden
User changes Priority to High → Root Cause appears instantly
Form stays clean for routine bugs while capturing analysis for critical issues
Result: 80% of bugs (low/medium priority) see a simpler form. 20% of critical bugs get required root cause analysis.
Issue Type-Specific Fields
Different issue types need different data. Progressive disclosure ensures each type shows only relevant fields.
Example 2: Bug-Specific Fields
Requirement: Show "Steps to Reproduce" only for Bug issues
Rule Configuration:
Screen: Global Issue Create
Target Field: Steps to Reproduce
Scope: Bug
Condition: (none - applies to all Bugs)
Action: Show field
Alternative: If the field should show for Bugs AND Incidents:
Scope: Bug, Incident
User Experience:
Bug issues → Steps to Reproduce visible
Story/Task issues → Steps to Reproduce hidden
Multi-Condition Progressive Disclosure
Combine multiple conditions to show fields in very specific contexts.
Example 3: Executive Contact for Critical Production Incidents
Requirement: Show Executive Contact field for critical incidents in production, but only to non-leadership users
Rule Configuration:
Screen: Global Issue Create
Target Field: Executive Contact
Scope: Incident
Conditions:
Priority = Critical
Component contains "Production"
User NOT in group "Leadership"
Action: Show field
Why it works:
Priority + Component: Targets critical production incidents specifically
User group: Leadership already knows who to contact; field only shows to team members who need guidance
User Experience:
Regular team member creating critical production incident → Executive Contact appears
Leadership creating same incident → Field stays hidden (they don't need it)
Cascading Disclosure
Show fields in sequence as users provide information, creating a guided workflow.
Example 4: Budget Fields for High-Cost Features
Requirement:
Show "Estimated Cost" when Feature issue type selected
Show "Budget Code" and "Finance Approval" when Estimated Cost > $10,000
Rule 1: Show Estimated Cost
Screen: Global Issue Create
Target Field: Estimated Cost
Scope: Feature
Action: Show field
Trigger: Feature issue type selected
Rule 2: Show Budget Code
Screen: Global Issue Create
Target Field: Budget Code
Scope: Feature
Condition: Estimated Cost > 10000
Action: Show field
Trigger: Cost exceeds $10,000 threshold
Rule 3: Show Finance Approval
Screen: Global Issue Create
Target Field: Finance Approval
Scope: Feature
Condition: Estimated Cost > 10000
Action: Show field
Trigger: Cost exceeds $10,000 threshold
User Experience Flow:
User selects Issue Type = Feature
Estimated Cost appears
User enters $5,000
Budget fields stay hidden (under threshold)
Result: Simple form for routine features.
User selects Issue Type = Feature
Estimated Cost appears
User enters $15,000
Budget Code and Finance Approval appear instantly
User completes budget approval process
Result: Proper financial governance for expensive features.
Progressive revelation guides users through exactly what they need. No overwhelming forms, no missing critical approvals.
Practical Use Cases
Real-world examples organized by team type:
Component-Specific Fields
Show "API Endpoint" field only for Backend Bug issues:
Scope: Bug
Condition: Component = Backend
Action: Show API Endpoint field
Result: Backend developers see relevant debugging information without cluttering forms for frontend work.
Show "UI Screenshot" field only for Frontend Bug issues:
Scope: Bug
Condition: Component = Frontend
Action: Show UI Screenshot field
Result: Frontend bugs automatically prompt for visual evidence, while backend bugs don't show irrelevant screenshot fields.
Impact: Developers get context-appropriate forms that match their workflow. Backend bugs focus on logs and endpoints; frontend bugs focus on visuals.
Tier-Based Field Visibility
Show "Customer Tier" field for Customer Request issues:
Scope: Customer Request
Action: Show Customer Tier field
Result: Support requests automatically include customer tier information.
Show "SLA Deadline" when Customer Tier is Premium or Enterprise:
Scope: Customer Request
Condition: Customer Tier = Premium OR Customer Tier = Enterprise
Action: Show SLA Deadline field
Result: Premium and Enterprise support requests automatically display SLA deadlines, ensuring timely response. Standard tier requests remain simple.
Workflow: Agent selects customer tier → SLA field appears instantly → Agent knows exact deadline → Customer expectations are met.
Release Management Fields
Show "Release Notes" when fixing bugs in releases:
Scope: Bug
Condition: Fix Versions is not empty
Action: Show Release Notes field
Result: Only bugs assigned to releases require release notes. Internal bugs without release impact stay simple.
Show "Breaking Change Impact" when Release Notes contains "breaking":
Scope: Bug
Condition: Release Notes contains "breaking"
Action: Show Breaking Change Impact field
Result: Breaking changes trigger additional impact documentation, ensuring proper communication planning.
Cascading disclosure: Release assignment → Release notes appear → Mention "breaking" → Impact assessment appears → Complete documentation ensured.
Common Patterns
Type-Specific Fields - Show fields relevant to specific issue types
Example: Scope = Bug, Action: Show "Steps to Reproduce"
When to use: Different issue types need different data
Value-Triggered Fields - Show fields when another field reaches a threshold
Example: Condition = Priority = High OR Critical, Action: Show "Root Cause"
When to use: Collect additional details for high-impact items
Role-Based Disclosure - Show sensitive fields only to authorized users
Example: Condition = User in group "Finance", Action: Show "Budget Information"
When to use: Protect confidential data from unauthorized access
Status-Based Disclosure - Show fields relevant to workflow stage
Example: Condition = Status = In Review, Action: Show "Review Comments"
When to use: Adapt forms to workflow stages
Related Patterns
Dynamic Required Fields - Combine progressive disclosure with conditional validation - show and require fields based on context
Field Locking on Transitions - Lock fields during status transitions to prevent changes at critical workflow moments
Pre-filling Values - Show fields and auto-populate them with smart values
Role-Based Visibility - Show different fields to different users based on who's creating the issue
Next Steps
Choose your path to implementing progressive disclosure:
Create Your First Rule - Step-by-step guide to creating your first progressive disclosure rule
Master Conditions - Deep dive into field-based, context-based, and user-based conditions
Explore All Actions - Learn about all 7 action types beyond show/hide
Ready to implement? Start with a simple show/hide rule and expand from there. Most teams begin with type-specific fields or value-triggered disclosure.
Last updated