Previously in this series, we discussed how to resolve conflicting accessibility best practices, and how the presentation of accessibility settings to users is as important as having them in the first place. Here, we’ll talk about the importance of simple language for designers and users both.
For those that haven’t read the previous posts in this series, let me introduce the client and product our team worked with. Tusk Philantropies hired Nearform to build a beta version of VoteHub, a mobile voting app aiming to provide disenfranchised, absentee and UOCAVA (overseas) voters with the means to cast a ballot in an election. Given the broad range of users and their needs, and the need to communicate to them relatively complicated concepts in relatively easy-to-understand ways, the vocabulary and phrasing and employed in VoteHub were critical in delivering an intelligible and effective user experience for everyone.
Simple language
Simple language is a topic discussed perhaps less often in product design circles than contrast, keyboard navigation or screen reader behavior, but no less important, especially in civic contexts like voting systems and ballots. Text is essentially the backbone of any app interface, and can make or break a product’s utility depending on how it’s used.
A good set of references for shaping the copy used in VoteHub were, unsurprisingly, official recommendations to election officials from the Center for Civic Design (CCD) and other sources for the style and tone of language used in ballot measures and contests. Here’s a list of references to help you get started:
- Plain language, CCD
- Plain language, Plain Language Action and Information Network (PLAIN)
- How to Design Better Ballots, Whitney Quesenbery, Brennan Center for Justice
In collaboration with the client, and over the course of creating the beta version’s wireframes and high-fidelity mocks, we progressively refined the alpha version’s text into simple, declarative language.
Placement and length of text
Placement and length of text were two concerns that repeatedly appeared during our reworking of the alpha app’s set of screen. Take for example the original Welcome screen, which front-loaded the voter with a lot of “notes and advisories” about the process to come, but without the context of that process being immediately apparent to the voter. To fix this, we colocated information and hints with the inputs a voter needs to fill out, so that they’re supported in the tasks we require of them to complete as they’re performing those tasks.
Text as a narrative
It’s not enough to evaluate an app’s copy, phrase by phrase. The total sum of text should ideally provide a user the cumulative ability to map out their entire journey, or at least be able to quickly identify where they are.
To that end, between each section or task of the main workflow, we inserted interstitial screens, whose purpose was
a) to communicate the voter had successfully finished what had just come before, and
b) to explain what was to come next.
Though technically these interstitial screens added more text for a voter to navigate and read, they provided much-needed clarity, reassurance, and a kind of rhythm a voter could expect from each stage of the workflow.
Describe your workflows in critical steps and problems using simple language
A final note regarding simple language, and how a designer might use it to understand, test assumptions about, and ultimately improve a product.
One can easily reveal workflow problems, and sometimes a novel solution to them, by translating the sequence of actions into a simpler form, for example a few paragraphs that describes each critical step a user takes, with one sentence for each step.
Below is an example reduction, describing the higher-level (and optimistic) transition from marking a ballot to digitally submitting it on VoteHub’s alpha version workflow:
“… System confirms voter’s registration and eligibility.
“Voter marks their ballot.
”Voter chooses an affidavit signing method. Voter signs their affidavit. Voter is asked to provide additional information, including identification and/or other documents. Voter may or may not be able to provide additional information (#1). Voter chooses to physically or digitally return their ballot.
”Voter chooses digital return. Voter requests One Time Access code. Voter checks email for access code. Voter may or may not have access to their email (#2). Voter enters access code. System confirms access code. Voter is authenticated.
”Voter may submit their ballot or perform a ballot check to ensure its accuracy …” etc.
When translating a flow or a part of one into simple language—when it’s reduced to the critical steps and problems a user might encounter on their journey along a product’s intended path— it then becomes a straightforward task to identify issues, such as the two highlighted sentences in the above example. To solve for the cases where a voter might not have the materials they need (#1), and where a voter might not have access to their email (#2), a simple reorganization of the text will do.
Consider this alternative reduction, matching the workflow revision recommendation we proposed and used:
“… System confirms voter’s registration and eligibility.
”Voter is asked to provide additional information, including identification and/or other documents. Voter may or may not be able to provide additional information (#1).
”Voter chooses to physically or digitally return their ballot.
”Voter chooses digital return. Voter requests One Time Access code. Voter checks email for access code. Voter may or may not have access to their email (#2). Voter enters access code. System confirms access code. Voter is authenticated.
”Voter marks their ballot.
”Voter chooses an affidavit signing method …” etc.
It’s clear in comparing the two that the alternative reduction moves user problems earlier in the flow, so that if for some reason the voter is unable to complete requests for information or access their email, they encounter it in advance of marking their ballot—the meat of the workflow—rather than after. We organized the remainder of the alpha workflow’s other steps and problems along the same lines, terming this front-loading of potential user drop-off points the voter’s “barriers to entry,” with the goal to ensure that we’re requesting information and actions from the user in the right order.
The theory of this can be applied in any number of ways, certainly not strictly limited to a writing exercise. One of the results of our team’s discovery work was a shorthand diagram illustrating our having moved user problems to the beginning of the flow. Whether you choose to represent the mental exercise in verbal or visual terms is up to you, and certainly there’s value to both approaches. No matter what eventual form the result of this exercise takes, reducing a complex workflow to its essentials can expose faulty assumptions and provide opportunities for reorganization and improvement.
Conclusion
Refining text to its simplest and most broadly-intelligible form carries with it a number of benefits, both for end users and team members.
