Skip to main content

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.

tip

Formify enables progressive disclosure by showing or hiding fields based on user selections, issue context, or user permissions.

info

Show field only shows; it never hides. A field on the screen is visible until a rule hides it, and a rule does nothing while its conditions aren't met. To show a field only when it's relevant, hide it in every other case:

  • Hide field with the opposite condition (the usual way): to show Root Cause for High and Critical bugs, hide it when Priority not equals High AND Priority not equals Critical. An empty field also matches "not equals", so the field stays hidden until a value is picked.
  • A Hide field rule with no conditions, plus a Show field rule below it on the field's Visibility tab, when the condition has no opposite, such as "contains" or "contains any of" (there is no "does not contain"). Give both rules the same Work type selection: rules with the same work types run from top to bottom, so the Show field rule wins whenever its condition is met. Move up and Move down in a rule's menu change the order. Rules with different work type selections appear together on the tab, but there is no guaranteed order between them.

The field must be on the screen: a rule can't show a field that the screen doesn't include.

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: Hide Field Until It's Relevant​

The simplest progressive disclosure rule hides a field whenever the condition that makes it relevant isn't true.

Example 1: Root Cause for High-Priority Bugs​

info

Requirement: Show Root Cause field only for high-priority bugs

Rule Configuration:

  • Screen: Global Issue Create
  • Target Field: Root Cause
  • Scope: Bug
  • Conditions (joined with AND):
    • Priority not equals High
    • Priority not equals Critical
  • Action: Hide field

Priority has no "is one of" operator, so the rule lists the two priorities that keep the field visible, each with "not equals".

User Experience:

  1. User creates Bug with Priority = Low → Root Cause hidden
  2. User changes Priority to High → Root Cause appears instantly
  3. Form stays clean for routine bugs while capturing analysis for critical issues
tip

Result: 80% of bugs (low/medium priority) see a simpler form. 20% of critical bugs are asked for a 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: Every work type except Bug (for example Story, Task)
  • Condition: (none - applies to all work items of those types)
  • Action: Hide field

Alternative: If the field should show for Bugs AND Incidents, leave Incident out of the scope too.

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 (joined with OR):
    • Priority not equals Critical
    • Environment (select list) not equals Production
    • Current user is in group "Leadership"
  • Action: Hide field

Why it works:

  • Opposite conditions joined with OR: The field is hidden as soon as one requirement isn't met: the priority isn't Critical, the environment isn't Production, or the user is in Leadership. It shows only when all three requirements hold.
  • Priority + Environment: 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​

info

Requirement:

  1. Show "Cost Band" when Feature issue type selected
  2. Show "Budget Code" and "Finance Approval" when Cost Band is "Over 10,000"

Conditions compare values; they don't check whether a number is above a threshold (see Operators by Field Type). Put the ranges into a select list, here Cost Band with the options "Under 10,000" and "Over 10,000", and build the conditions on it.

  1. Rule 1: Hide Cost Band for Other Work Types​

    • Screen: Global Issue Create
    • Target Field: Cost Band (select list)
    • Scope: Every work type except Feature
    • Action: Hide field

    Result: Cost Band shows only when the Feature issue type is selected

  2. Rule 2: Hide Budget Code Below the Threshold​

    • Screen: Global Issue Create
    • Target Field: Budget Code
    • Scope: All work types
    • Condition: Cost Band not equals Over 10,000
    • Action: Hide field

    Result: Budget Code shows once the user picks the "Over 10,000" band

  3. Rule 3: Hide Finance Approval Below the Threshold​

    • Screen: Global Issue Create
    • Target Field: Finance Approval
    • Scope: All work types
    • Condition: Cost Band not equals Over 10,000
    • Action: Hide field

    Result: Finance Approval shows once the user picks the "Over 10,000" band

An empty Cost Band also matches "not equals", so the budget fields stay hidden until the user picks a band. They stay hidden on other work types too, where Cost Band is hidden and empty.

User Experience Flow:

  1. User selects Issue Type = Feature
  2. Cost Band appears; the budget fields stay hidden while no band is picked
  3. User picks Under 10,000
  4. Budget fields stay hidden

Result: Simple form for routine features.

tip

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:

Area-Specific Fields​

Show "API Endpoint" field only for Backend Bug issues:

  • Scope: Bug
  • Condition: Area (select list) not equals Backend
  • Action: Hide 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: Area not equals Frontend
  • Action: Hide UI Screenshot field

Result: Frontend bugs automatically prompt for visual evidence, while backend bugs don't show irrelevant screenshot fields.

tip

Impact: Developers get context-appropriate forms that match their workflow. Backend bugs focus on logs and endpoints; frontend bugs focus on visuals.

Common Patterns​

Type-Specific Fields - Show fields relevant to specific issue types

  • Example: Scope = every work type except Bug, Action: Hide "Steps to Reproduce"
  • When to use: Different issue types need different data

Value-Triggered Fields - Show fields when another field has a specific value

  • Example: Conditions = Priority not equals High AND Priority not equals Critical, Action: Hide "Root Cause"
  • When to use: Collect additional details for high-impact items

Role-Based Disclosure - Show fields only to the users who work with them

  • Example: Condition = Current user is not in group "Finance", Action: Hide "Budget Information"
  • When to use: Keep other teams' fields off a user's form (see Role-Based Visibility)

Status-Based Disclosure - Show fields relevant to workflow stage

  • Example: Issue View rule, Condition = Issue is not in status In Review, Action: Hide "Review Comments"
  • When to use: Adapt forms to workflow stages

Hide, Then Show - For conditions with no opposite, such as "contains"

  • Example: Rule 1 with no conditions, Action: Hide "Breaking Change Impact"; Rule 2 below it, Condition = Release Note contains "breaking", Action: Show "Breaking Change Impact". Both rules have the same work types: the order on the tab decides only between rules with the same Work type selection
  • When to use: Labels, multi-select lists, checkboxes and text conditions that use "contains" or "contains any of"

Next Steps​

Choose your path to implementing progressive disclosure:

tip

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.