Embedded UX leadership in a delivery-critical environment

I joined a cross-functional team delivering a new in-store touchscreen experience intended to increase average transaction value and validate a future multi-store rollout.

The team was already formed, with early concepts and engineering work underway. My role was to embed from a UX perspective — supporting delivery in the short term, while introducing research, structure, and shared foundations that could support scale if the pilot proved successful.

Over time, this work extended beyond the touchscreen itself, surfacing deeper issues around design ownership, brand collaboration, and the absence of shared systems across teams.

What I noticed.

The touchscreen initiative had clear commercial goals and strong momentum, but UX practice had largely been absent from early decision-making. Initial concepts were functional, engineering-led, and focused on feasibility rather than customer behaviour or experience quality.

There was also a long-standing tension between product teams and brand, shaped by slow approval cycles and minimal shared guidance. Brand documentation existed, but it was limited in scope and difficult to apply to new digital contexts like touchscreens.

At the same time, delivery timelines were tight. Development had already begun exploratory spikes, creating a narrow window to introduce research and reshape direction without slowing progress.

Signals of misalignment.

As I embedded further, several patterns became clear:

UX introduced late in the process

Experience decisions were being made after technical constraints were already set, limiting the team’s ability to respond to insight or iterate meaningfully.

Fragmented brand interpretation

Without reusable styles or components, each squad interpreted the brand independently, increasing approval friction and inconsistency.

No shared design foundations

Across multiple squads, there was no centralised source of truth for styles, components, or interaction patterns — for designers or developers.

Delivery pressure masking deeper issues

The urgency of shipping the touchscreen risked locking in patterns that wouldn’t scale across other channels if the pilot succeeded.

Ways of working under strain.

This was an environment where delivery mattered — and stopping to “do UX properly” wasn’t an option.

My challenge was to introduce research, alignment, and better decision-making inside delivery, not alongside it. That meant working opportunistically: using development spikes as space to run research, using concept work to build trust, and using tangible artefacts to bring brand and product closer together.

Rather than positioning UX as a gate or an additional layer, I focused on making it a practical support for the team — helping decisions feel safer, clearer, and easier to stand behind.

The challenge.

The challenge wasn’t designing a touchscreen. It was ensuring the experience could succeed commercially and form the foundation for something bigger if rolled out at scale.

Framing the opportunity

Instead of treating the kiosk as a one-off interface, the work was framed around understanding customer behaviour in-store, validating assumptions, and designing patterns that could evolve across channels.

Approach

While embedded with the team, I led a research-heavy phase alongside delivery, including:

  • Menu and category exploration to understand decision-making at the point of purchase
  • Customer research and competitor analysis to challenge assumptions around speed, choice, and value
  • Close collaboration with the UX research team to ground design decisions in evidence
  • Concept work to align brand stakeholders early and rebuild trust through tangible outputs

Alongside this, I designed and prototyped the touchscreen experience — balancing commercial requirements, technical constraints, and usability. Prototypes were used not just for handover, but to support discussion, alignment, and A/B-style exploration.

Introducing foundations

As the work progressed, it became clear that the absence of shared design foundations was a blocker — not just for this project, but for the organisation more broadly.

I began introducing a lightweight, Figma-based component library grounded in existing development patterns, with the explicit intent of supporting delivery first. The longer-term opportunity — extending this across app, web, and multiple squads — was positioned as a way of working, not a design file.

Trade-offs and constraints

Time was extremely limited. Not every research insight could be acted on immediately, and not every system improvement could be prioritised before launch.

The focus remained on:

  • enabling confident decisions
  • reducing approval friction
  • leaving behind foundations the team could build on after delivery

Reflection.

This work reinforced the value of embedded UX leadership in high-pressure environments. Progress didn’t come from enforcing process, but from earning trust — showing value quickly, supporting delivery, and introducing structure where it made things easier rather than harder.

The touchscreen launch validated the importance of grounding decisions in real behaviour. Observing customers in-store, reviewing real-world usage, and testing changes post-launch helped shift conversations from opinion to evidence.

Most importantly, the project demonstrated how delivery work can become a catalyst for broader change. What began as a single touchscreen pilot became the starting point for shared foundations and more sustainable ways of working across teams.