Good UX does not always produce a journey map, service blueprint, or polished deliverable. Sometimes knowing when not to create one is part of the design judgment.
I was recently interviewing for a Staff Product Designer position at a company I will not name. During the conversation, I spoke in detail about the strategic and operational work I have spent the past three years doing with small businesses and solopreneurs.
We talked about unblocking bottlenecks, identifying revenue leaks, diagnosing why prospective customers dropped off before completing a sale, and streamlining internal workflows so founders could stop drowning in repetitive manual work.
After we walked through some of this work, one of the interviewers said something along the lines of, "Lorraine, we can definitely see that you have the ability to think strategically. We can see the strategic work in what you've been showing us. But do you have any visuals you can show us?"
I was confused.
"Visuals? What kind of visuals?"
"Service blueprints, customer journeys..."
The question struck me as strange.
They had already told me they could see the strategic thinking. They understood the problems I had been solving and the decisions behind the work. But there still seemed to be an expectation that somewhere behind all of it there should be something recognizable and visual that made the strategy tangible.
That expectation stayed with me after the interview. I was not questioning the value of customer journeys or service blueprints. I was questioning the assumption that strategic UX work should necessarily produce one.
Over the course of my career, I have created plenty of them. I have facilitated multi-day workshops, synthesized messy qualitative research across disparate business units, aligned cross-functional teams, and mapped complicated enterprise systems end to end. I know when these tools are valuable because I have seen them do exactly what they are intended to do.
But I have also learned that knowing how to create something and knowing when it is necessary are two very different skills.
What struck me about the interview was the assumption that this type of documentation would naturally be part of the work I was doing with an independent business owner.
Why would it be?
A small business owner rarely comes to me asking for a service blueprint. They come to me because they need to make more money, acquire more customers, stop losing qualified leads, reduce the overwhelming volume of tasks they are managing by hand, or figure out why a system that looked fine on paper is failing in the real world.
Their objective is not to assemble a binder proving that proper UX rituals were observed. Their objective is to run a viable, profitable business.
That interview made me reflect on an issue I have seen throughout my career in product design: sometimes we become so accustomed to the process that we stop asking whether every part of it is necessary.
When Process Becomes the Product
In enterprise environments, process can easily become the product.
Large corporations operate with distributed risk, sprawling organizational structures, and dozens of cross-functional stakeholders. Documentation frequently functions as a universal translator. It can also function as organizational armor.
We conduct generative research, develop archetypes, synthesize personas, draft journey maps, build service blueprints, chart user flows, and compile presentations to explain what we learned and why we recommend a particular course of action.
In that environment, all of those deliverables can have legitimate utility.
They bridge communication gaps between product management, legal, compliance, engineering, marketing, operations, and executive leadership. When you need seventy people across four time zones to understand the same problem, a shared representation of that problem can be enormously useful.
I have used these methods, and I will continue to use them whenever they genuinely help clarify complexity or enable a group to make better decisions.
The breakdown happens when the deliverable ceases to be a means to an end and becomes the end itself.
A journey map is a tool. So is a persona, a research study, a prototype, or a workshop. Their value comes from what they help us understand, decide, change, or improve.
Producing them is not, by itself, the outcome.
What Does the Business Actually Need?
If I spend an afternoon analyzing an independent founder's intake workflow, trace where prospective clients are abandoning an inquiry form, identify a clumsy mobile layout and unnecessary questions as sources of friction, and simplify that flow, I have something actionable to put in front of the business.
I do not automatically need to stop there and spend the next two weeks rendering that understanding into an immaculate, color-coded Figma file.
What would that accomplish?
If three people touch the process and all three understand the problem, extensive documentation may not improve the decision. It may simply formalize something we already understand.
At that point, I am adding process without adding much value.
Sometimes you genuinely need the map because the terrain is unfamiliar, the dependencies are obscure, and the team needs a shared understanding.
Sometimes you already know where you are going.
When you already know where you are going, insisting on drawing the map first is not necessarily thoroughness. Sometimes it is hesitation disguised as methodology.
Context Changes the Process
That distinction becomes critical when working with solo business owners and small teams because every additional layer of process carries a cost.
A solo operator does not have a dedicated research department, an enterprise UX division, a business strategy team, and an operations department. In many cases, one person is handling customer service, marketing, fulfillment, vendor relationships, and bookkeeping while also trying to generate enough revenue to keep the business operating.
When we introduce enterprise-style processes that do not contribute to the decision at hand, we are not raising the business's standards. We are consuming resources it cannot easily replace.
Yet many of the practices we teach and reward in the design industry were developed in environments with considerably more people, money, specialization, and organizational complexity than a small business possesses.
That does not make those practices wrong.
It makes context important.
A framework that helps coordinate a large organization may be unnecessary for a three-person company. A research exercise that reduces the risk of a multimillion-dollar product decision may be excessive for a founder testing a reversible change this afternoon. A detailed map that creates alignment among six departments may add little value when everyone involved in the service can sit around the same table.
Knowing the difference is part of the job.
The Artifact Is Not the Thinking
This is where the disconnect in my interview became interesting.
They had already told me they could see the strategic thinking. Yet there was still a desire to see something that represented it visually.
When we evaluate strategic impact primarily through familiar deliverables, we risk confusing evidence of process with evidence of judgment.
We ask to see the map without first asking whether the map was necessary.
Perhaps we should ask different questions when reviewing the work of experienced designers.
Not simply: What did you make?
But: Why did you decide that was the right thing to make?
And sometimes: Why did you decide you did not need to make it?
There is considerable judgment involved in that decision.
A designer can follow every prescribed step of a process and still arrive at the wrong solution. Another can recognize that the team already has enough information, remove an unnecessary step, make a relatively modest change, and solve the problem.
The second designer may have less to put in a portfolio.
That does not mean less design happened.
Design maturity is not the ability to generate a 40-page deck or an elaborate service blueprint on command. It is having the commercial awareness, contextual understanding, and judgment to know when deeper documentation is necessary and when a direct conversation, a deleted step, a rough sketch, or a pragmatic operational change will accomplish more.
Seniority should not be measured by the weight of the documentation we leave behind. It should be visible in the quality of the decisions we help people make, the constraints we recognize, the resources we respect, and the durability of the results.
So, where was my service blueprint?
There wasn't one.
The business didn't need it.
The problem was understood. The decision was made. The work moved forward.
Sometimes good UX leaves behind a journey map, a prototype, a research report, or a service blueprint.
And sometimes good UX leaves behind a business that simply works better.