Some of the hardest UX problems I’ve worked on were not really interface problems.
They showed up in interfaces, of course. A user had to jump between views to piece together information. Two groups were using the same product in completely different ways. Someone was copying a value from one part of a system, pasting it somewhere else, and manually rebuilding context the product already technically had.
It would have been very easy to look at those moments and say, “This screen needs to be better.” Sometimes that was exactly right.
But sometimes the screen was just where a deeper problem finally became visible.
The actual issue might have been an unclear information model, a workflow crossing ownership boundaries, two systems representing the same state differently, or a process that had accumulated so many exceptions over time that nobody could quite explain how the whole thing worked anymore. Sometimes an entire team was compensating for missing structure with spreadsheets, Slack messages, tribal knowledge, and the heroic memory of one person everyone hoped would never take PTO.
At that point, polishing the interface helps, but only so much. You can organize the junk drawer beautifully. You still have a junk drawer.
Start with the job, not the screen
One of the most useful habits I developed as a product designer was learning to stop asking only, “What does the user need on this screen?”
The more useful question is usually: What are they actually trying to accomplish, and what work are we currently making them do in order to get there?
That changes what you are designing.
Maybe the user is an analyst trying to reach a confident decision, but the evidence they need is scattered across different parts of a platform. Their actual experience is not any one of those screens. It is the entire path they have to travel, the information they have to remember along the way, and the mental assembly work required to turn all of it into an answer.
The same thing happens inside organizations. A product team may need to understand whether something is actually ready to move forward, but the answer lives across planning documents, status fields, meeting notes, Jira tickets, and whichever coworker happens to remember what was decided last Tuesday.
Those sound like completely different problems. In both cases, though, someone is being asked to assemble a story that the system should be helping them understand.
That assembly work is part of the user experience.
Sometimes the friction lives between things
Interfaces are good at making local problems visible. The harder problems often live in the connections.
An object means one thing in one part of a product and something slightly different somewhere else. Two user populations share the same surface but need different defaults, permissions, or workflows. A process has ten documented steps, but nobody has modeled the decisions that actually move work from one state to another. Several teams technically agree on a lifecycle, except that each of them appears to be using a slightly different lifecycle.
This is usually the point where I start mapping things.
Not because every difficult problem needs an enormous diagram with seventy-three boxes and arrows. Nobody has ever looked at a wall of arrows and thought, “Wonderful, our lives are simpler now.”
Mapping is useful because it forces implicit structure to become explicit. What are the actual objects in this system? What states can they be in? Who can act on them? Where does information originate? Where does it disappear? Which handoffs are intentional, and which exist because the organization slowly grew around them?
Once those relationships are visible, “the UX is confusing” often turns into something much more specific.
Maybe two workflows disagree about the source of truth. Maybe a user can see a state but cannot act on it. Maybe the system already knows something important but makes the user carry that information manually into the next step anyway. Maybe a process works only because everyone involved has learned a collection of exceptions that exist nowhere except in documents, meeting notes, and people’s heads.
That is usually where I stop thinking only about what needs to change on the surface and start asking what structure the experience is missing.
Does the system need a clearer definition of its states? Does information need to persist differently as work moves from one place to another? Are two teams actually describing the same thing with different language, or are they making genuinely different decisions that we have been pretending are equivalent? Is ownership unclear because the interface hides it, or because nobody ever actually decided who owns what?
The artifact at this stage might be a journey map, an architecture model, a service blueprint, a workflow diagram, or something much uglier that exists purely to help everyone think. The useful part is not the diagram itself. It is getting enough of the system out of everyone’s heads that we can finally see what we are asking people to compensate for.
That is still design work.
The solution may not be a screen
This is also where the boundaries between Product Design, Design Operations, Product Operations, and product strategy start becoming much less interesting to me.
Those disciplines have different responsibilities, and I am not pretending they are interchangeable.
But the problems themselves have an annoying habit of refusing to stay inside the org chart.
If people are struggling because the interface is unclear, the interface should change. But if the same confusion keeps appearing because two parts of the product use different definitions of the same state, fixing one screen does not resolve much. At some point, somebody has to figure out what that state actually means, when it changes, what information belongs with it, and which parts of the system need to agree.
The same thing happens with internal product work. If several teams are maintaining their own interpretation of a lifecycle, adding another document may make the disagreement easier to read without making it any less of a disagreement. The more useful work may be sorting out which decisions are actually shared, where teams genuinely need flexibility, what information has to move with the work, and how the tools people use can reflect those decisions without requiring constant manual reconciliation.
That might end in a product change. It might change a workflow, the way information is structured, the states a system recognizes, or how work moves from one group to another. Often it is some combination, because real systems are rude like that.
What matters to me is that the solution follows the source of the friction.
If a user is manually carrying a hostname between two views, I want to know why. If a team has to compare three places before they can tell whether something is ready, I want to know why. If everyone has built a perfectly reasonable workaround around the same missing piece of structure, I am probably going to become much more interested in that missing structure than in making the workaround prettier.
That is the part of UX work I find hardest to contain inside the UI. Once you understand what someone is trying to accomplish, you sometimes have to follow the problem farther than the screen where you first found it.
Solving the thing that is easiest to see
Of course, knowing a deeper problem exists does not mean you always get to solve it immediately.
There is a reason organizations gravitate toward interface fixes. They are tangible. You can put the old screen and the new screen next to each other in a deck. Everyone can see what changed. Someone can circle a button or point to a cleaner hierarchy and say, yes, this is better.
Structural problems are harder to package that way.
They tend to cross team boundaries. They expose inconsistencies that were easier to tolerate while nobody had to name them directly. They may require Product, Design, Engineering, Operations, or leadership to agree on something the organization has managed to avoid agreeing on for years.
And sometimes the deeper fix simply is not available yet.
That does not make near-term design work pointless. A small change can make someone’s day meaningfully easier even if the system underneath it is still messy. Good product work often means improving what is in front of the user now while understanding enough about the underlying problem that you do not accidentally make it harder to fix later.
Sometimes you make the workaround less painful because that is the change the organization can support today. I have no problem with that. I just want us to know it is a workaround.
There is a meaningful difference between helping someone rebuild context faster and asking why they have to rebuild it in the first place. Both can be useful work. They are just solving different layers of the problem.
Following the problem
Over time, this is how more of my work moved beyond traditional product surfaces and into workflows, operating models, planning systems, knowledge architecture, and the systems teams use to build and deliver products.
Those things look pretty different on paper, and I did not sit down one day and decide I wanted to make my job harder by wandering into all of them.
Usually, I got there because I was following the problem.
If the thing making an experience confusing was a screen, I worked on the screen. If the same confusion kept showing up because three teams meant slightly different things by the same status, that became the problem. If people were maintaining the same information in multiple places and hoping it stayed in sync, I followed that too.
The question underneath all of it has stayed pretty consistent for me: what is someone trying to do, where is the system making that harder, and what is actually causing the friction?
Sometimes the answer is a product experience. Other times it is a workflow, a shared model, a tooling change, or a decision about how information should move between people and systems. And yes, sometimes the button really is just in the wrong place.
I care less about which category the solution falls into than whether we are solving the thing that is actually getting in the user’s way.
The interface is often where I first see the problem. I just do not want to decide that it is the whole problem before I have followed it far enough to know.