The report told them what happened. They needed to know what to do first.
A sales organisation had years of data on every medical imaging system it had ever installed, and a set of models scoring which ones were worth an upgrade conversation. It all lived in an analytics report almost nobody could use without exporting to Excel first. I redesigned it into a role aware decision tool where the AI recommendations are explainable, arguable and approved by a human before they reach the CRM.
The visuals live behind a password
This was client work for a Fortune 500 healthcare company, delivered through Tata Consultancy Services. The thinking below is mine to share. The interface, the model names and the internal process are not, so the screens are not published here.
If you are hiring and want the full case study with all screens, ask me for the password and I will send it. It takes a minute.
What was actually happening
The client has years of data about every imaging system it has ever installed. Age, service history, contract dates, utilisation. A set of models scores that data to suggest which systems are worth an upgrade conversation. The output lived in a report of several dense pages, dozens of filters, and millions of rows.
The data was good. The workflow around it was not. When I sat with the sales team, this is what they were really doing:
- Open the report, wait. It was slow, and every page put a lot on screen at once.
- Give up on filtering in the tool and download a CSV or Excel export instead.
- Apply their own filters and formulas by hand to work out who to call.
- Manually push the shortlist into the CRM.
- Manually message the relevant sales user to tell them the opportunity existed.
So the intelligence was real, but it was arriving as homework. Every person in the chain rebuilt the same spreadsheet in a slightly different way, and the recommendations lost their reasoning somewhere between the export and the CRM.
They had built a very good answer machine, and then asked people to do the hardest part of the job in Excel anyway.
How I learned this
I did not run a formal lab study. This was an enterprise project with busy people, so I did research the way the project allowed: inside the working meetings. I spoke with the person leading sales for the region, with sales users themselves, and with people handling some international accounts.
Two things came out of that quickly.
The first is that the report and the job were shaped differently. The report was organised by data. The job is organised by time and by account. A sales person does not think "show me all systems where utilisation is below X". They think "it is Monday, which of my accounts is about to fall out of contract, and what do I say to them".
The second is that nobody fully trusted a score they could not explain. If the tool said a system was worth an upgrade, the first question was always "why this one". Without an answer, people fell back on their own judgement and the model may as well not have run.
This was not a reporting problem. It was a decision queue with an AI opinion attached, and the design job was to make that opinion legible, arguable and accountable.
Once I framed it that way, the structure of the product fell out of it. Instead of pages of filters, the tool follows the shape of the actual work: sense what is urgent, explore the account, act on it, report on what closed, and govern what the models are allowed to say.
What changed
- Several dense pages, dozens of filters
- Horizontal scrolling tables
- Same view for everyone
- Scores with no visible reasoning
- Export to Excel to get real work done
- Manual push to the CRM, manual handoff
- Seven purposeful views, one job each
- Expandable parent to account to asset, no sideways scroll
- Role aware: sales, manager, validator
- Every recommendation names the model behind it
- Filtering, comparing and acting happen in the tool
- Approve, then push to the CRM from the same screen
Designing the part that is AI
The models were not mine to build. What was mine was the question of how much authority they get on screen, and what a person can do when they disagree. That is the real design surface of an AI product, and it is where I spent most of my time.
Always name the model that made the call
Every recommendation shows which model surfaced it, in plain language, so a sales user can see the reasoning rather than just a number.
Offer alternatives, not a single verdict
Each asset carries priority ranked alternative scenarios. The tool has an opinion, but it shows its second and third choice too, so the human stays the decision maker rather than a button pusher.
Prioritise priority, not raw score
Sorting by model score produced a list that felt arbitrary to users. Ranking by business priority, driven by contract timing and urgency, matched how people actually plan their week.
Put a human gate before the CRM
Nothing reaches the CRM automatically. A validator reviews why each record surfaced, then approves or rejects it. Machine suggests, person decides, and the trail is visible.
Make it easy to say the model is wrong
The queue can flag questionable logic. During design we found a twenty year old system still being pushed as an upgrade candidate, which is exactly the kind of thing that quietly destroys trust if there is nowhere to report it.
The hardest part
Honestly, it was not the interface. It was the business logic underneath it.
This product sits between a lot of constraints. Several data sources feed it, several destinations depend on it, and different regions do not sell the same way. Every simplification I proposed had to survive a real edge case somewhere in the world.
The other hard part was people, in the fair sense. The existing report had been used for a long time, and familiarity is its own argument. Moving from "give me all the filters" to "the tool has an opinion and will rank things for you" is a change in mindset, not just layout. I had to show that the opinionated version still let an expert get to any record they wanted, otherwise it reads as taking control away.
What worked was arguing with a working prototype rather than a slide. When someone said "this will not handle my kind of account", we could open the thing and look.
I designed it, then I built it
Static screens could not answer the questions this project kept raising. Does the hierarchy still make sense at four levels? Does the detail panel work when an asset has six alternatives? So I built the whole thing as a working prototype in plain HTML, CSS and JavaScript, using Claude Code to move quickly.
Two deliberate choices there:
- No dependencies and no build step. It opens from a file, which means anyone in the business can click through it without installing anything. That mattered more than technical elegance.
- Structured like the real app. The data lives in one place shaped like an API response, and the views never touch raw records. When engineering picks this up for the planned build, swapping the demo data for live endpoints is a single seam, not a rewrite.
I also aligned it to the client's design system and brand, and kept it accessible: AA contrast, keyboard operable, status never carried by colour alone, and reduced motion respected.
The prototype ended up doing three jobs at once. It was the design artefact, the stakeholder demo, and the specification.
Where it stands
The product entered user acceptance testing with the regional sales team in July 2026. The people in it are sales users, business managers, validators and the product manager.
The change they describe is a workflow one. The work that used to be a chain of exports, manual filters and formulas, manual pushes into the CRM and manual messages to sales users now happens in one place.
Being honest about stage. This is in UAT, not yet fully rolled out, so I am not claiming adoption or revenue numbers. The measurable outcomes will come from that rollout, and the metrics I would judge it on are time from recommendation to CRM, the share of surfaced opportunities a validator accepts, and whether people stop exporting to Excel.
What I would do differently
I would push harder, earlier, for a way to measure trust. We designed a lot of transparency into this product on the reasonable belief that it builds confidence, but I would like a real signal: how often does someone open the reasoning, how often do they pick an alternative over the top recommendation, how often do they reject.
I would also test the role switching with people who hold two roles at once. Real organisations are messier than three clean personas, and a manager who also owns accounts is a case I would want to watch someone use.
The bigger lesson I took from this one: with AI features, the interface is mostly a negotiation about authority. How sure does this thing sound, how easy is it to disagree, and who is accountable when it is wrong. Getting that balance right mattered far more than any individual screen.