Building a UX Practice at a SaaS Startup

1. Context

Plytix is a SaaS PIM (Product Information Management) tool: an online platform, available on subscription, that brings a company's product data together as a single source of truth and prepares it for every channel where the client sells.

There was no UX practice before I joined — no established processes, no shared vocabulary for what UX could actually offer the team. I was hired as the only UX person, which meant the first part of the job wasn't designing screens. It was explaining what UX was for, to people who had never worked with a UX role before.

2. My Role

My role split across three areas:

UX advocate — working with UI designers, managers and the dev team to build a shared understanding of user needs. I ran the research myself, brought everyone's input together, and looked for solutions that worked both technically and for the user. Rather than telling a team something wasn't feasible, I focused on framing the outcome: what we could ship now as a temporary solution, and when we could revisit the definitive one. That kept people engaged instead of putting departments against each other.

UX manager — establishing and improving user-centred design processes, connecting UX to the wider business alongside the Head of Product, and regularly reporting on UX programmes, projects and best practices. I owned the key UX artefacts: user journeys, personas, longitudinal research, UX measurement.

UX designer — the hands-on work: user research and competitor analysis, interpreting data and qualitative feedback, user stories, personas, storyboards, information architecture, sitemaps, prototypes, wireframes and usability testing.

3. Processes I Built

There was no existing UX process to plug into, so I documented four, adapted to how the team already worked:

• Evaluate → Optimise — document and evaluate an existing flow, check related user insights, evaluate the experience, and, where needed, map pain points with a swimlane diagram.
• Document → Analyse — a descriptive analysis of the interface and flow, an analysis of specific PIM features, and an evaluation of the emotional impact and behaviour behind them.
• Propose → UX proposal — a first pass at a new feature, benchmarking what competitors do, and an early look at technical feasibility before committing.
• Shortcut reviews — UX review and investigation work directly inside the team's ticketing tool, comparing the user's perspective against the story's stated scenario, with an overall analysis.

I also wrote a short methodology guide i documenting my role, how I fit into the sprint, and what the team could ask of me. There was no prior UX awareness to build on, so that context had to be made explicit rather than assumed.

4. A Day in My Work

A concrete example of how this played out: I was asked to analyse a "Find and Replace" feature for an HTML attribute. There were two types of text involved — the plain text end users interact with, and the underlying code text that structures it. Product wasn't sure which one the feature should target, so I went directly to a developer to understand the constraint.

He explained the actual usability problem: users could only interact with the code text, not the plain text. That meant if the same word appeared in both, replacing it in one replaced it in both — even though the two could serve different purposes. "Red", for instance, is a colour attribute in the code (<p style="color:red">) and an adjective in the plain text ("red dress"). Same word, different jobs.

Product was already wary of technical complexity and wanted a result within the timeline, without engaging much with the user problem. I took screenshots of the different scenarios with the developer and asked whether the underlying configuration could change so users could interact with the plain text directly. He was clear: not now — the current sprint didn't leave room for it, and the feature wasn't high-impact enough to reprioritise.

I asked for ten minutes with my team, presented the scenarios with the screenshots, let them react, and then reframed the conversation around the user outcome rather than the technical ask. We agreed on a temporary solution: keep working with the code text for now, but show a warning message when the feature is used on an HTML attribute, so users understand what's actually happening. The team liked it, refined a few details together, and I looped the developer back in on the outcome.

I also kept a running document of situations like this one, so decisions like it wouldn't have to be re-litigated from scratch next time.

5. Outcome

Three months wasn't long enough to see every process mature, but it was enough to establish a working UX function where there hadn't been one: documented processes the team could actually use, a shared vocabulary for talking about UX with people who'd never worked with a UX role before, and a track record of resolving product-dev tension by focusing on outcomes instead of taking sides.

It also shaped how I've worked since. Building bridges between teams isn't about being right — it's about finding the version of a solution everyone can actually agree to ship.