Redesigning for the User,
Not the System
Infor Cloverleaf Healthcare Data Integration Platform (HDIP)
Company
Infor — Cloverleaf Product Suite
Cross-functional partners
Product Manager, Business Analysts,
Software Engineering Leads
Role
Senior Product Designer (sole product designer)
Scope
End-to-end redesign of the configuration & monitoring workflow for a healthcare SaaS platform serving clinical integration engineers across the U.S. and internationally
Timeline
January – October 2024
~73%
Reduction in related support tickets
10 → 6
Days to onboard new engineers
↑
Task speed & accuracy
(self-reported)
None of that came from visual polish. It came from stopping, going back to the user, and redesigning the interface around how engineers actually think, not around how the system stores data.
​
That's the through-line of this project: a structured, evidence-driven effort to close the gap between what Cloverleaf's configuration and monitoring workflow was communicating and what the people using it actually needed. Here's how we got there.
Background
What Cloverleaf HDIP Does, and Who Uses It
Cloverleaf Healthcare Data Integration Platform (HDIP), as the name suggests, is a healthcare integration engine. Its job is to route and transform clinical data — EHR records, lab results, patient orders — between the systems that make up a health network: hospitals, outpatient clinics, laboratories, and more. The people responsible for configuring and keeping those data pipelines running are integration engineers. They're highly technical, they're busy, and they're working in an environment where a missed failure or a delayed message can have real downstream consequences for patient care.
​
The configuration and monitoring tools are their primary workspace. When I joined the project, that workspace had layers of accumulated complexity: a legacy desktop IDE that had been ported to the web without being fundamentally reconsidered, and a modal-heavy interaction pattern that reflected how the system stored its data, not how engineers thought about their work.
Identifying the Problem
Research Before Design
A pattern of support escalations and product manager conversations with key customer accounts had flagged the monitoring workflow as a persistent pain point. But the team lacked a clear picture of why — which meant we weren't in a position to fix it well.
​
As the sole product designer on this project, I initiated and owned a structured research effort built around three methods, used in combination.
Task Analysis Sessions
I conducted sessions with five integration engineers across five different health systems, asking participants to walk me through their typical monitoring workflows while narrating their thought process out loud. This gave me direct observation of where friction was occurring — in real time, with real data, under real organizational constraints.​
Collaborative Journey Mapping Workshops
I facilitated sessions with cross-functional stakeholders — product, implementation services, and customer support — to map the full workflow from initial configuration through live monitoring. The journey map covered six workflow stages: managing the cloud connector, configuring a site, deploying a site, managing data flow, handling errors, and auditing user actions. Two primary personas emerged from the research: the Integration Developer and the Operations Analyst, each with distinct goals and pain points across that workflow.
​
What made this work valuable wasn't just the artifact itself; it was that it was built in real-time, together. Journey maps built collaboratively with stakeholders tend to stay alive and guide decisions. Ones built in isolation tend to get filed away.
Support Ticket & Session Recording Analysis
I cross-referenced qualitative observations from the task analysis sessions with support ticket data and session recordings to identify where users were failing at measurable rates, and to validate that the patterns I was seeing in research sessions were showing up in usage data too.
What came into focus across all three methods was a single, consistent finding: the interface was organized around how data was stored internally, not how engineers thought about their work or made decisions. Engineers monitoring active data pipelines couldn't quickly distinguish between failed, delayed, and correctly processed messages without opening multiple views and tabbing between browser windows. The information architecture reflected the system's internal logic — not the engineer's mental model.
On a high-level screen review, the interface looked functional. It was only when you put real users in front of it under realistic conditions that the fundamental mismatch became visible. And that's exactly the kind of problem you can't fix with visual polish alone.
Designing The Solution
Iteration as Practice
Armed with those findings, I set out to redesign the interface around the engineers' actual workflow and decision-making patterns. The system's data structure was no longer the organizing principle. The user's mental model was.​ That required working through a lot of design problems — and working through them in iterations, not in one pass.
​
Rethinking the properties panel
One of the most significant structural issues was the properties panel: a bottom panel engineers relied on constantly, but which was crammed with so many fields it required constant scrolling and expanding. I explored multiple approaches to the real estate problem, relocating the properties panel to the right side for a better side-to-side workflow: progressively collapsing and expanding sections, restructuring field hierarchy, and testing how much context could be safely collapsed without losing navigability. The explorations ranged from fully expanded views showing all field content to fully collapsed views showing only section titles, working toward a state that gave engineers the right amount of information at the right moment.
Solving the Verifications tab hierarchy
The Verifications tab, which surfaced configuration errors and warnings to engineers, had a specific design problem: what piece of information should anchor each error entry? The answer wasn't obvious. I developed and tested four distinct hierarchy concepts, each leading with a different data point: Thread first, Field first, Tab first, and Description first. Testing with users revealed which hierarchy matched how engineers actually scanned for and acted on errors, rather than which one seemed logical on paper.
​
The ideation behind that decision was documented explicitly: mapping the pain point (cramped data grids in a constrained vertical panel) to the solution approach (treating the vertical panel viewport like a mobile screen, following IDS Listview component guidelines) and connecting it directly to the planned testing method.
Thread first
Field first
Tab first
Description first
%20UI%20Real%20Estate%20Issue.png)
Mapping the configuration wizard flows
The thread configuration workflow — which engineers used to set up inbound, outbound, notes, and settings for integration threads — required mapping out a significant number of interaction paths before any UI work could begin. The flow diagram for the CLWizard thread properties covered multiple user paths, branching states, and endpoint conditions, all of which needed to be accounted for in the redesign.
Throughout all of it, I prototyped iterations in Figma and tested each with a mix of external customer participants and internal users before finalizing for engineering handoff. The final redesigned screens represented a significant departure from the legacy UI — lighter, more structured, with cleaner modal hierarchy and a consistent approach to progressive disclosure across the configuration workflow.​
​
Outcomes
Results Across Multiple Signals
~73%
Drop in support ticket volume related to monitoring workflows following release
10 → 6
Days to onboard new integration engineers at customer organizations
In follow-up surveys sent to the original external research participants, engineers self-reported completing monitoring tasks significantly faster and with fewer errors than in their initial sessions. Internal users who tested the new interfaces confirmed the changes directly addressed the pain points they had flagged.
​
These weren't outcomes driven by a single design decision. They were the cumulative result of building the design on a foundation of real user behavior, iterating based on evidence, and working with cross-functional partners who had shared in the process of understanding the problem from the beginning.
Reflection
What This Project Reinforced for Me
The deepest usability problems are rarely surface-level. The legacy Cloverleaf interface looked functional on a screen review. It was only when you put real users in front of it, with real data and workflow constraints specific to their organizations, that the structural mismatch became visible. No amount of visual polish alone would have fixed an information architecture organized around the wrong frame of reference.​
Research isn't a phase to complete before design begins. It's an ongoing practice that keeps design anchored to real human experiences.
The collaborative journey mapping also reinforced something about how design work actually gets done inside organizations. When cross-functional partners are in the room together building a shared picture of the user experience in real time, design decisions become easier to make, easier to defend, and more durable over time. Everyone contributed to it. Everyone can point back to it. That kind of shared ownership is what separates design that sticks from design that gets relitigated at every stakeholder review.
​
The Cloverleaf redesign was, at its core, an exercise in one of the most fundamental principles of product design: closing the gap between how a system works and how people think. When those two things are out of alignment, the interface will always feel like it's working against the user. Closing that gap carefully, collaboratively, with evidence is the work.