What senior citizens taught me about designing apps

On Monday, I taught a group of approximately 30 senior citizens (average age around 65) how to use their iOS and Android devices. I’ve always really enjoyed teaching, so when I was presented with the opportunity, I became extremely excited. Some people might shy away from these sort of classes, for fear of frustration, but I’ve always been curious about what some of my colleagues consider the lowest common denominator when it comes to understanding modern handheld devices (I’ve heard someone ask themselves, at least once, whether their grandma would understand the design of an app).

For many of these students, they had only had their phones for a few weeks. For some, a year. There seemed to be a common theme amongst the reason that they chose to attend the class. They were overwhelmed by the amount of different interactions that they didn’t think they could accomplish. In fact, at the end of the class (we got so far as installing Facebook and Skype and setting up an account on each), one student was convinced that I must have earned myself a Masters Degree in a related field in order to understand the content I taught.

Problems that were presented when trying to do simple tasks such as adding a friend to their contacts, or finding their email accounts, repeated themselves quite frequently. This was a result of quite a few patterns repeating themselves in the design of the user interfaces of the apps that were used. This list might seem like it’s obvious to many, but might be useful (or at least anecdotal evidence for already quantified data).

1. Make sure to have reasonably-sized tap areas.

We started with the basics. I showed them how to connect to WiFi, which was probably the most difficult out of everything. The WiFi icon on most smart phones is extremely small, and a lot of the students who had deteriorating eye sight had trouble telling what it was and if they got disconnected, many couldn’t see the (usually) greyed out symbol at all.

2. If an item needs to be small, make sure that it contrasts well against the background, in every state.

The lack of contrast when the WiFi icon was greyed out made it really difficult for some of these users, which really highlighted how much color choices matter. I don’t think it would be a great idea to increase the WiFi symbol on most phones, but I do think that it might be useful to let a user know via a toast message if they have connected to or have been disconnected from a WiFi signal.

3. Analogies are extremely useful.

I then showed the smartphone users how to make a phone call. This was easy for most to do when they were entering the phone number in by hand. I then showed them how to add a phone number to their contacts list directly from the phone app (this process is nearly identical across both iOS and Android devices in terms of UI). This was more difficult, because again, the text was small, and the interaction area was equally as small. Small interaction areas proved to be difficult for those who weren’t accustomed to using touch devices. Most of the students who had issues seemed to approach their phones clumsily, intimidated by the wealth of knowledge that they hoped I had about their device and how much they hoped to take in in the class.

One of the main things that I told them, that seemed to help greatly, was that often designers chose certain icons and conventions based on analogies to older technology. I didn’t get into what skeuomorphism is, as I didn’t think it was the time to really expand upon the subject – but it seemed to me that perhaps, for these particular users, it would be useful. Simply being able to associate the image of an envelope to their email accounts was helpful, does this translate to the overall interface? Are we moving in the wrong direction with “flat” design? I love the cleanliness that is trendy in design right now, but this experience certainly makes me curious.

4. Common interactions should have common language.

In some of the apps that we used, basic interactions that were core to the utility were labelled with different language. “Add Contact” and “Add Friend” were used interchangeably in some cases. This was confusing for new smart phone users, as they questioned what the difference between a friend and a contact was – even if there wasn’t a difference at all.

5. Once a user is shown how to do something, they’ll likely remember. If they aren’t shown, they’ll likely be overwhelmed and feel lost.

The Drawer. We all have come to know and love the drawer. In some apps, there was no icon to initiate the drawer, and thus some (often core) interactions weren’t apparent to new users. I’m sure there are other examples of hidden interactions (the OS-based search in iOS is a pretty good example, actually). Simply showing the user where the navigation or interaction is hidden helps a lot. Once my students were shown the drawer in a particular app, they knew where it was and were ready to explore it.

6. Communicate with users why you need to access their data.

Why do you need to send them push notifications? Why do you need access to their photos? These were common questions that students asked about apps when they first installed them and began to play with them. Clearly stating what the data will be used for (and in some cases what it won’t be used for) removes any misunderstanding between you and your user.


Of course, none of this is concrete and is completely anecdotal. Yet, I theorize that through user testing these tips would show fairly useful. Many of them have been stated, I’m sure, in accessibility guidelines, but it’s nice to have a reminder every once in a while.

I’m excited to keep teaching this class and learn from my students, and would be curious about others experiences of learning through teaching!


This post was cross-posted to Medium. I’d appreciate your recommendations!