Whenever I had to take standardized tests in high school, I would get anxious over the easiest part: filling out my name.
Tests like the SAT and ACT insist that you fill your name out exactly as it appears on your identification documents. But when I wrote the hyphen in my surname—Gonzalez-Cameron—it would throw back an error, or I would run out of space. Either way, I could not make the information on the form match my documents.
More recently, I found myself in a standardized testing environment again, this time to take the GRE. Although their website is more upfront about how to handle last names, they still require and refuse accuracy in the same breath—particularly frustrating for Hispanic-Americans and many other test-takers:
This is where design and cultural awareness intersect. What determines the space limitations for collecting last names? Why can’t hyphens, spaces, accent marks, or nonstandard characters be used? What would it take to alter the code to accept a wider range of naming conventions, especially given that Hispanic-Americans make up 17% of the population?
These are seemingly small considerations for the design process. Students shouldn’t stress about instructions or worry that their answers will be thrown out because they can’t complete the first step correctly. Designers have a responsibility to understand their users, and to build forms that can accommodate an increasingly common style of surname—whether that’s for standardized tests, government documentation, health-care forms, or other systems that people use to live their daily lives.
If we want to make the web a better tool for communication, we need to better understand our audiences and capture the correct cultural nuances in our content and experience designs.
Understanding Hispanic-American naming conventions#section1
Naming conventions are just one of many distinctions for the Hispanic-American population—a group that itself is hardly monolithic, subject to millions of variations by ethnic background, location, age, dialect, and other factors. But understanding how names work and taking them into consideration can go a long way toward a better user experience.
Most Hispanic-Americans have at least two last names. They are not hyphenated; hyphenation is a practice that many have adopted to avoid confusion in the United States’ single-name infrastructure.
Here’s how it works: in traditional marriages, the husband and wife keep their respective two surnames. The wife may add on “de <name>” to show that she is now “of” her husband’s family—so now she’s working with three surnames.
If the couple have children, their surnames will be constructed from the first surnames of the parents. To illustrate:
Even without considering accent marks, you can probably already imagine how this would break things on the English-based Internet and backend databases. And this doesn’t even begin to touch on the challenges created by tildes, cedillas, non-Latin scripts, nontraditional naming conventions, and naming systems used by other ethnic groups.
Let’s improve our processes#section2
We’ve walked into the spiderweb of intricacies around making our stuff work better for more people, specifically around the accommodation of names. There’s obviously room for improvement—from the tactical aspects of forms all the way up to the culture of our workplaces.
Review or study form design#section3
There is already conversation about accommodating names on web forms. For example, in “Personal names around the world,” the W3C provides a great primer on how these issues affect everyone, not just Hispanic-Americans.
Luke Wroblewski literally wrote the book on web forms—in which he walks through the overarching process for designing a good form, focusing on specific aspects such as viewports and inline validation—and has also published a number of informative articles. In “Inline Validation in Web Forms,” Wroblewski points out that “web forms aren’t great conversationalists. They ask a bunch of questions, then wait until you answer them all before they respond.”
I like to use this observation to reimagine forms as dialogues. This makes it easy to spot potential pain points for your audience. For example, the form input of “Name:” can be reimagined as “What’s your name?” Similarly, the form response of “Error: last name not valid” can be heard as, “I’m sorry, I can’t understand your last name, so it’s not valid”—not a particularly kind response.
Form functionality gains traction at the development stage, so it’s useful to look at work on that side as well. Aaron Gustafson’s presentation “Falling in Love with Forms” goes through common form patterns and how to build more intuitive, responsive forms in HTML5. While Gustafson doesn’t address name accommodation directly, his approach supports better form design across the board; he encourages designers and developers to “focus on making the form read naturally and easily. You can’t always make an interface perfect, but you can make it usable.”
It may be helpful for your team to take a day and workshop how you build your web forms. You should look at the challenges and considerations that arise in making forms, building research into the budget and scope of projects, and incorporating more usability testing with diverse testers. Not only will this build skills and provide insights, but it can mark an important shift in your organization’s culture; often people get so bogged down in daily tasks that carving out space for the whole group signals permission to stop and learn more intentionally.
Clarify your digital governance process#section4
I’m certain no one makes forms intentionally difficult to fill out. To tactfully suggest and work toward improvement, though, requires an understanding of your organization’s digital governance process. Knowing that you have a strong framework in place for getting things done or getting approval makes it easier to work on specific changes.
What if you don’t have a digital governance process or don’t know what it is? I once worked in a government setting where no individual had the authority to decide what would get published, why, or when. Our team knew we needed to overhaul a section of the website because the grant program’s terms were going to change, but no one seemed to have the freedom to try things out or make changes, or the power to make the final call. Meetings became a lot of discussion with little to no decision-making.
When these kinds of meetings are the norm, teams lose momentum, which means nothing changes, and then the old, outdated versions persist. In her fantastic book, Managing Chaos, Lisa Welchman explains that clear digital governance is the way forward:
Clarifying your organization’s digital governance plan makes it easier to make changes—whether to fields in your web forms or to the design process that built them.
Getting team buy-in on change#section5
The strongest step is to begin building a more culturally aware process in your organization. If you’re in a decision-making position, you have the agency to set the tone and make changes. If you’re not in a decision-making position, it’s still possible to take action, if you work carefully and diplomatically.
- Start asking why. How does the webpage editing process at your office work? Does everything have to get run by Sally now because someone published something offensive once by accident? Write down your questions about how content is created and developed. Maybe you notice that no one speaks up about additional audience research, or asks why this content needs to be published. Start asking “why” yourself—all the time, genuinely.
- Do your research. Look for analytics, case studies, or real-world examples to show that these ideas have worked elsewhere, then put together a plan for your own pilot project. For example, you might suggest taking two days to do more detailed audience research for a particular web page or small section redesign.
- Demonstrate critical thinking. Know what your goals are with the pilot project. How will the additional research help? What questions are you trying to answer? How can you apply the research to the design? What metrics will you use to test the results?
- Create a safety net. Pitch your project as an experiment (or, if you have the freedom, implement it regardless). Ideally, you’ll demonstrate the business case for more research, get some time to try it out, and then allow the work to speak for itself. When decision-makers can see the benefits to the users and the team, it may become a permanent part of the process.
What’s in a name?#section6
Names and naming conventions seem like such innocuous, inconsequential details in designing web experiences. But without getting that right, we potentially prevent people from completing forms or executing tasks. We become responsible for telling users that they do not exist or are not valid. How is that improving the web or making it easier to communicate and get things done?
A busy designer or developer can be forgiven for not knowing the nuances of every piece of the mosaic that is the Hispanic-American group. I certainly don’t know, and I’m a member of it.
But we can learn to ask ourselves what we don’t know, and understand concrete aspects that help us do our jobs more thoughtfully. Starting with learning something consistent about the mosaic of “Hispanic-American,” like a naming system, and applying what we learn to our work—such as making forms more accommodating—is a step in the right direction. That direction is toward a strong multicultural awareness, which we all need to do our best work in an increasingly diverse society.
While you do that, I’m going to go talk to Spain about their habit of duplicating people’s single last names to fit their government forms, which require two surnames. (Sarah Smith Smith, anyone?)