Application Design
How I Think About Building Tools for Non-Technical Users
Most tools don’t fail because they lack features. They fail because they make sense to the person who built them, not the people who use them.
Most of the tools I build are used by two groups: internal staff and the general public. Neither group is technical in the way developers or GIS professionals are, and that gap shows up everywhere.
The Core Problem: The biggest issue isn’t intelligence. It’s understanding. Public users don’t always know what we do, why we do it, or what the data actually means. Internal users often have deep domain knowledge but not technical knowledge, especially when it comes to GIS, systems, or data structures. When something doesn’t make sense, it’s not because the user failed. It’s because the tool did.
Where Things Go Wrong: Many tools are built to make sense to the person building them, not the person using them. This is especially common in GIS applications. You see detailed maps, layers and tools everywhere, no explanation of what anything does, and no context for what the data means. To a developer or GIS professional, it may feel intuitive. To everyone else, it’s noise.
What I Prioritize Instead: Clarity over capability. You can build the most powerful tool in the world, but if users don’t understand it, it doesn’t matter. That means explaining what something is, why it exists, and guiding users on what to do next. Not just exposing functionality and expecting them to figure it out.
How I Approach It: I try to step outside of my own perspective. The simplest way I’ve found is to think about how my wife would use it. She’s smart, capable, and representative of a typical public user, but she doesn’t live in GIS, systems, or government data. If something wouldn’t make sense to her, it’s probably not clear enough.
One Rule I Follow: Sit with a non-technical user after your first pass, every time. It exposes blind spots immediately. Things that felt obvious during development suddenly aren’t, and those gaps are exactly where most tools fail.
The Bottom Line: Building for non-technical users isn’t about simplifying everything. It’s about making sure what you build actually makes sense to the people it’s meant for.