Product Designer since August 2024, hired by CONVO to lead design on XTEL and embedded full time in their product team. XTEL is trade promotion software for global consumer goods companies — where they plan and settle promotional spend, one of the biggest costs on their books.
Enterprise software · Design systems · AI interaction
Islamabad, Pakistan — Working globally
Umar Usman — Product & UX Designer . I design enterprise tools for people who move billions in trade spend.
They can’t afford to guess what a button does.
Selected workI designed our AI assistant using Microsoft’s own guidance for Responsible AI, HAX and Copilot, in workshops run with their design team.
XTEL’s own launch describes the platform as supporting more than 100 global consumer goods companies and managing over €350 billion in annual trade spend. That is the system I design.
On the platform
The people who move that spend
Coca-ColaNestléWalmartTesco
These are manufacturers and retailers on the platform I design. I ran research sessions with their commercial teams and designed against what came back — promotion planning and settlement, and retail execution and assortment at shelf level.
To be exact about my own position: I am the product designer on XTEL, engaged through CONVO Corp and embedded in XTEL’s product team. These are the businesses that use what I build, not my own accounts.
Platform scale and the Microsoft integration are XTEL’s own published figures — “XTEL Unveils Enhanced Trade Promotion Management, Revenue Management AI Technology for Global CPGs & Retailers, Powered by Microsoft”, 22 January 2026.
Approach
Enterprise software fails quietly. Nobody complains — they just build a spreadsheet next to it. My job is to find where the product stopped being worth the workaround.
Selected work
Three projects — XTEL, 2024–2026
The AI assistant
01Designing where AI enters an enterprise data tool, what a conversation looks like beside a table, and — mostly — what happens when it is wrong.
Read caseThe platform redesign
02A decade-old trade promotion platform rebuilt around how trade teams describe their work, not how the database stores it.
Read caseThe design system
03A token and component library, built on WCAG 2.2, replacing an Adobe XD-era system that had stopped describing the product it shipped.
Read caseCase 01 — AI assistant
I built an assistant that sits beside the work, not on top of it.
Everyone agreed we needed AI in the product. Nobody could say where it should go.
The AI itself runs on Microsoft’s platform, and after meeting their team we built against their guidance for assistive AI. I wasn’t working on the models. I was working on everything around them: where the AI shows up, what a conversation looks like inside a data tool, and what happens when it gets something wrong.
One constraint shaped the whole thing. In this product a number turns into a funding decision, so if someone can’t check where an answer came from they won’t use it. That's worse than not having it.
A full-screen assistant demos beautifully. Then it opens, and you can’t see the table you were asking about.
We built it as an assistant rather than an agent. It helps you find things, understand them and act on them, but it doesn't do the acting for you. The people using this move real money, and none of them wanted software making those calls on their behalf.
Three ways in, all compatible, none of them a new pattern.
I didn't want to invent a new way in, so I followed Microsoft’s guidance and used routes people already expect. It should feel like part of the product, not something bolted on.
Persistent navigation
It has its own place in the sidebar under “Your AI assistant”, so people find it without being shown.
Global header
Reachable from every screen, always in the same spot.
Contextual, from a record
Opened from inside a record, it already knows what you are looking at, so you don't have to explain it.
Microsoft trained us. Then we had to apply it to trade promotion.
We ran workshops with Microsoft's design team instead of inventing our own house style for AI. I kept the framework names in the specs on purpose. It means an engineer, or a client's auditor, can check the work against something published rather than trusting a designer's opinion.
Six principles as review gates
Fairness, reliability and safety, privacy and security, inclusiveness, transparency, accountability. I used these as an actual checklist each AI screen had to pass, not as a slide in a deck.
Guidelines across the interaction arc
Microsoft Research's Human-AI eXperience guidelines, grouped by when they apply: at the start, during use, when the system gets it wrong, and over time. Most products skip the "when it gets it wrong" group. That's the group I spent the most time in.
A shared pattern language
Invocation, prompts, citations, explainability, AI notice, latency, history, error handling, added friction. Working to named patterns meant I could hand engineering a spec they could argue with.
The framework also settled the biggest question early. Microsoft splits Copilot experiences into immersive, assistive and embedded. We went with assistive. The AI sits next to the work and helps, but it doesn't run the workflow. Given what a wrong move costs the people using it, that was the only version they wanted.
Most of the work went into the states you never see in a demo.
A demo is one question and one good answer. Real use is slow responses, questions the system can't handle, answers that sound confident and aren't, and actions that move budget. People decide whether to trust the thing in those moments, so that's where most of the spec went.
Say what it is doing, not that it is busy
When we can estimate how long something takes, the bar actually fills and the word matches the job. "Analyzing" tells you it understood the question. A spinner just looks stuck.
When you cannot predict the wait
When we can't estimate it, the indicator loops instead of filling, so we aren't promising a finish time we do not have.
Before the panel is ready
The panel loads into a placeholder so nothing jumps around, and if you type before it's ready you get told, instead of nothing happening.
No answer is a designed answer
When nothing comes back it says what it couldn't find and what would help. We wrote fixed copy for the failures we could predict, and let the model generate only for the ones we could not.
Never a dead end
Every dead end offers the nearest useful thing instead. People stop asking after they hit a wall twice, so we made sure there wasn't one.
Every number carries its receipt
Answers show the records behind them, inline. Checking takes a glance instead of a second question. This was the condition we got the feature approved on.
Slow down before money moves
Anything that changes committed spend doesn't happen on one click. It tells you what it's about to do, in money, and asks again.
Reallocate €180K of Q3 budget?
This moves funding from three approved displays to price reductions. Approvals will need to run again.
Say it is AI, every time
A notice on every generated response, not a one-time consent screen. In an interface this dense people forget which parts came from a model, so we label all of them.
Make the wrong answer useful
Thumbs down opens a short list of reasons instead of an empty box, so we get something we can count. There's a free text field for whatever the list misses.
Why wasn't this helpful?
Inaccurate or irrelevant · Took too long · Wrong records · Other
Four calls that shaped the pattern.
Each one came from watching what happens when a domain expert is handed a chat box and no context for what to say into it.
- 01
Sidepanel, not takeover
Anchoring the conversation beside the data means every answer can be checked against the rows that produced it, without leaving the screen.
- 02
Suggested prompts as onboarding
The blank input is the real onboarding problem. Prompts are drawn from the user’s own domain, so the first question teaches the shape of every question after it.
- 03
Answers cite their source
Every response surfaces the records behind it. Verification is one glance, not a second query.
- 04
Designed failure
When the assistant cannot answer, it says what it couldn't find and hands back the filter that gets closest — instead of guessing.
| Description | Customer | Total | Code | Status |
|---|
AI where the decision gets made, not in a separate chat · click to enlarge
Case 02 — Platform redesign
Rebuilding a trade promotion platform around the people who use it every day.
One of the biggest costs in the business, and nobody had designed for it.
After the cost of making the product, trade promotion is one of the biggest things a consumer goods company spends on. It covers every discount, in-store display and retailer deal that gets a product onto a shelf.
XTEL builds the software where that money gets planned, approved, spent and settled. Five different roles work in the same platform on the same numbers, and each of them means something different by “finished”.
The people using it know trade inside out. They don't know software, many of them work in a second language, and they're all on quarterly deadlines. When a screen looked dense they read it as complicated, and when it looked complicated they stopped trusting it.
I audit every release, and log it the way engineering logs bugs.
Design quality doesn't fall apart during a redesign. It slips release by release, in the gap between what was specified and what got built. So I audit every version and keep the findings in a database instead of a document, tagged so engineering can pick them up directly.
Findings logged per release audit. Separate audits cover the AI assistant, XTEL Studio and PCO. The drop after 9.2 is the point of doing it: issues raised in one audit stop showing up in the next.
| Finding | Type | Criticity | Environment | Spec |
|---|---|---|---|---|
| Filter column loses selection on reload | Impl. vs spec | High | General build | Figma ↗ |
| Saved filter set not visible to shared users | Impl. vs spec | Medium | General build | Figma ↗ |
| Navigator column order resets between sessions | Suggestion | Medium | Client build | Figma ↗ |
| Row action target below minimum size | Design bug | High | General build | Figma ↗ |
| Empty state offers no next action | Enhancement | Low | Test build | Figma ↗ |
- 01
Implementation vs specification
Most of what I find is the build drifting from the design file. Giving that its own category means it shows up as a tracked issue rather than a designer complaining about details.
- 02
Generic build and configured build, audited separately
Every client’s deployment is configured differently, and the configuration changes the experience. If I only audit the generic build I'm missing the version people actually use.
- 03
Every finding linked to its frame
Every entry has the Figma link for the screen it's about, so nobody has to guess which state I meant.
- 04
Prioritised into delivery, closed by re-audit
Findings get prioritised into the delivery backlog and fixed in the release cycle. I check they are actually gone by auditing the same screens in the next version. If it doesn't come back, it's done.
- 05
Flow audit before redesign
Before the redesign I mapped every core journey end to end: each screen, state, empty case and dead end. Then I interviewed users to check whether the map matched what they actually did.
From a list of everything to the five things people actually say.
The old navigation listed every function with equal weight. People opened it and went straight back out. I regrouped it the way trade teams describe their own work: top down, bottom up, execution, resolution, analysis.
It wasn't a reskin. We rebuilt four systems underneath the product.
“UI revamp” is what this gets called in a status update. What it actually meant was rebuilding the pieces the whole platform is made of. Every module uses them, so every decision landed everywhere at once.
Navigators
The list screen every module is built on. One set of patterns, then the variants the product actually needs.
- Editable and read-only tables
- Priority column and status treatments
- Consolidated view
- Empty and no-result states
Filters
Rebuilt from a control decided per screen into something people could save, share and come back to.
- Advanced filter panel
- Column-level filtering
- Saved filter sets, private or shared
- Clear all and remove-set behaviour
Mass operations
Editing hundreds of records at once, without the old flow’s habit of leaving you unsure what you just changed.
- Mass edit across selections
- Mass copy with scoping
- Single and multiple deletion, with clear consequences
Documents
The record itself: how a promotion gets read, changed and moved through approval.
- View and edit modes
- Document navigation
- State and workflow feedback
- IBP document flows
Fixing the filter panel fixes filtering in every module. That's the case for doing this as systems work rather than screen by screen, and it's the case I had to keep making internally.
Three questions, answered before anyone clicks.
Where am I against target, what needs me today, what's broken. The landing screen answers those three and pushes everything else down a level.
Tasks are grouped by priority instead of by module. Nobody starts the day thinking “I will go to the deductions screen”. They start it wanting to know what's late.
Volumes
Trade spend
Gross sales
78%$4.220.321$6.122.000Net sales
78%$4.220.321$6.122.000Margin
78%$4.220.321$6.122.000Click any screen to enlarge · placeholder data throughout
Case 03 — Design system
The product had no shared language. So I built one.
An interface designed by the people who built it.
That's not an insult, it's what the old screens show. The platform had grown feature by feature for over a decade on a design system ported out of Adobe XD, and it was showing on the screens people actually used.
[GUIREFERENCEDOC.REFERENCEDOC.CODPARTYDESCRIPTION]
Field labels were printing the database binding path. Not in a debug view — this is the screen a key account manager used to build a promotion. Whole sections of the form were named after the schema.
Force Uppercase on validation: Mandatory Field Empty
This error message is the internal rule name stuck onto the failure condition. It tells you what the validator is called. It doesn't tell you which field to fix.
Field Examples · Grids Examples · Panel Examples · amCharts
The navigation included the component test pages, and listed a charting library as a menu item. People were browsing the development environment.
[POPUPWITHGRIDVALIDA…
Buttons showed truncated internal identifiers. The text was too long for the button because nobody had written one. The identifier was the label.
Consistency here isn't about looking tidy. It's what stops people re-checking every screen before they commit to it.
I treated accessibility as a constraint, not an audit.
I built on WCAG 2.2 from the first token instead of retrofitting it later. When someone has been reading a table for eight hours, contrast, target size, visible focus and keyboard order stop being accessibility features. They're the difference between getting the number right and getting it wrong.
Nothing shows status through colour alone. Every state has a colour, an icon and a word, so it still works for colour-blind users and on a printed export.
I specified every state, not just the one that works.
Buttons
Minimum height 40px, 44px for row-level actions. Disabled states keep 3:1 against the surface so they stay findable.
Inputs & validation
Labels stay visible. Errors sit next to the field and say how to fix it, not just at the top of the form.
Status
Five states, one shape. The dot gives you the colour and the word gives you the meaning, so neither is doing the job on its own.
System metrics
Same product, three years apart. Drag the handle.
On the left is the platform as I inherited it, rebuilt from the legacy screens with the original labels. On the right is where it is now. The density is what people notice first. The part that mattered was giving every field a name a person had written.
Available Fields
Outcome
What I can and can’t tell you.
The redesigned platform and the AI work became the version we took into new business conversations, and leadership presented it internally as one of the things behind new client wins.
The numbers behind that were shared internally and they are under NDA, so I'm not putting them on a website. I'm happy to talk through the shape of them, and about how much I'd actually attribute to design rather than to the rest of the product.
Commercial results under NDA
What I would do differently.
I built the design system and the redesign at the same time, because the roadmap wanted screens before it wanted foundations. The first flows shipped on tokens that changed underneath them, so we did that work twice. Next time I'd lock colour, type, spacing and states before anything goes into build.
About
Background
I like the products nobody puts on Dribbble.
Most of what I've worked on is software people are paid to use. That's the part I find interesting.
Consumer products can win on how they feel. Enterprise products win on whether someone can finish a task correctly and quickly on a Tuesday afternoon, with a deadline and a spreadsheet open next to them. Getting that right takes research, a system, and being willing to delete things that took someone else three months to build.
I work closely with engineering and I read the code my designs ship into. I'd rather build a pattern that survives implementation than one that looks good in a screenshot.
-
CONVO Corp — client: XTEL, a Kantar company2024 — PresentProduct Designer — design system, platform redesign, AI integration
Contact