The product’s most used screens

Tradeverifyd helps companies see who they buy from, tier by tier, and what risk sits in that chain. The centerpiece is a supplier map: it starts from the customer's company and branches out to its suppliers, tier by tier, with risk scores, screening results and notes on every card.

People take what they see on these screens to their boss. If the screen looks sure when the data isn't, or doesn't show where the problem really is in the chain, the product fails at its only job.

Two backend fixes had just stopped the product from inventing suppliers when there was no trade data. The right call, with a side effect: a company with no records showed its own name and nothing else. A new customer's first screen was a lone box, with no status saying what had happened: still loading, something failed, or nothing found.

That blank was doing the work of four different situations, and the customer couldn't tell them apart. All four read as "they have nothing on us." A failed load even said "nothing here yet", exactly like a healthy empty map.

I wrote the analysis and the spec, then a small system around it: loading, genuinely empty, error, and a rule of never showing a raw error message. Designed once, reused on search, the supplier map and monitoring. I shipped a shared empty state with a tone, and the four map states on top of it. Then I applied the same kit to the events feed, which read like a debug view.

• Tone is part of the message. Finding no trade activity says nothing bad about the customer's suppliers, so that state stays neutral, never a warning color.
• Don’t fill an empty screen with the wrong thing. One idea was to show a related company that had more data instead. I said no. That company had been sold years before, and it only looked related because of an error in the data. Showing the wrong company is worse than showing a clear empty screen.
• Copy without promises. No apology, and no "we've flagged it" when nobody had agreed that this opens a ticket.
• Don't guess the state from counts. A map can be full of suppliers while the company itself connects to none of them. That turned the design into a backend requirement: the data has to say why a map is empty, not only that it is.
• Ship only what's true today. Only the failed-load state shipped behavior. The others waited until the data could say why.

Customers couldn't find the supplier that mattered. I walked the live product and logged nine problems: a nagging banner, a toolbar so full it clipped its own navigation, lines between suppliers you couldn't follow, a side panel that opened with an internal ID.

Then I counted what the cards carried on a large map. One label, about where the data came from, was on every single card, so it told nobody anything. The one supplier on a sanctions list looked like all the others, and its loudest element was that same label.

I brought the critique and the numbers to a UX call with product and engineering. We decided together: drop the data source label and keep a label only when it tells the customer something that matters, order suppliers by how critical they are, soften the lines, and put the score first in the side panel.

Then I turned the auto-generated meeting summary into one tracked list, fixed two errors in it, and flagged three items that read as decided but weren't, so nobody built them.

• Navigation where people look for it. The list of maps moved to the left, the map's title comes first, and the tabs sit right under it.
• The list shows each map's status. A risk dot per map, a pulse when something in it is critical, a warning, a loading sign. You know where to look before opening anything.
• Calmer connections. Softer lines that show the path without fighting the cards.
• Riskiest first. Suppliers ordered by risk grade, then whether they carry a finding, then how severe, then how close they are. A flagged supplier pulls its whole path up with it.
• Critical can't be missed. A serious finding, like sanctions or forced labor, turns the card red whatever the score says, draws its path in red, and drives the counts so the page can't contradict itself.
• No repeated information, and real flags. The label on every card and the internal ID are gone. Only what the customer declared and real screening findings get a tag. Country codes got real flags, not emoji, which break on Windows.

I built it as a prototype with the real product components, not mockups, with a note for engineering on everything the product still lacked for the prototype to be complete.

I filed the next layer as eight design issues: the overview, the header, a worst-first list, the hand-off to the AI assistant, lean cards, a side panel you can trust. While prototyping I also found a real bug, a score that never updated after discovery, and measured it before raising it: latent, not yet visible to customers.

Failed loads stopped looking like empty maps. The data now says why a map is empty, which the new screens need. The supplier map decisions were tracked from critique to shipped in one place, and the next layer is defined as eight design issues.

To be clear: the prototype was never meant to be merged. It was the spec engineering built from.