Through on-site shadowing, ride-alongs, and Interviews with fire-alarm, sprinklers and extinguisher inspectors, service managers, and compliance officers, we uncovered a core set of obstacles holding inspections back:

• Pen-and-paper notes are re-typed into Excel days later, introducing errors and slowing report delivery.

• Concrete basements and shielded stairwells kill cell signal, blocking any real-time data capture.

• Without live validation, clients face compliance risk from missing or inaccurate device results.

• Inspectors log only failed devices on-site, bulk-passing everything else from memory.

• Often, testing procedures involved the use of tools that required one or even two hands to perform.
• Inspectors needed both hands to operate testing tools, making tablet use impractical.
• Reports were only updated after the inspection, creating lag and errors.
• There was no way to validate field testing in real time or share data instantly with stakeholders.

At the same time, switching to a mobile platform raised a few big questions on the ground:

“I’ve got a meter in one hand and a screwdriver in the other, Where would a tablet even fit? ”

“What if the app loses connection underground? I can’t afford to redo an inspection.”

I joined the project as the sole designer, responsible for discovery, ideation, prototyping, and final UI for both mobile and web platforms.

Through extensive user shadowing, I captured pain points firsthand and shaped the early product direction. I designed the full end-to-end system, from mobile inspection flows to the web-based report manager.

As the project evolved, I transitioned into a dual role, continuing to lead the product design vision while also acting as Product Manager. I remained hands-on with UX/UI while hiring and mentoring two additional designers to support our growing roadmap keeping UX decisions aligned with rollout constraints, dev timelines, and evolving customer feedback.

Throughout, I collaborated closely with developer leads, project managers, and customer support teams to validate feasibility, prioritise features, and advocate for user needs at every stage.

Xaap Team – Cork Ireland

Negotiation insight: When starting the implementation of the offline inspections, the feature to add a picture while failing a device was at risk of being dropped from the roadmap due to offline functionality complexity. I made the case to PMs and devs using support ticket data, feature requests, and conversation logs, showing how it can potentially reduce client callbacks and frustration. That evidence kept it in scope, while we agreed to push lower priority features to a subsequent release.

I conducted on-site observations of fire safety, sprinkler systems, and fire extinguisher inspections, mapping processes such as smoke detector testing and basement inspections. These observations revealed critical context: two-handed workflows, limited mobility, and disconnected reporting.

UX  Personas

• Inspector: On-site, hands-on, time-sensitive.
• Service Provider Owner: Management oversight, scheduling, reporting, and compliance.
• Customer Support Agent: System admin.

These personas were initially defined through internal stakeholder input, including PMs and business leads. They were later validated through shadowing sessions, real-user interviews, and confirmed by behaviour patterns and pain points observed in the field.

• Web Portal: This enabled building owners, fire marshals, and auditors to retrieve reports, track open deficiencies, and verify signatures without sending a single email.
• Fire Panel Gateway: Proprietary gateway device to connect offline fire panels with the Xaap Cloud to perform live/real-time inspections and get immediate testing results on fire alarm devices.

These entryways look different because the work behind each one is different, yet they still feel related. A unified design system, shared colors, typography, and interaction patterns, threads them together, so moving from phone to browser is simply a change of screen, not a change of product.

When an app’s structure mirrors the way people actually work, screens feel intuitive and tasks flow without friction. To reach that point with Xaap, we stepped back from pixels and first mapped the mental models of every role, from inspectors deep underground to service managers behind a desk. The resulting hierarchies enable each user to land exactly where they need to start, while all share a single backbone of data, ensuring seamless handoffs.

Before we split the work into separate iOS and Android flows, we built a single core map of tasks and entities. From that shared backbone, we made only the tweaks that honor each platform’s native habits—bottom-tab hierarchy for iOS, Material bottom-nav and system back gesture for Android, platform search, sheet, and modal patterns. In short, the architecture is the same at its core, the furniture changes to match the room it lives in.

Xaap uses a three-tier brand blue plus a purpose-built grey ramp and semantic accents to balance clarity in the field with credibility in the office. The color palette expands from the web to the mobile applications to achieve a unified look and feel.

To keep Xaap instantly recognizable, yet still feel at home in every environment, we anchored the design system on two complementary fonts:

Our web UI runs on a token-driven design system built in Figma and Storybook. Every staple, input field, status pill, icon, navbar, paginated table, right-hand drawer, is specced once, mapped to Xaap colour and spacing variables, then consumed across the portal. What you see here is a single “cut-out” from the library:

• The form kit with live-error states,

• The semantic badge set that mirrors mobile statuses,

• A feather-weight icon pack exported as one SVG sprite,

• The responsive data-table molecule, and

• The slide-in drawer pattern is used for reports, settings and approvals.

Because engineers pull these components straight from Storybook, new pages ship with zero bespoke CSS.

It was a challenging task to align development and design into a unified view of the design system. We had several sessions to define naming conventions and component structure patterns to be able to recreate the same elements on Figma as on the apps, but we made it happen 🙂

Below is a slice of the hand-off file our engineers received. Every state of the device card—closed, open, pass/fail tapped, notes added, barcode scanned, sits in one Figma frame with redline spacing, token names and edge-case call-outs.

We treated the card as a mini design system: atoms (labels, badges), molecules (button rows, summaries) and the full organism. That rigor was our way to communicate across multiple dev teams on different cities to build the component once and reuse it across the app without a single Slack back-and-forth.

During our initial testing, inspectors often bump up system text for readability, and the old card collapsed under larger fonts, labels wrapped, and actions slid off-screen. We rebuilt it as a simple vertical stack: key details stay on one line at any size, secondary info appears only after a “tap-to-expand,” and thumb-wide PASS / FAIL buttons remain fixed. Bigger Pass button hitting area as it was proved that 90% of the taps were on this component. The new hierarchy scales cleanly, reads faster, and works for every accessibility setting.