Overview > Projects > Product Design - 2025
Product Design
IMO Studio ( 2025 )
You know you’ve inspired your employer’s confidence when they ask you to spearhead the design of a service portal for nearly all their clients. IMOHealth offers some of the most complex and sought-after data services in the healthcare industry, but all in different stacks. Need a way to describe an optimal operating room setup? IMO has an app for that. Need specificity in describing a research study cohort? IMO has an app for that. This is the story of how I partnered with enterprise architects to lead the design of a single new solution that brings all this functionality together and combines it.
Screenshots from the prototype I designed for this project. You are invited to play with the live prototype. Try importing a file (don’t worry, you can’t break anything).
Challenge: Unite the “Clans”
quick primer
Much of billing in healthcare relies on exactitude in diagnosis. That exactitude finds expression in medical terminology. But every entity in healthcare maintains its own set of terms. An insurer, for example, may refer to heart disease one way, but a hospital another. And the government yet another. This obviously gives rise to a need for reconciliation whenever such entities interact. Each IMO enterprise solution provides a unique KIND of reconciliation. Simple right? Like brain surgery!
the business rationale
In the late summer of 2024 the UX Team was made aware of the goal driving this effort: Leadership wanted one stack to rule them all. A new, integrated aggregation of all the capabilities offered in its various products. And they wanted these provided online (not on-prem), in a subscription-based SaaS.
More, they wanted the capabilities afforded in ways that complemented eachother, to highlight the value-add of using more than just one. And to present them as would an “ETL,” a kind of data-processing product (think ‘Databricks’).
To get us started, the CTO gave us the first version of this diagram (left) that broadly summarizes the technical, back-end functionality at the user’s disposal. It wasn’t much help, so we were still a long, long way from “uniting the clans.”
Then the CTO put me in charge. Just call me William Wallace.
Headwinds: Organizational, Structural, and Political
Why was the CTO driving the design of what was essentially a PRODUCT initiative? Good question. In part, because the UX team belonged to Engineering. But mainly because at IMO, as of these words, Engineering DOMINATED every conversation about STRATEGY leadership ever started. The effects of tolerating this dynamic could be a whole separate article. Suffice to say, Engineering’s outsized voice at this organization was the source of all the following high-velocity headwinds:
A predominant “if-you-build-it-they-will-come” mentality: Did our customers WANT this product? Who knows? Engineering sure did. A tendency to build first and ask questions later was rampant at IMO.
No product manager assigned: While each of the products being unified had a product manager, none was dedicated for the totality. This product needed a full-time champion and that’s not a designer’s job.
Inexperienced designers: I often say that to developers, designers all look the same. We do this voo-doo they never quite understand. So when devs are in charge of hiring, dilettante designers can get added to payroll.
Mismanagement: When I made my concerns known to my manager about the need for a dedicated Product Manager, a restructured UX team, and better political air cover, he could not find the will or leverage to act.
Flat UX Team: Not all designers are equal. Some have more experience than others. So if you do not structure project resources accordingly, you end up with a team of generals with no army. “Design Ops” is a thing.
Tricky politics: A disused version 1 of Studio had been designed by other members of the UX team prior to this effort. So when I was put in charge of the design a year later without proper air cover, resentment abounded.
Sluggish stakeholder involvement: I had had two early versions of a content model rebuffed by the CTO before his enterprise architects engaged in earnest. They were the first of very few.
Interference: Because this project would encompass a near entirety of IMO’s value-prop, tensions were high. Some in a position to do so resisted the urge to interfere in the design process. Some others did not.
Did I let any of this slow me down? Not at all. The fact is I love a challenge and I love a puzzle. We reached mature design because I effectively leveraged my experience, diplomacy, curiosity, humor, pragmatism, and empathy. With the benefit now of hindsight, I would have additionally reminded myself that not every design impediment can be solved with more design activity. And kept a better awareness as to when too much had been asked of the UX Team. Myself included.
“Clans” of Complexity
To say the enterprise software IMO offered clients when I started was complex doesn’t even come close. Each product was its own self-contained little galaxy of complexity, serving its own exquisitely arcane little corner of an already esoteric medical terminology market.
Adding to the complexity, the user experience of each product veered between suboptimal and utterly incomprehensible. This is because many of them were designed by different designers, some of whom were temporary contractors, woefully inexperienced, or both. It additionally seemed clear to me in a number of cases that the Product Managers themselves had likely “designed” their product with the cooperation of the one dev on their team who dabbles in UI design (there’s always one). This rarely leads to positive outcomes.
Indeed, one of the projects I worked on at IMO, prior to this one, involved designing an online version of an “on-prem” solution called Release Manager that IMO had decided to sunset (see article, right). The pressure was on for me to merely lift-and-shift the UX from the latter to the former, but I just could not in good conscience do that.
Why? Mainly because Release Manager’s User Experience was unfathomable. And because letting such an experience persist is not my job.
But also for the same reason I raise the subject here of complexity: because you cannot design something you do not understand. I quote the timeless wisdom of Steve Jobs (emphasis added):
“To design something really well, you have to GET IT. You have to really grok what it's all about. It takes a passionate commitment to really thoroughly understand something, chew it up, not just quickly swallow it.”
Did each of these many complex products have documentation, both internal and external? Yes, some. Was it well-written and/or terribly useful? No, not really. Why? Because it rarely if ever spoke to the REASON the relevant product existed in the first place. What were the user’s goals?
The blog article I wrote for IMO recounting my research of Release Manager
Worse, as time passed, and employees came and went, there were fewer and fewer people who could connect all the dots as to why some of these products ever got stood up and/or articulate just what either the upstream or downstream touchpoints actually were. Indeed, as epilogue to the Release Manager saga, when its Product Manager was abruptly laid off, it fell to me to explain his product to his replacement (just another of the intangible benefits of choosing serious UX people).
Long story short, it took me a good three or four months to get my head around why just ONE of our products existed, what its capabilities were, and redesign it in such a way that it could be used by a literate adult of average intelligence uninclined to plow through a pile of dubious help files. Now I was set to do that same thing for four other products and THEN devise ways to get all five to play together synergistically.
Go get ‘em Wallace.
Summiting Mount ‘Big Picture’
the plan for ascent
As we’ve established, I had the complex task of unifying, and combining a handful of truly complex products into one new product. Ensuring the result far exceeded the sum of its parts. And we’ve established that products cannot be well designed until their purpose and capabilities are fully understood. So I would research each of the relevant products, break each one down by purpose and capability, then discover commonalities and opportunities for synergy.
My occasionally humorous Figjam notes taken as I researched one IMO product
Research
Having studied journalism and worked in broadcast news, I generally channel my inner Woodward and Bernstein. That is, I embrace the good, old-fashioned stake-holder interview. This typically involves one or more recorded one-on-one Zoom calls.
During such calls I focus less on taking notes and more on asking probing questions. It’s often not enough to get experts on a call — you have to get them talking. And get them THINKING. Some will surprise you with their ability to articulate and teach. Most understand a lot but need help describing it. Some others understand less than even they thought they did and have been proceeding on untested assumptions. A very small minority, for various reasons, are irretrievably poor candidates for this methodology.
After such calls, I review the recordings and take notes. Usually in Figjam so I can draw as I learn. Such notes can grow into expansive “conspiracy boards” (see example, left).
As is often the case in enterprise software, unfortunately, touchpoints with actual users at IMO were impeded by red tape. In the example of Release Manager (above), by the time I finally got a sitdown with an actual user, I’d already gotten most of what I needed to understand the product.
Who did I talk to, then? Optimally, the product manager is the last word on the purpose and capabilities of a given product. That was the case at IMO about half the time. But what I discovered was that at IMO, the implementation specialists were the true experts. They knew what the product was supposed to do, how it did it, and what the most recent user feedback (or fury) was about.
The other stakeholders I interviewed were my fellow designers. Each of them were assigned to one of the products (“clans”) leadership wanted united. These interviews helped me establish a baseline awareness of each product’s purpose and process.
MAPPING IT ALL OUT
All these conversations got me to the next phase of my “ascent”: strip away all the UI and expose each product in terms of goals and tasks. Such is the entire point of USER STORY MAPS, always one of the first methodologies I invoke to achieve shared understanding. But it was especially vital at IMO, where I learned no one person fully understood all our offerings from every perspective. Let me repeat that: no one person fully understood all our offerings from every perspective.
An early user story map I created to capture, in the broadest terms, the point and process of each IMO product. Notice how each product has its own color sticky note.
Discovering commonalities
I wish I could share word here of an amazing tool I deployed, or an exotic process I invoked. Some time-saving means, perhaps driven by A.I., of pushing a button and having a solution pop out by dinnertime. Alas, there is as yet no substitute for the kind of old-fashioned, heads-down analysis, rigor, and creativity I gave to this project. As evidenced by the below board, showing my informal audit of certain functionality common across the products.
In this ad hoc table, there is a row for each product and a column for two of the more basic functions each had in common.
Design Workshop: seeking synergy
The “summit” of “Mount Big Picture” was in sight. And the pressure was on.
Again, in addition to UNITING our clan of products, there were ways, our stakeholders believed, that the sundry operations encompassed by these products could be COMBINED. The hope was to eventually create pipelines of interlocking functionality. Demonstrating to our clients that the new product would be a force multiplier and become a one-stop shop for ALL their healthcare terminology data needs.
But none of these stakeholders had specifics beyond what they were hoping to do with the data architecture.
I wanted at least one or two good-faith efforts at combining capabilities from a user perspective in the initial prototype. So I held a key design workshop with the designer assigned to one of the products we were working with.
She had enough familiarity with another product to posit a logical connection in function between the two. I had my first example of synergy in the new product.
Workshop: Looking for “weld points” between two IMO products (one in purple, the other in green).
View from the “summit”
Below is the winning diagram after two previous attempts at a viable content model. I reached this peak because I had persuaded the CTO I couldn’t be expected to acquire the technical awareness necessary to vision this product by myself. After dragging their feet for months, I had managed to get the EAs involved in earnest. Together we mapped the desired data model to a desirable user experience. LET THE WORD GO FORTH: your designers are NOT technical. Don’t expect them to be.
Regardless, this isn’t your typical content model diagram. It’s highly tailored to the mix of stakeholders I was dealing with at the time. Despite my long campaign of evangelism to the contrary, powerful people in the organization were having a hard time adapting to the idea that you don’t START product design with UI design. So where we might otherwise see a higher level of abstraction, we instead see low-fidelity screenflow with a lot of annotation.
Here we see easy-to-follow “happy-path” screenflow moving from left to right, each with the enterprise architects’ data model (in the circle) as the point of origin.
Getting to Mature UX Design
“What’s the holdup?”
Blog article I wrote for IMO about AI, as published on their Web-site.
Everybody loves a pretty picture. Few care for wonky diagrams laid out like something out of ‘A Beautiful Mind.’ But as we’ve seen (and if this Web-site has a theme), a nice UI is always, ALWAYS just the tip of the iceberg. The truth is you can’t have a really great UI without an equally great IA.
The problem is everyone knows what ‘UI’ stands for. Far fewer know what ‘IA’ stands for. Even fewer know what Information Architecture actually IS (including myself, once upon a time).
And when you don’t understand what something is, or why it’s crucial to getting something you want, you won’t understand why you’re waiting for it.
So despite the succinct article I wrote on IA for IMO mid-project, (right) and all my evangelism on the subject in the three years prior, appreciation for the importance of this phase was giving way to impatience, tension, and downright fear among certain of our stakeholders, as to timelines.
In the above-mentioned article, ‘Eight Things to Know About Information Architecture,’ (which was received so well internally, it got published to IMO’s public-facing Web-site), I write that IA is INVISIBLE, like the rules in chess (an analogy I borrowed from the definitive book on the subject).
Unfortunately, so is much of the PROCESS of establishing it. Research is fundamental to IA and It’s hard for research to compete with mockups in conveying progress. Especially where engineering is concerned. Technical people tend to eschew ambiguity, preferring the concrete and quantifiable. Effective IA is achieved on a BATTLEFIELD of ambiguity. Victories are won in increments and captured in ways that REQUIRE CURIOSITY.
So in a context in which engineering predominates (see headwinds section above), and a CTO is being asked to wait for an invisible process to deliver an invisible outcome, despite all my evangelism, hand-wringing was inevitable.
The eighth item I list in my ‘Eight Things to Know About IA’ is: “IA is probably what’s happening while you’re waiting for UX.” This made enough sense to enough people at IMO that they appended a nice conclusion to the article that reads:
“At IMO Health, we gladly take that time – at every stage – to help build the best possible clinical terminology, normalization, and data quality solutions. That is our commitment to one another, as colleagues, and to all of our customers across the healthcare ecosystem.”
That was true for most of our stakeholders. But for at least one nervous UX Manager, that message had gone unreceived.
ia as rocket fuel
What must be emphasized here is the feedback loop between structure and facade. Just as you cannot construct a building from the outside in, you cannot START with UI. Ideas are fine. Sketches? Great! But a full-court press on even medium-fidelity mockups BEFORE you understand your own content model is always a waste of time. Coversely, UI design goes much faster once information architecture is solid.
So when the UX Manager at IMO insisted on a high-fidelity clickable prototype on a tight deadline, I had enough of what I needed to get it right on the very first try. The design I prototyped was not only attractive and elegant, but utterly fit to purpose. His request was premature and risked elevating his political goals over IMO’s (not to mention the users’). But the very time spent on IA he’d fretted about was the reason the prototype went as well, and as FAST as it did.
Rock solid IA enables your UX Designer to move forward quickly and with confidence.
Below we see the evolution of two key pieces of this product’s content model as expressed in the UI. From conception to delivery.
outcomes: Excitement, Engagement, and Implementation
Nothing drives home the reality of a new product more than a high-res prototype. In addition to capturing design decisions, it paints a portrait of a new universe that compells consideration. Among other things, it motivated the disparate development teams to get more involved with the project and with eachother — something I’d been trying to effectuate for months. Within a day of seeing it, they had blown up the comments feature of the prototype platform. The clans were coming together.
And, at long last, a dedicated product manager was finally appointed to lead implementation of the design, which was underway as I write in April of 2025.
UX I rendered for this project
Executive summary
Specificity in diagnosis is the basis for a lot of billing in healthcare and IMO offered a handful of enterprise applications that help ensure nothing gets lost in translation when industry orgs talk to eachother. I was tasked to lead the effort to design a new product that would unite these apps, eliminate overlap, and combine their capabilities in valuable ways.
Pushing through a maze of complexity and organizational barriers, I mounted an epic research effort, broke each app down by user goal and capability, then mapped these out for crossfunctional consumption, analysis, and validation.
Vaulting pushback on timelines and design theory, I established a viable content model and achieved stakeholder buy-in with a beautiful clickable prototype that exceeded all expectations.