It started as a simple request, “Can you help me send an email to a friend.” Something most of us reading this have done countless times, but it was a new experience for my 89-year-old grandfather. He has always been pretty resistant to new technology. As a survey engineer, he drew site plans by hand long after most of his peers worked digitally. Today, he is retired and prefers newspapers and television over the internet and cell phones.
He’s not the only person in this position. According to a 2018 National Center for Education Statistics study, 16% of US adults are not digitally literate. International numbers are even higher at 23%. In the US, only 61% of adults over 65 own a cell phone. It’s easy for those of us in tech to ignore these numbers and assume that everyone using our products is familiar with technology.
As someone who uses digital technology every day for work, I have a strong natural bias toward designing and building products that cater to the technologically literate. This is a hard habit to break. Helping my grandfather send an email challenged some core assumptions I’ve made in my approach to design.
An easy solution?
Typically, the answer to the problem of not understanding our users would be user testing so that we can build empathy and test our assumptions. In an ideal world, we’d test our products with a diverse audience that includes folks who are not digitally savvy. Still, this can be difficult in practice since that audience isn’t typically signing up for user testing platforms and digital research studies.
When the ideal is not possible, we should do the second-best thing and educate ourselves so we can begin to build empathy. Even if we cannot test every user flow with a non-tech-friendly audience, we can still learn a lot about general patterns we should follow and apply to our work.
Here’s what I learned about designing software for non-tech literate folks by observing my grandfather sending an email.
Affordances are important
Design affordances or the clues that indicate the purpose of an element are very important. Many applications reduce UI elements to their most basic form to save space and reduce clutter, for example, by removing text labels on buttons. This can easily create confusion for all users. My grandfather couldn’t figure out how to send an email because the “send” button was not called out in any way, it didn’t look like a button so it was hard to find on the screen.
Another issue he ran into was that the UI was so “flat” that there was no distinction between the text input fields for the email subject and body. In a completely flat interface, he didn’t know where he was supposed to type.
Reduce dependency on tech-specific language
Much of the visual language for UI design is based on the real world. Email is mail, and folders are folders. But imagine trying to explain a hamburger menu icon to a non-tech user. What might be obvious to you is likely not clear to someone else.
To reduce confusion, we should reduce our dependence on iconography alone to communicate. Text labels go a long way toward adding clarity. The email application my grandfather was using had a side navigation that used icons with no text labels, making it impossible for him to find the emails he had sent. Icons can quickly create confusion if their meaning needs to be clarified.
Balance new features with simplicity
Designing software for a broad audience takes work. Power users expect a very different experience compared to first-time users. I believe the clearer the UI, the better the experience will be for all users. We should be careful about adding new features that aren’t essential to the core experience. How are those features explained, and where do they belong on the screen? Progressive disclosure, clear information architecture, and strong hierarchy are important principles when it comes to maintaining clarity in an increasingly complicated UI.
Everyone is a first-time user at one point, and we should design for that experience without relying on things like product tutorials that are usually seen once. Balance means adding features for power users without inadvertently confusing first-time users.
Be clear
Don’t make me think. No, really. The best UI is the UI that no one notices because it’s so simple. Clear and straightforward UI helps users who are not familiar with the software. My grandfather needed to physically write down every step for sending an email so he could repeat the process on his own. He listed everything from how to turn on his “machine” to where to look for responses to his email. We should strive to make our products so simple that new users don’t need to write down how to use them.
Personas can be dangerous
Personas are great at defining a target audience but can be dangerous if we over-index them. They’re meant to form a single identity to “target,” which naturally excludes people who may use our products but don’t happen to fit a certain demographic mold. Our users will have diverse cultural, economic, age, gender, and tech-literacy backgrounds, along with many other factors. These differences may mean the products we design are significantly more complicated to use for those who don’t fit our target persona. We should be careful not to inadvertently exclude folks by relying too heavily on a single persona.
The next time you are working on a digital product, remember, not everyone using it will be a digital native power user. We should do our best to pause and experience our products through their lens. Put aside the keyboard shortcuts and maybe help a non-tech person send an email to see the digital world through their eyes.
For additional resources on the topic of ageism in tech, see this thoughtbot article Software for all ages: tackling ageism with industry experts.
Check out our past projects with Airrosti, Groups Recover Together, and Relias to learn more about how we approach the design process with empathy and inclusivity.
If you are interested in discussing your current design process or need help uncovering the right product strategy and market fit, send us an email. We would be happy to help.
