Enterprise Laboratory Information Management System

I worked as the lead UX and product designer on LIMS, Daikin’s internal Laboratory Information Management System, replacing Excel-based workflows with a single platform for test request submission, approvals, scheduling, and lab capability management. Working in an agile team alongside engineers, PMs, and other designers, I led user research and information architecture for a system serving seven distinct roles — from Lab Technicians to Stakeholders — each with different responsibilities, data needs, and permissions.

Skills

User research

Design System

Information Architecture

UI and component integration

UX strategy and Audits

Agile

Tools

Figma

FigJam

Miro

Figma AI

Notion

Claude Code

Notebook LM

PROJECT DIRECTORY

Role	Key Responsibilities	Methods	Teams Involved	Focus Areas	Project Type
UX & Product Designer	Information Architecture, User Search, User journey maps, UX implementation, Design Systems, Accessibility implementation, Prototyping and development ready hand off documentation.	Agile environment and Sprint planning	Cross-functional Agile Environment: Engineers, PMs, Design Peers, Executive Stakeholders.	User research, information architecture, personas and journey mapping, workflow design, contribution to a shared design system	Heavy data Laboratory Management System Integration. Onboarding users to new workflow.

“Migrating from Excel isn’t just swapping tools — it’s about reshaping an entire operational workflow. The challenge was advocating for human intuition inside a platform natively defined by heavy engineering constraints.“

– Abril J Alejo

KEY INSIGHTS & IMPACT

Designing From Zero, for Five Roles at Once

What I did: Ran user interviews and research with Product Engineers, Engineering Managers, Lab Managers, Test Engineers, and Lab Technicians to understand how each role actually used the existing Excel-based process, since no prior digital system existed to learn from.

Design Approach: Built personas, journey maps, and a permissions-aware information architecture so each role saw a personalized dashboard and workflow, rather than one generic view stretched across five different jobs.

Why it mattered: A test request touches multiple approvers in sequence — without role-specific views, the tool would have forced technicians and managers into the same crowded interface built for neither of them.

Continuous Research in an Engineering-Native Culture

What I did: Held weekly meetings with end users throughout the 18-month build, using their real day-to-day friction to prioritize what got designed next, rather than working from a fixed spec handed down up front. I ran quarterly UX audits, documented in Figma, and mapped the evolving information architecture in FigJam as the platform’s roles and workflows became clearer.

Tools: Used AI tools in a supporting role for early-stage drafting — structuring interview guides and doing lightweight competitor scans — to leave more time for the actual user conversations and audit work.

Why it mattered: Daikin’s culture is engineering-first; UX had to earn its place by showing, repeatedly, that user feedback changed what got built. Weekly cycles and quarterly audits made that visible rather than theoretical.

A Feedback Loop Built Into the Workflow

What I did:Set up a third-party feedback board where users could log friction points as they worked with the tool day to day, and used that steady stream of input to help shape the agile team’s backlog priorities.

Design Approach: Ran quarterly UX audits in Figma against the live product, translated recurring feedback into wireframes and prototypes, then validated design directions with A/B testing before they went into the design system.

Why it mattered: For a tool with no precedent to test against, live feedback from real lab workflows — checked quarterly against a structured audit — was the closest thing to ground truth available.

Overview

The Challenge

How do you replace an entire lab’s Excel-based workflow with a single piece of software — one that has to serve five roles, with no existing digital system to build from, in a culture where engineering, not UX, has traditionally led product decisions?

There was no legacy digital tool to migrate from and no existing onboarding process for new users. Every workflow — test requests, approvals, scheduling, lab capability management, inventory — had to be mapped and designed from the ground up, while stakeholders expected a working, adopted product on a fast timeline.

The Outcome

Over 18 months, the team built LIMS into the lab’s single source of truth: a role-based platform covering test request submission, multi-step approval tracking, scheduling, lab capability configuration, and an onboarding/FAQ system that hadn’t existed in any form before.

Continuous user research and a live feedback loop shaped the backlog throughout the build, rather than front-loading requirements once and building to spec.

The Core Challenge

One platform, seven different jobs

Seven roles needed the same underlying data — samples, equipment, results, deviations, capacity — but each needed a different slice of it:

Lab Technicians	Lab Managers	Engineer Managers	Engineers	Test Engineers	LIMS Admins	Stakeholders
Samples, equipment, lab availability	Lab availability, technician capacity, deviations, methods, results, equipment, materials, status	Engineer capacity, results, deviations, status, methods, samples, training, competencies	Raw data, calculations, interpretations, training, deviations, results, samples	Results, deviations, people capacity, methods, materials, samples	People/roles, competencies, location management, equipment, results	Results, deviations

A technician needs to see what’s assigned to them and log results. A manager needs team-wide capacity and deviation status. A stakeholder just needs results and deviations, with none of the operational detail. Designing one system that served all seven without becoming generic to everyone — or turning into seven disconnected tools — was the core information architecture problem.

Designing within strict constraints

The project had to:

Migrate every existing Excel-based workflow into a single platform, from zero.
Support distinct permissions and personalized views for five roles.
Build an onboarding and user-guidance system where none had existed.
Move at a pace stakeholders considered fast enough to justify the investment, in a culture where engineering decisions typically came first.

I found that advocating for user research in that environment worked best by showing results early and often — weekly interviews and a live feedback board did more to build trust in the process than any single upfront research report could have.

Strategic Collaboration

Aligning diverse perspectives

Working across the team: I connected stakeholders, product owners, and end users throughout the process, translating findings from user research into decisions the development team could act on.

Working with the Users: As part of my weekly routine, I ran what we called ‘coffee hour’ — an open space for users to talk through their experience using the app. It let me, as the UX designer, see how different user roles ran into the same friction points from different angles, and catch errors or possible improvements early. That input fed directly into the periodic audits I ran.

Exploring the AI phase:
I used NotebookLM during discovery and research to help organize and synthesize findings, and Lyssna’s built-in AI to help break out patterns from user research data.

Deep Dive Architecture

Translating research into Information Architecture

During the research phase, I looked at how other LIMS platforms structured their systems and combined that with what I’d learned from user interviews — what our users specifically expected and needed from their day-to-day workflows. I used both to shape the information architecture, working within the development team’s capacity and technical capabilities, and balancing that against what stakeholders expected the platform to deliver.”

Results

From Excel sheets to reduction cognitive load

One concrete design decision that reduced cognitive load: breaking dense tabs into separate pages, converting long columns into dropdowns, and adding a sidebar so users could pull up additional information in one click instead of searching external files or waiting on a teammate to respond. Status visibility on test requests turned out to be one of the features users and stakeholders valued most — it gave everyone a single, shared view into where every request and piece of lab information stood, without needing to ask around.”

Reflection

My take aways

Working on LIMS gave me the experience of managing a data-heavy interface and taking a product from zero to a finished, working system. The biggest challenge was building a platform that users would find not just useful, but intuitive — and helping them move away from Excel sheets into a genuinely collaborative tool.

What I would do different

I’d push to run workshops with stakeholders and the development team earlier in the process — advocating for user research and UX involvement from day one rather than after key decisions were already made. Because UX wasn’t traditionally prioritized in this engineering-led culture, that early advocacy work took real, ongoing effort — and I saw firsthand how skipping it upfront meant more rework later