Designing for low literacy: the interface begins with the community

During one of our community co-design meetings, pastoralists drew icons in the sand.

They were not rough versions of icons we had already designed. They were showing us the images that made sense to them: a visual vocabulary grounded in their surroundings, their work, and the way they understood the information InfoRange needed to present.

Our job was to listen, carry those drawings back to the UI/UX design process, and translate them into interface assets that could work on an Android screen.

That moment captures the most important lesson I learned while implementing InfoRange for pastoralist communities in Northern Kenya: designing for low literacy is not simply a matter of removing text. It is about finding, with the community, a usable combination of communication channels.

For InfoRange, that combination became text, native-language audio, community-designed category icons, and color-coded map pins. None of those channels had to carry the entire interface alone. Together, they gave more users a way into it.

The first icons were obvious—to us

Our early icon concepts looked clear to the product and design team. We thought many of them were self-explanatory.

Then we put them in front of the people who would use the app.

Rather than explaining an icon first, we asked community members what they thought it meant. Most of the initial icons we considered obvious were not understood as we intended. The problem was not that the drawings were poorly executed. The visual references behind them belonged to our design vocabulary, not necessarily to the communities’ vocabulary.

That distinction matters. An icon is not inherently intuitive. It becomes recognizable through a person’s experience, environment, and learned associations. Calling an icon “universal” can hide the fact that its supposed universality has only been tested among people who already share the designer’s references.

So we changed the process. Community members did more than react to finished options: they drew the icons they wanted in the sand during co-design meetings. We listened to the symbols and color associations they already used, worked with the UI/UX team to turn that input into production designs, implemented the assets in the app, and returned for feedback after implementation.

This was not a formal usability study, and I do not want to turn qualitative feedback into a metric we did not collect. What we can say is that the designs were shaped through repeated interpretation, revision, and post-implementation feedback with the people who would rely on them.

Icons and colors do different jobs

The resulting visual system is not one undifferentiated layer of “pictures.” Its parts serve different purposes.

Category icons help users recognize different report types. Colored backgrounds on map pins reinforce those categories and make related reports easier to scan. For example, different shades of red are used for disease and wild-animal reports.

The point is not that red has one universal meaning. It is that these associations were discussed and refined with the community instead of being chosen only from a generic design system or stock icon library.

That is the middle ground we were looking for: text can remain useful for people who read it, while the icon and color system gives users another way to identify what is on the map. Low-literacy design does not require pretending that a single symbol can communicate every detail. It requires being deliberate about what each channel contributes.

Put the explanation where the user needs it

Icons and colors improve recognition, but they cannot explain the full purpose of a feature. For that, InfoRange uses audio.

Each main feature includes an ear icon. When a herder taps it, the app plays an audio explanation of that feature in the selected native language. The current languages are Rendille, Borana, and Samburu.

We began with English transcripts, then worked with literate community members to translate the explanations into the local languages. That participation matters for the same reason the sand drawings matter: changing the medium is not enough if the meaning is still produced entirely outside the community.

The response was encouraging. In feedback gathered during co-design meetings after implementation, users appreciated hearing the app explained in their own language. I would not stretch that response into an unmeasured claim about task completion rates. It is still meaningful evidence that language and voice can make an interface feel more approachable.

Accessibility features have to work offline

InfoRange operates in places where cellular connectivity can be absent or intermittent. Streaming an explanation only when the ear icon is tapped would make the feature least reliable in the environments where the app is actually used.

The app therefore downloads the audio for the user’s selected language in the background and caches it on the device. Once available, the explanation can play reliably without a connection.

This is where a UX decision becomes an engineering requirement. If audio is one of the channels that makes a feature understandable, its offline availability is not an optional enhancement. It is part of whether that feature is accessible at all.

Co-design changes who gets to define “intuitive”

My main role on InfoRange was implementing the Android app. I also helped coordinate the icon work with the UI/UX design team. That put me at the point where community knowledge had to survive the journey from a conversation—and a drawing in the sand—into a consistent digital interface.

The technical work mattered, but it came after a more important decision: the people using the app had authority over what its visual language should mean.

The lesson I would carry into another project is not “use audio for every low-literacy audience” or “icons are better than words.” Both statements replace one assumption with another. The stronger rule is:

When an interface’s primary communication channel excludes part of its audience, work with that audience to find the combination of channels they can use—and then engineer each one as a real part of the product.

For InfoRange, that meant retaining text while adding native-language explanations, replacing supposedly obvious icons with community-authored visual references, using color to reinforce categories on the map, and caching audio so the whole approach still works offline.

The interface did not begin in Figma or Android Studio. It began when we stopped assuming we already knew what people would understand and gave the community room to show us.

The constraints in this piece come from an offline-first Android app I led for the arid rangelands of Northern Kenya and Namibia. The broader engineering story — offline maps, encrypted local storage, background synchronization, and battery-aware GPS collection — is in the InfoRange case study.