From ad hoc design support to a repeatable UX function

The organization did not simply need more design output

UX work was happening.

But UX was not yet functioning as a reliable part of how the organization learned or made product decisions.

Teams could move forward without regular user validation. Design rationale was not always preserved. Customer-facing groups held valuable knowledge that did not consistently reach UX or Product. Different functions had different assumptions about what UX was supposed to contribute.

Some people primarily associated UX with visual interface design, which kept the function focused on outputs rather than the decisions that shaped them.

UX remained downstream while decisions about workflows, requirements, priorities, and customer needs were made elsewhere, creating a risk that product work would proceed without enough customer evidence.

I researched the organization before designing the function

I treated the organization itself as the first research subject.

Before introducing new processes, I needed to understand how work currently happened, where product decisions were made, how customer feedback reached product teams, where customer knowledge existed, what previous UX efforts had looked like, what people believed UX was responsible for, and who could advocate for stronger practice.

I conducted interviews with more than 20 stakeholders across Engineering, Product Management, Solutions Architecture, Marketing, and Customer Support, and paired the findings with a UX maturity assessment.

Three patterns appeared consistently.

Usability testing was not dependable

Testing happened, but it was sporadic.

Teams could make design and product decisions without regular validation from users, and usability testing was not yet part of a predictable product-development rhythm.

Collaboration was fragmented

Different functions had valuable context, but they did not always have visibility into one another’s work.

Design decisions could happen without enough input from Product, Engineering, Support, or customers.

UX and UI were often treated as the same thing

Many people understood UX primarily through interface design.

Research, workflow design, service thinking, discovery, validation, and UX strategy were less visible parts of the discipline.

Those findings showed that improving UX would require more than adding methods or deliverables. I considered three ways the function could evolve.

Three possible directions

1. Introduce a formal UX process

This could create consistency across discovery, research, design, validation, and handoff.

The risk was adoption in a lean organization where a stage-based process could feel like overhead.

2. Continue project-by-project support

This required the least organizational change.

The risk was that UX would remain reactive and dependent on individual projects and relationships.

3. Build lightweight decision infrastructure

This became my direction.

I documented a structured research plan and introduced smaller mechanisms that improved the quality of decisions teams were already making, including earlier stakeholder participation, prototype research before implementation, and shared records of findings and rationale.

The goal was to create enough structure for continuity and customer focus without enough process to become a barrier.

The strategy was shaped by what the organization was ready to adopt

Structure vs. speed

The organization needed more structure around UX.

But I did not believe a rigid, linear design process would survive contact with the way the company actually worked.

I adopted a spiral model and used it to organize the research plan.

Research, design, stakeholder feedback, and engineering input could happen in recurring loops rather than through formal handoffs after UX was finalized.

The model gave UX more visibility and repeatability while remaining compatible with agile product work.

Education had to change behavior

Explaining that UX was more than UI would not change how the organization worked.

People needed shared reference points they could use without UX being present in every conversation.

I updated the internal UX function page and created educational material that clarified the difference between UX and UI while making methods, diagrams, frameworks, and examples easier to access.

The resource gave UX advocates something concrete to use with their own teams and made the function less dependent on one person repeatedly explaining its purpose and value.

Documentation had to stay usable

The lack of documentation was creating organizational memory loss.

Research findings could disappear. Prototype history was difficult to trace. Decisions could be revisited because the rationale behind them was no longer visible.

At the same time, I knew that documentation could become another process people ignored if maintaining it required too much effort.

I limited each project record to what a new contributor needed: who was involved, what we learned, what changed and why, the cross-functional challenges we faced, and the prototype history.

The goal was not documentation for its own sake. It was to create continuity.

Research rigor had to match organizational readiness

I wanted usability testing to become a normal part of the product-development rhythm.

That required more than running studies more often. Research needed to happen early enough to shape the work, and teams needed to understand how to participate.

I began testing prototypes with users before full implementation, while the team could still respond to what we learned.

I also created clearer guidance for stakeholders participating in usability studies and invited more cross-functional partners to observe the sessions.

Stakeholders could watch users work through problems rather than relying only on findings delivered secondhand.

Research became something teams could experience together.

This reduced the risk of late surprises, avoidable rework, and confusion during implementation.

Customer knowledge already existed. It was simply scattered.

Customer Support, Product, Customer Success, Architects, and other customer-facing teams already held valuable information about user problems.

The issue was that the feedback existed in different places, at different levels of detail, with no consistent mechanism connecting it back to UX and product decisions.

I established recurring meetings with Support to connect UX with the issues customers were raising.

I also worked with Product to build more direct customer feedback loops within the product. That work led to an in-product feature associated with improved user retention.

From there, I introduced a Voice of Customer program to capture user sentiment and evaluate feedback around feature releases.

Journey mapping made a system visible

I applied the approach to the experience of migrating workloads, where time to value depended on more than an individual screen.

I facilitated workshops to create a comprehensive journey map of the end-to-end experience.

The map showed what users were trying to accomplish, where they encountered friction, and where the organization could make targeted improvements.

I also introduced a grid that placed perspectives from different departments alongside the same user pain points.

That gave Product a shared way to break down problems that had previously been understood separately across teams.

This connected research, prototype versions, stakeholder feedback, decisions, and next steps to the customer experience they were intended to improve.

That made the rationale behind a change easier to follow. It also made the work easier to continue when someone new entered the project.

Design rationale became something the organization could refer back to rather than rediscover.

The UX roadmap was not simply a backlog of design work

The maturity assessment established a baseline for the function and helped me set goals for how it needed to grow.

I translated that direction into a UX vision and a roadmap covering key features, concerns, and areas requiring research or design attention.

The roadmap gave UX a clearer point of view about where to lead, where evidence was missing, and where customer needs should influence product direction.

That moved the function from reacting to requests toward participating more deliberately in what the organization chose to address.

Evidence of organizational change

The evidence was behavioral. Interviews and the maturity assessment created a baseline. The research plan brought different functions into the work earlier, while prototype research introduced user evidence before implementation. Support touchpoints, journey mapping, project records, and the Voice of Customer program connected knowledge that had previously been scattered.

The cross-functional research pod and UX leadership on a revenue-generating feature showed that these practices could support delivery while keeping both functionality and user needs in view.

Together, the mechanisms began to make customer-centered decision-making more repeatable.