Progressive Disclosure UX: What to Show, Reveal, and Never Hide

Reduce irrelevant questions without hiding the decision

A workshop registration page asks for name, email, attendance mode, postal address, travel details, dietary preferences, invoice data, and a long explanation of every field. Most visitors want to attend a free online session. The form looks complicated because it presents several different journeys at once.

In this worked redesign, the workshop offers online and in-person attendance. Everyone needs the date, duration, availability, and whether attendance costs anything before reserving. In-person attendees need the venue and may request an access arrangement. Online attendees need the joining process. There is no payment or invoice in this first release.

Progressive disclosure should follow those dependencies. It should not become a way to hide inconvenient facts such as a fee, an eligibility restriction, or the fact that choosing a session creates a commitment. The first decision remains understandable before the person opens optional content.

Compare two real GOV.UK patterns

The GOV.UK details component gives optional explanation a descriptive control; its public example offers help with nationality. The guidance explicitly cautions against hiding information most users need. This is a useful model for short, situational help, not for concealing the main instructions.

The radios component demonstrates a different pattern: choosing a contact method reveals the corresponding input, such as an email address field. The selection makes the next question relevant. This is a dependency between answers rather than a collapsed paragraph of general help.

Apply those patterns according to the job. A short explanation of how the joining link arrives can use details. Choosing online versus in person should determine the relevant follow-up fields. A complex new sequence may deserve its own page instead of an expanding block that pushes the submit button around.

Write the visible page before designing expansions

The initial page should say what the visitor is reserving. In this example: “Community workshop — Saturday, 2–4 pm. Free to attend. Choose online or in-person attendance.” Show availability for each mode. The in-person option includes the venue; the online option explains that joining instructions arrive after confirmation.

Ask for name and email because both modes need confirmation. Do not show a postal address field merely because it exists in the database. Remove invoice controls entirely because the release has no payment flow. Removing irrelevant requirements is often better than hiding them.

Place the optional joining-link explanation beside the online information. Its label should describe the question it answers. “More” and “Advanced” make visitors guess what is inside; “How will I receive the joining link?” lets them decide whether opening it is useful.

Define the expanded state and the return path

When a person selects in person, reveal one optional checkbox: “Email me to discuss an access arrangement.” Use the email address already entered for the reservation, and explain that an organizer will follow up. Do not nest another expanding question inside this reveal. GOV.UK recommends putting multipart follow-ups on a separate page; use that route if the service needs a longer conversation.

If they switch back to online, the in-person questions no longer apply. In this design, previously entered in-person choices can remain in local draft memory for switching back, but they are excluded from validation and submission while online is selected. The review page shows only the active answers. State that policy explicitly so a hidden required field cannot block submission.

If an organizer genuinely needs an answer regardless of mode, move it out of the conditional section. Hiding a field does not change the business requirement. Likewise, retaining a hidden answer and submitting it silently can create a request the visitor no longer intended.

Check comprehension and accessibility

Give one participant an online-attendance task and another an in-person task that needs an access conversation. Observe whether they can predict which information they will need and understand the result. Counting fewer visible fields is not sufficient evidence of improvement.

Use controls with clear accessible names and expanded-state information where appropriate. Newly revealed inputs should follow their trigger in reading and keyboard order. Do not unexpectedly move focus just because a block expanded; make it possible to reach the new content naturally.

GOV.UK documents research and limitations for its components, including conditional-reveal accessibility considerations. Reusing a visual pattern does not inherit all of its implementation behavior. Test your own component with keyboard navigation, text zoom, and supported screen readers, including validation inside an expanded branch.

Use a disclosure inventory for the next form

For each proposed hidden item, record who needs it, what makes it relevant, how someone discovers it, and what happens to its data when hidden. If the only reason is “the screen looks busy,” revisit the underlying requirements before adding another expandable section.

Keep a small comparison of the original and revised journey: which questions disappeared because they were unnecessary, which became conditional, and which remained visible because they influence consent or choice. This makes the design rationale reviewable.

The finished design should make the next decision easier without making the consequences harder to see. Verify that outcome through complete task attempts, including changing an earlier answer, rather than approving only the collapsed screenshot.

References

• GOV.UK: Details component
• GOV.UK: Radios and conditional reveals