The brief was to envision a desktop application that would let railway inspection engineers carry out virtual checks on unmanned, remote stretches of track to monitor vegetation encroachment, all from the safety of an office environment.

The platform combines two data streams: LiDAR (Light Detection and Ranging) survey data of the physical site and forward-facing video footage recorded from the driver's cab of a passing train. Engineers can compare these two sources frame by frame, assess the level of encroachment at any milepost, and generate maintenance work orders, without leaving their desks.

A machine-learning layer highlights vegetation inside the inspection zone on the video feed and flags encroachment zones in the LiDAR view; based on the engineer's confirmation it recommends next actions and routes the work order to the right maintenance crew.

We opened the project with a structured series of workshops involving SMEs, business analysts, and key stakeholders. The goals were practical: surface tacit knowledge, expose current limitations, agree on priorities, and build consensus around an MVP scope.

To ground the team in real conditions, we organised field visits with on-foot inspectors. Walking alongside engineers as they ran live surveys gave us first-hand insight into the constraints of the existing process and what would need to translate into the digital experience.

Designing for a data-heavy enterprise platform is closer to sculpting than illustrating. You start with an enormous block of available information and carve away until only what's useful for the task remains. Strip too much, and the tool becomes useless. Keep too much, and it becomes unworkable. The skill is in the balance.

From the workshop and field data we synthesised two distinct user personas, each with their own pain points, goals, and contextual constraints. These gave us a north star for every interaction decision that followed.

With personas in place, we mapped a pain-points and opportunities chart to anchor the ideation, then visualised the ideal task flow for each user group.

Once wireframes were signed off, design moved into the development team's hands. The build was split into three prioritised releases, each one tested against user stories, with the feedback feeding directly back into the next iteration.

The platform serves a specific audience that values functionality over visual flourish — and it had to be built within the constraints of an industry-regulated environment. Managing a focused agile team let us move quickly without compromising design rigour or engineering quality.

VLI was one of the most complex projects I've led recently, and one of the most rewarding. Having time and access to do proper primary research before designing — workshops, field visits, contextual interviews — was the single biggest factor in getting the solution right.

Boots is a rare hybrid: the UK's largest pharmacy network and its favourite beauty destination in one brand. Its app had grown up on the retail side — Advantage Card, offers, shopping — while healthcare lived in separate flows with different navigation, tone and sign-in. Customers who came to buy skincare and stayed to reorder a prescription had to change worlds mid-journey, and many simply gave up.

The opportunity was strategic as much as experiential. The NHS was actively shifting routine care from GP surgeries into community pharmacy, and Boots already delivered a large portfolio of services on the NHS's behalf. A personal-healthcare layer inside the app — trusted, accessible and connected to NHS systems — could make Boots the place millions of people manage everyday health, not just buy it.

I structured the programme on the Design Council's Double Diamond: diverge to understand the real problem, converge on the one worth solving, diverge again on solutions, converge on what to ship. The shape kept a large team honest — no solutioning before the problem was defined, and no shipping before the solution was tested.

Synthesis ran as a two-day workshop with the whole team and the pharmacy lead. Three behavioural archetypes emerged, each with a different trust threshold — and a problem statement the team could hold in one sentence.

Standard usability metrics weren't enough — a health journey can be easy and still not trusted. Alongside task success and time-on-task I added a trust-to-act score: after each task, how comfortable would you be doing this for real, today, for yourself or someone you care for? Three moderated rounds with 24 participants, including screen-reader users, ran across the release gates.

Healthcare isn't a UX category; it's a constraint that raises the bar on everything. Designing to a regulatory standard forced rigour into every decision — and the resulting discipline made the commercial side of the product stronger too.

MAPFRE Insurance is one of the United States' most established carriers, offering coverage across auto, home, motorcycle, watercraft, and commercial lines. In Massachusetts alone, they hold the position of largest private passenger auto insurer, largest homeowners insurer, and largest commercial auto insurer.

Despite this market dominance, their digital experience told a different story. The Online Bind platform — the journey customers used to quote and purchase auto insurance — had aged poorly. Internal customer-satisfaction surveys flagged it as a major friction point, with measurable impact on conversion, usability, and customer satisfaction scores.

MAPFRE's leadership made the call to commission a full redesign: a refreshed visual system, a re-architected quote flow, and full alignment to current accessibility standards. I came in as Principal UX Designer and engagement lead, owning strategy, research, design direction and project management end-to-end.

Working backwards from the convention deadline, I mapped a high-level UX plan covering five stages — each with its own deliverables, validation checkpoints, and stakeholder touchpoints. This gave the client a transparent view of where their investment was going and where they could expect to weigh in.

I interviewed five participants ranging from late teens to late sixties, all of whom had purchased some form of online insurance within the previous two years. The mix included working professionals and one recent retiree. Each interview blended open-ended exploration with structured probes around their last purchase experience.

From these conversations, four behavioural themes emerged repeatedly:

Synthesising interview themes, I built one primary persona — Jamie — capturing the most representative behavioural pattern: a working professional who values clarity, fairness, and self-service, but who has been burned by previous insurance experiences and approaches every new provider with cautious scepticism.

With personas locked and the feature set agreed, I ran an open card-sort exercise to inform the site map. Participants received twenty-five distinct insurance products on index cards and grouped them however felt most natural — then named those groups themselves. The aggregated patterns translated cleanly into the final IA.

To anchor every interaction decision in a real customer journey, I built a task flow tracing the steps a customer like Jamie would take to obtain an auto bind quote.

From task flow, I expanded into a full user flow — explicitly modelling the obstacles, decision branches, and trust-eroding moments Jamie might encounter, and the design responses to each. The extra time invested at this stage paid back many times over once we entered hi-fi design.

The single biggest experience shift was rebuilding the quote form as a guided wizard. The legacy version asked for everything on one long page — no progress indication, no context for why a question was being asked, and no save-and-resume. Users abandoned the flow at the first sign of friction.

The new wizard chunks the same data into themed steps, surfaces clear progress, and lets the user save and come back later. Every field is justified to the user with a short, plain-language explanation of why it's needed.

MAPFRE was the project that taught me how powerful a hard deadline can be when paired with disciplined prioritisation. The convention date didn't just compress the schedule — it forced clarity at every decision point. Every "could we also..." conversation ran through the MoSCoW filter, and that single piece of discipline kept the team focused on what actually mattered.

Generative AI gave software the ability to answer. Agentic AI gives it the ability to act — to plan a sequence of steps, call tools, make intermediate decisions, and complete a goal on the user's behalf. For enterprise finance software, that shift is transformative and terrifying in equal measure: the upside is enormous productivity, the downside is an autonomous system making consequential financial moves the user didn't fully authorise.

Intuit set out to embed agentic capabilities across the Enterprise Suite so that finance teams could hand off repetitive, multi-step work — reconciliation, anomaly triage, compliance checks, reporting — to AI agents. My mandate was to define the UX strategy and interaction framework that would make these agents genuinely trustworthy: powerful enough to save real time, transparent enough that a controller would stake their name on the output.

This wasn't a single screen. It was a design language for a new category of interaction — one the whole organisation could build against.

To design delegation to AI, we first studied how finance professionals delegate to people. Over a five-week research cycle, the team ran contextual interviews with 18 controllers, accountants, and finance managers, plus diary studies tracking how and when they handed work to junior staff — and critically, what made them trust the result.

Three trust mechanisms surfaced consistently, and they became the backbone of the whole framework.

I designed the programme to answer one question — what makes a finance professional comfortable handing consequential work to a system? — and sequenced methods from attitude to behaviour so we weren't designing to opinions alone.

Research gave us the roles; scenarios gave the team a shared picture of what "an agent doing finance work" actually looks like, hour by hour. Each scenario names the trigger, what the agent does on its own, where the human must step in, and how the outcome is recorded. They became the test scripts for every round of validation.

Rather than a binary "manual vs automated," I defined a five-level autonomy spectrum. Each feature in the Suite is placed on this spectrum based on the risk and reversibility of its actions — and users can dial an agent up or down the scale as their trust grows.

Before any visual design, the four core patterns were wireframed at desktop scale and put through Wizard-of-Oz sessions. The question at this stage wasn't "does it look right?" but "does the person feel in command?"

Standard usability metrics weren't enough here — a feature could be easy to use and still not trusted. So alongside task-completion and time-on-task, we introduced a delegation confidence score: after each test task, participants rated how comfortable they'd be letting the agent do that work unsupervised on real company data.

We ran three rounds of moderated testing with 24 finance professionals, iterating the plan-preview and live-trace patterns between each round. Confidence rose sharply once users could see and bound the agent's behaviour, confirming the research thesis: transparency, not accuracy alone, is what unlocks delegation.

Before the first test round I agreed four shared numbers with the PM and the AI/ML lead, and they are the numbers every agentic feature in the Suite reports today. The framework was judged on whether finance professionals actually delegated, not on how many components we shipped.

Designing the patterns was half the job. Getting multiple product teams, across vendors and time zones, to build agentic features the same way was the other half — and the part that made this a leadership project rather than a design one.

Agentic AI is the biggest interaction-model shift since the touchscreen, and it rewards the fundamentals rather than replacing them. The winning moves weren't clever prompts or novel widgets — they were the oldest ideas in UX: show your work, respect the user's authority, make mistakes recoverable.

Finding a parking spot in a busy area is rarely quick. Drivers can lose anywhere from a few minutes to an hour hunting for a space that fits their car and sits close enough to where they're going — mostly because they're making decisions without reliable information about what's available.

KOKO asked me to design a mobile app that fixes this for drivers and, at the same time, gives local shopkeepers a reason to sponsor it. The app surfaces free or nearby parking around a destination, lets drivers book a slot in advance, and rewards each booking with discount coupons and redeemable points from participating stores. Target users: anyone who drives.

Discovery began with the business: what problem KOKO was solving, what its objectives were, and what made the brand distinct. From there I studied the market, analysed the competition and set out to understand drivers' needs and pain points first-hand.

To ground the survey questions in real behaviour I spent time watching high-traffic parking areas — deliberately covering different parking types (garages, multi-level structures, open lots, and street parking). I timed how long drivers took to find a spot and to pay, and noted their driving patterns. One car alone made more than twelve turns and three loops before parking, then queued five minutes to pay.

To go deeper on the day-to-day problems, I interviewed five private car owners who drive daily to college or the office. The transcripts were rich but scattered — a reminder that raw interview data needs structured synthesis before it yields conclusions.

I benchmarked the parking apps already on the market and compared the ones with elements closest to KOKO's ambition. ParkMobile and RingGo came nearest to the target — map views of availability, navigation and reservation. PayByPhone informed pay-for-a-spot and extend-stay; SpotHero the reservation model; Strava's mapping and Sharvy's kudos, badges and stats shaped the community and rewards thinking. Google Maps set the bar for wayfinding.

With research and objectives in hand, design focused on getting drivers to their goal as quickly as possible with as little friction as possible.

Every component was built to be compatible and reusable within the KOKO style guide, with a minimum of WCAG AA accessibility across the application — contrast, touch targets and legibility checked for use on the move.

To get ideas flowing I sketched a series of paper prototypes. These lo-fi artefacts made it cheap to test and iterate before committing to screens.

Key screens were worked up in low fidelity to find the most usable and scalable structure. After testing and refinement, a unified layout emerged that flexed across user types and use cases.

Parking space booking

Offers and points redemption

Design is never finished. Once real users had the product, we reviewed performance, gathered feedback and improved against both user needs and business goals.

I assembled a prototype to surface usability issues. Even with limited functionality, participants could grasp each screen's structure and flag anything that would hurt the experience. Findings were clustered in an affinity map, prioritised, and fed back into navigation and other areas.

Before the first release I agreed a small scorecard with the PO so each drop could be judged against the problem we were hired to solve — drivers abandoning parking apps out of frustration — rather than against feature count.

Listening to customers and would-be customers is everything. Understanding how they think and feel made it possible to empathise and design for the problems they actually have. Most of those problems aren't new — plenty of parking apps already ship these features. The point was never to reinvent the wheel but to listen closely enough that the experience becomes obvious and users don't have to think.

And it doesn't end at launch: shipping the MVP to real people is what validates the assumptions and answers the questions users still have. Further iteration towards delight is the path from here.

Published research backs the hunch: the volume of reviews from friends shapes following behaviour far more than the crowd's. Crowd valence and variance showed no effect once friend reviews were ignored — and a negative one when they were included. In short, the influence people attribute to reviews mostly comes from reviews by friends.

Source: ScienceDirect, "Friend reviews vs. crowd reviews" (2018)

Key screens were explored in low fidelity to find the most usable, scalable structure. Testing and refinement shaped a unified layout that works across user types and use cases.

Lo-fi sketches locked hierarchy, design goals and component choices before the visual layer was applied against the Opatter style guide.

The MVP prototype was tested in two rounds with participants matching the persona, in simulated in-store scenarios: choose a gift, then choose something for yourself. Alongside task success I measured decision time, self-reported confidence, and a System Usability Scale score.

Before testing I defined what "working" meant, so results could inform a go / no-go rather than a debate. One north-star, three supporting signals, tracked round over round.

Across IES, PPM and Compliance, my team was producing good Figma work — and losing a lot of it in translation. Research synthesis took days. Static mockups left engineers guessing at states, edge cases and logic. Every "why did we design it this way?" question sent someone back through a Zoom recording. Rework arrived late, when it was most expensive.

The opportunity wasn't a new tool; it was a new operating model — what the team now calls Vibe Designing. Generative AI had become good enough to transcribe, synthesise, draft and even build. If we re-sequenced the work around those capabilities — with the designer firmly in the loop as editor and decision-maker — we could hand engineering something far more useful than a picture: a working prototype whose every element traced back to customer evidence.

Speed is the easy part of designing with AI. The hard part is staying trustworthy, consistent and honest while moving fast. These are the practices I hold my team to — and the ones I ask engineering and product partners to hold us to. They are written as rules on purpose: a framework is only as good as the discipline around it.

Guardrails are what turn an experiment into a practice an enterprise can trust. In a regulated financial-software company they are also the licence to operate: security, legal and compliance said yes to Vibe Designing because the rules were written down first.

Three reasons, in the order leadership cares about them. Trust: one leaked customer detail or one confidently wrong requirement would end the programme and set AI-assisted design back years. Speed: teams move fastest inside clear boundaries — nobody pauses to ask "am I allowed to?" when the answer is written down. Scale: rules let eight people across two vendors behave as one team, and let a new joiner be productive in a week.