Your client knows more than you do. That's the point.

Process · 5 min read

I had a client who'd worked in industrial safety across three continents. He'd spent years in the Middle East working at petroleum and energy production sites. He understood insurance policy requirements, fire brigade notification protocols, sprinkler impairment rules, and the specific compliance standards for manufacturing, mining, retail, and construction. He could tell me which industries to target first and why. He knew the difference between a hot work permit and a confined space permit and could explain the entire workflow for each.

I knew none of that. And that's completely fine.

My job was not to become an industrial safety expert. My job was to take everything he knew and turn it into an app that a worker could use on a phone while standing in a boiler room. Those are two very different skills and neither one replaces the other.

The domain gap is a feature

When I'm sitting in a meeting and the client starts talking about impairment notices, fire system shutdowns, and insurance escalation protocols, I'm not pretending to keep up. I'm listening and asking questions. "How many photos would they take during a job?" "Would you prefer hours or minutes for the time estimate?" "If the system goes offline for more than 24 hours, what happens next?" Those aren't design questions. They're industry questions. And the client is the only person in the room who can answer them.

That gap between my knowledge and theirs is actually what makes the design better. Because I don't understand the jargon intuitively, I have to simplify it. I have to ask what things mean. I have to figure out how to present complex workflows in a way that someone with no training can follow. If I already knew the industry inside out, I'd be tempted to design for experts. But the end users aren't experts. They're workers who need to get through a process quickly and correctly.

Your job is translation

Think of the designer's role as translation. The client speaks industry. The user speaks taps. The designer is the bridge. In our case, the client described a process that involved safety checklists, timed inspections, photo verification, escalation protocols, and compliance reporting across multiple sites. That's a lot of complexity. On the worker's phone, it became a card with a task, a timer, and a camera button. That translation is the work. Taking something genuinely complex and making it feel simple without losing any of the rigour.

The best apps I've designed have come from clients who know their industry far better than I ever will. The NDIS professional who could describe exactly what a support worker needs to see on day one. The industrial safety specialist who could walk me through fire brigade notification protocols step by step. The more the client knows, the better the raw material I have to work with. My job is to shape it into something that works on a screen.

Respect the expertise you don't have

If you're a first time app builder, this is important. The designer or developer you work with should be asking you lots of questions about your industry. Not because they're unprepared. Because they respect that you know things they don't. If someone comes in and tells you they already understand your industry after reading a few articles, be careful. Understanding an industry takes years. Understanding enough to design the interface takes good questions and honest listening.

Your knowledge is the reason the app will be good. The designer's skill is making that knowledge accessible to someone who has never worked a day in your industry. That combination is what makes apps built by subject matter experts so much better than apps built by people guessing from the outside.

Sources
Domain Expertise in UX (Nielsen Norman Group) - How deep industry knowledge shapes better user experiences when combined with design methodology.
Why Design Thinking Works (Harvard Business Review) - The value of empathy and deep user understanding in the design process.

Related blog posts:

Why subject matter experts build the best apps →

Why your app shouldn't speak your industry's language →

What happens on the first call →