Conversation design: A tool for inclusivity

It may seem obvious, but often forms feel more like interrogations than conversations.

State your name. Next. Phone number. Next. They can lack any sense of dialogue, but also feel downright rude.

When user experience (UX) designers are tasked with building the digital experience of a form, they may go through the entire cycle of discovery, user research, prototyping, and testing but only address the UX copy as an afterthought. The conversations we have with users through these forms, on the other hand, are rarely prioritized in tech. They tend to be considered in snippets, only at the point of a feature need, field labels, or calls to action.

When we break the user journey into pieces, it helps us be meticulous about every design decision, but we can lose the conversation in the process.

If we consider the conversation before we design flows, we can prioritize how we are interacting with the user, not just how we are asking them to make decisions. This approach helps us put vulnerable people at the center of our work, as we can listen for what a screen reader might hear and assess how much cognitive load our dialogue is placing on the user. By thinking about the conversation first, we unlock a powerful tool for accessibility and inclusivity.

Designing forms as conversations

When we design flows, we typically begin with start points, end points, and decisions users need to make along the way. We do this to understand how a user moves through a series of interactions, and then test to see if they can do so without friction. What we don’t often reflect on, though, is the flow of the dialogue. Are there awkward pauses? Do we confirm with “uh huh” or “got it” like we would in person?

We can start by asking one question at a time. For example, many folks using screen readers, particularly beginners or those with cognitive disabilities, will have a much better experience when a page has a clear question (h1), a clear space to answer, and a meaningful response before the next question.

Dynamic fields that offer inline responses may seem like a nice way to respond to user input in real time, but it can cause screen readers to lose their place and marginalize the folks who need them.

Consider this example of a simple dynamic interaction as a screen reader would encounter it:

Q: Is this the form I need?

Choice A: Disability compensation

If the user chooses A: Dynamic content with action appears

sign in to start your form

Choice B: Claim for something other than disability

If the user chooses B: Dynamic content with action appears

We don't support these forms online yet. Please download the PDF to mail it to us.

In this example, the screen reader skips the dynamic content containing the action when it is displayed within a set of form fields, so the user is effectively at a dead end.

Now compare it with this one-question-per-page example:

Q: Is this the form I need?

Choice A: Disability compensation

Action: CONTINUE

Next screen:

Please sign in to start your form

Choice B: Claim for something other than disability

Action: CONTINUE

Next screen:

We don't support those forms yet. Please download this PDF to mail in your form.

In this example, the question protocol paired with one-thing-per-page allows the user to reflect on the question, make a choice, then have their choice confirmed. This not only benefits screen readers, but also anyone experiencing cognitive difficulty who needs to consider each decision with care and have confirmation that they are filling out the form correctly. This can be especially important when critical benefits will be approved or denied based on a user action.

Designing for the dialogue a screen reader user will hear goes a long way to shift accessibility considerations to the beginning of your process, making your form easier to use, more clear, and more holistically inclusive.

Process matters

Begin your form design by crafting a polite exchange with your user, using plain, easy-to-understand language before cracking open a design tool.

Start, as any good project does, with questions. What does your form need to gather? Is each question critical to success? Is there anything you could subtract from the form that isn’t necessary? How long is the conversation? Does it fall naturally into sections? This exercise can begin to shape the form.

A form as a decision conversation.

Next, think about the flow of the dialogue and the potential states, including hint text, calls to action, and error states. If an error appears below the field it is intended to inform, a screen reader would miss the guidance to recover and remedy the error.

A number of boxes as a desicion flow.

Also, if your form is long, consider pausing after each section to confirm the user is making progress.

Working closely with product and engineering is invaluable as you evaluate the implementation — not only do you reduce the risk of accessibility bugs, but you bring an opportunity for the team to think of accessibility first. At Ad Hoc, accessibility specialists help us check our work every step of the way and test with assistive technology to ensure we deliver inclusive experiences. Your team might not have these resources, but you can adopt an accessibility first mindset and check out our Accessibilty Beyond Compliance Playbook to learn more about where to start.

Human-centered design mindset

When you look at a form in its base state, it’s just a container for a human exchange. Approaching a form with an inclusive mindset is a powerful tool in government services, as we can humanize the way we converse with folks using them. If you are applying for a critical health service, housing, or disability benefits, it can be reassuring to know the technology is built by human beings, they are considerate of your experience, and they have taken care in crafting their conversation with you.

A balancing act

This approach isn’t one size fits all. Conditional forms with complex logic might need a focused and guided environment, which this is not intended to solve. An argument could be made that asking one question at a time increases interaction cost and would annoy or delay more advanced screen reader users. Sometimes optimal positioning for a screen reader will present a struggle for sighted users. As is true with any UX problem, we have to weigh the trade-offs. But if this approach can place accessibility at the beginning of your process and reduce cognitive load for your users, it might be the right choice for your form experience.

Thanks to Josh Kim for his accessibility advice while writing this blog post.

Older

Pushup: a new tool for creating dynamic web apps

January 11, 2023

To build and maintain server-side web applications faster and easier, we’ve created a new tool: Pushup. We designed Pushup for the Go programming language as a page-oriented, server-side web framework, similar to applications developed in PHP, Ruby on Rails, and Django for Python.

Read more → of

Newer

A cloud migration is like a kitchen remodel

January 25, 2023

Organizations considering a migration to the cloud may not immediately think that television shows like “Help! I Wrecked My House,” or “Rescue my Renovation” are relevant to the work that they are doing. But it just so happens that things like renovating a kitchen or putting an addition on your house can hold valuable lessons for moving systems to the cloud.

Read more → of

Related

Good government gone mobile: 5 apps that showcase the opportunity of mobile in government

Mobile apps, choice, and customer experience

It’s time to revisit mobile apps as a part of your government CX strategy

How emerging-large companies can help agencies like GSA best achieve their goals

Prioritizing Louisiana users to create a better agriculture and forestry website

Plain language for the win: Improving customer experiences with clearer communication

Become an accessibility champion by using simple mockup annotations

Why new software and new people aren’t enough to transform your customer experience