Growing UX maturity: introducing user-centred thinking in a development team
Changing how a software team talked about users.
Note
Due to confidentiality agreements with the employer, specific metrics and detailed screenshots cannot be shared. This case study focuses on process and approach.
When I joined the company as a front-end developer, UX wasn’t part of the development process. Features were discussed in terms of requirements, technical feasibility, and business priorities. Users were present in conversations, but mostly as an abstract concept. As the product stabilised after a major platform migration, I saw an opportunity. Rather than focusing solely on what we were building, we could start asking who we were building it for and why. What began as a team-wide introduction to UX evolved into a longer effort to gradually embed user-centred thinking into everyday development.
Context
In early 2022, the company was focused on stabilising and expanding a new generation of its software platform. The development team was small, agile, and highly collaborative. My official role was front-end developer, but I had past experience in UX and was applying UX methods where opportunities arose.
The timing felt right: the migration work was largely behind us, the platform had become more stable, and there was space to think beyond technical delivery.
I proposed an introductory UX course to leadership. The goal wasn’t to transform developers into UX specialists. It was to create a shared understanding of what UX was, why it mattered, and how it could help us make better product decisions.
The proposal was supported, and I was given the opportunity to develop and deliver the training myself.
Challenge
The challenge wasn’t resistance. The challenge was absence.
The team cared deeply about building good software, but there was no shared UX vocabulary, no formal research practice, and few mechanisms for bringing user needs into day-to-day product discussions.
Most decisions were made using internal knowledge, customer requests, and product expertise. While these sources were valuable, they often left an important question unanswered: what problem was the user actually trying to solve?
Introducing UX therefore wasn’t about replacing existing practices. It was about creating space for a different perspective within an already busy development process.
Any approach also needed to acknowledge reality. We didn’t have dedicated UX resources, large research budgets, or the capacity for major process changes. Whatever happened would need to fit naturally into existing workflows.
Approach
The UX course was only the starting point.
At the end of the training, I presented a maturity roadmap designed to gradually increase the team’s UX capability over time. Rather than proposing a large transformation, I focused on small changes that could be introduced through existing rituals and processes.
The first priority was creating a shared understanding of our users. We began developing personas that reflected the different people using our platform and started bringing them into conversations about features and priorities.
Something subtle but important happened. Team discussions gradually shifted from talking about “the user” to talking about specific user types by name, and their needs. Instead of asking whether a feature was technically possible, conversations increasingly included questions about who would use it, in what circumstances, and what problem it solved.
As confidence grew, additional UX techniques started appearing throughout the development process. User story mapping helped us understand complex workflows. Small UX improvement tickets began finding their way into the backlog alongside technical work. Bugs were addressed immediately, rather than being logged and otherwise ignored.
The goal was never to introduce UX as a separate discipline operating in isolation. It was to make user-centred thinking part of how the team already worked.
Outcomes
The biggest change wasn’t visible in the interface. It was noticeable in conversations.
Personas became a regular reference point during discussions, even before they were fully completed. Team members increasingly framed decisions around user goals rather than feature requirements alone. UX stopped being something owned by one person and became a shared consideration across roles.
The impact gradually became visible in the product as well. Through a steady stream of small improvements, the platform became easier to learn, easier to navigate, and more efficient to use during high-pressure situations. Client onboarding improved, support requests decreased, and user growth continued.
While it is difficult to attribute these outcomes to any single initiative, the introduction of UX practices helped create a stronger connection between development decisions and user needs.
Most importantly, the organisation now had a foundation on which future UX work could build.
Reflections
Looking back, the most valuable lesson was that UX maturity is rarely achieved through major initiatives.
It grows through repeated exposure, shared experiences, and small successes that demonstrate value over time.
The roadmap itself was useful, but the real progress came from integrating UX into places where the team was already working. Story refinement sessions, planning discussions, backlog reviews, and feature conversations became opportunities to introduce user-centred thinking without creating additional process overhead.
If I were starting again, I would push even more for direct user contact. Personas helped create empathy, but there is no substitute for watching real users interact with a product. Establishing regular usability testing, would likely have accelerated the team’s maturity significantly.
The initiative remains ongoing. UX maturity growth is not a finite process. Growth needs to be continuous; one cannot stop it without having it slip away. UX is no longer something being introduced. It has become part of how the team thinks about building software. It is up to the team to keep it up and continue maturing.