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
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
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.
Best Practices
Begin with Basic Rules
Begin with basic show/hide rules. Add complexity only when needed.
Good: Show field when Priority = High
Simple, clear, easy to understand and maintain.
Avoid: Complex multi-condition rules unless business requirements justify them
Don't over-engineer - add complexity only when truly needed.
Hide by Default
Hide fields by default. Show them when relevant.
Three-step approach:
Identify "always needed" fields - Summary, Issue Type, Priority
Mark everything else as "conditionally needed" - Root Cause, Budget Code, etc.
Create rules to show conditional fields - Based on user selections
Result: Forms start minimal and grow only as needed. Users aren't overwhelmed by 20+ fields on page load.
Walk Through Scenarios
Walk through common scenarios to ensure fields appear at the right time.
Testing checklist:
✅ Fields appear when expected
✅ Fields disappear when conditions change
✅ Required fields are never hidden when they need to be filled
✅ Form progression feels natural
✅ No orphaned data (hidden fields with data)
✅ No confusion about why fields appear/disappear
Pro tip: Test with real users from each role. What seems obvious to you might confuse them.
Progressive Disclosure + Dynamic Required
Progressive disclosure works powerfully with dynamic required fields.
Example:
Rule 1: Show "Acceptance Criteria" when Issue Type = Story
Rule 2: Require "Acceptance Criteria" when Issue Type = Story AND Story Points > 5
Result:
Small stories (1-3 points): Acceptance Criteria visible but optional
Large stories (5+ points): Acceptance Criteria visible AND required
Layered validation: Show first (progressive disclosure), then require when critical (dynamic validation). Users aren't surprised by required fields they can't see.
Common Patterns
Reusable patterns for progressive disclosure:
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 (Bugs vs Stories vs Tasks)
Value-Triggered Fields
Show fields when another field reaches a threshold.
Example: Condition: Priority = High OR Priority = 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 (draft vs review vs done)
Troubleshooting
"Field doesn't appear when I expect it"
Common causes:
Field isn't added to the Jira screen configuration
Scope doesn't match the issue type you're testing
Not all conditions are met
Rule is disabled
Solution:
Verify field is on the screen: Project Settings → Screens
Check rule scope matches your test issue type
Review all conditions - ALL must be met (AND logic between types)
Confirm rule is enabled in the rules list
Debug tip: Temporarily remove all conditions to see if the field appears. Then add conditions back one by one to identify which condition is blocking.
"Field appears but then disappears unexpectedly"
Common causes:
Changed a field value that affects the condition
Conflicting rules on the same target field
Browser cache issue
Solution:
Review what you changed - did it affect a condition?
Check all rules affecting this target field
Ensure rules work together logically (no conflicts)
Refresh browser and test again
Conflicting rules: If Rule 1 shows a field when Priority = High AND Rule 2 hides it when Component = Backend, the field will flicker or behave unexpectedly for High Priority Backend bugs.
"User says field is missing but should be visible"
Common causes:
User's issue type doesn't match scope
User's selections don't meet conditions
User-based condition excludes them
User is on wrong screen
Solution:
Verify user's issue type matches rule scope
Check user's field selections against conditions
Review user-based conditions (groups, roles, permissions)
Confirm user is on the correct screen (Create vs View vs Transition)
Test with same issue type, selections, and user role to reproduce
Reproduce first: Always try to reproduce the issue with the exact same conditions before debugging. What the user reports and what they actually did might differ.
Related Patterns
Progressive disclosure works powerfully when combined with other patterns:
Dynamic Required Fields
Combine progressive disclosure with conditional validation - show and require fields based on context. Show first, then require when critical.
Field Locking on Transitions
Lock fields during status transitions to prevent changes at critical workflow moments.
Next Steps
Choose your path to implementing progressive disclosure:
Create Your First Rule
Step-by-step guide to creating your first progressive disclosure rule. Start here if you're new.
Master Conditions
Deep dive into field-based, context-based, and user-based conditions. Essential for advanced progressive disclosure.
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