They had been doing this for thirty years. That was the hard part.
targens built compliance software for banks, and seven of the ten largest in Germany ran on it. Jardin was their first product for somebody else entirely: mid-sized manufacturers and traders who suddenly had to prove who they do business with. They needed to show it to buyers before it was coded, and what they had was an idea and no design at all.
Companies have to check who they do business with: suppliers, partners, customers. Are they sanctioned, are they clean, do they meet the standards you are legally on the hook for. In a large company that is somebody's full-time job, and it is mostly done in documents and spreadsheets.
The product let a company design that checking process itself, then run it. An administrator defines what gets evaluated and who is allowed to evaluate it. People collect the information and the documents. The system scores each risk factor from what was collected, and a person reviews the score, because a number a system produced is not a decision.
The only designer on it. I built the design system, ran the brand and colour work, facilitated the information architecture workshop, drew every flow, and designed the screens. A researcher at the agency recruited and analysed; I was in the prep and in every session. The client brought the compliance knowledge, and I brought the questions that turned it into something you could put on a screen.
Four steps, three people and a machine
Three roles, and we spent the first weeks tying ourselves in knots trying to hold all three in our heads at once. So we stopped and did them in order of how clear they were: the one who collects first, then the one who evaluates, and the administrator last, because it was by far the most complicated. Three flows, three milestones, at weeks five, nine and thirteen.
An administrator builds the process
Inside the company that bought the software. Decides what counts as a risk here, who may evaluate it, and in what order. The only one of the four steps that is not about another company.
Somebody collects the data
Adds the business partner, chases the documents, fills in what is known. Usually the person closest to the relationship and the one with the least time.
The system scores it
Against sanctions lists, external databases and news sources, following the process the administrator built. It produces numbers, not decisions.
A person checks the score
Goes through what the system found, decides whether it is true, and signs it off. The name on the decision.
A slide deck, and nothing else
There was no prototype. There was no design. There was a presentation of the idea, written by their product manager, who knew compliance inside out and had written it for people who already did too. On their side there was also a developer who could put a screen together when she had time.
- Plenty of assumptions, and no agreement on who the user actually was.
- No customers yet, so nothing to check those assumptions against.
- A domain nobody at the agency knew. The client had a product manager who knew it inside out, and thirty years of knowledge does not transfer in a meeting.
- And the reason they had called us: they wanted to validate the product and start selling it before it was finished being coded.
The kickoff was two days, and most of it went into finding out how little was settled. What came out was deliberately modest and I still think it was the right call: a base design system, the whole workflow in low fidelity, and a small set of high fidelity screens they could put in front of a customer.
Not a finished product. A thing solid enough to have a real conversation with a buyer, and to find out from that conversation what should actually be built. Three flows, three milestones, at weeks five, nine and thirteen. It ran from July to December.
Two of those flows were the same company, twice
The client described the product as three workflows, one per role, and drew them as three separate things. The administrator genuinely is separate: they work inside the company that bought the software, setting up how it will evaluate everybody else. That one stands on its own.
The other two do not. The collector and the evaluator are looking at the same company at two different moments of its life. Same business partner, same documents, same history, picked up later by somebody else. Drawn as two flows they need two sets of screens that have to be kept in sync. Drawn as one thing moving through stages, most of that duplication disappears.
That is the most useful thing I did here, and it came out of drawing the flows rather than out of a workshop. You do not see it while people are describing their jobs to you. You see it when you try to put both descriptions on the same page.
Not a sitemap. What the thing is, and what hangs off it.
Drawing the flows also turned up a hole. When you add a business partner, it may already be in the system, added by another department under a slightly different name. Nobody had raised it, because it is not in the happy path anybody describes when they explain their process to you.
So adding one starts by looking for it: you see what already exists and what you typed, side by side, and you decide. It costs a step at the exact moment somebody is in a hurry, and it is cheaper than the same supplier being evaluated twice by two departments who do not know about each other.
For them, everything was important
The client knew compliance far better than I ever would, and that came with a cost: every field they described was essential, every screen had to show everything, and no order was more correct than any other. Deciding what appears when was the whole job.
The overview is where that got resolved. Not by hiding anything, but by putting the state of the work first: twenty-eight data items, seven of them filled in, six steps in the process, you are on the second.
And a word that mattered more than it looks: not evaluated. A risk category nobody has examined yet is a completely different fact from one that came back clean, and a system that shows both as empty is lying to the person who has to sign it off.
What stage the case is at, what has been filled in, and what nobody has looked at yet.
The risk evaluation screen is the one I am most attached to. They had the requirement and no idea what it should look like: the evaluator has to see how the system reached a score and be able to disagree with it.
I tried several shapes before this one. A risk factor, the red flags underneath it, the individual data items behind each flag, and the value of each. Three lenses over the same partner, so you can work in the order the decision gets made rather than the order the data was entered.
It is dense on purpose. The alternative is a summary somebody has to take on trust, and this is a person whose name goes on the decision.
The format was mine. The requirement was theirs.
Two workshops, and one argument I half lost
Information architecture
I facilitated this one. Getting the client's product people into a room to lay out what lives where, together, rather than me proposing a structure and them reacting to it. Structure that a client helped build is structure a client defends later, which matters more on an agency project than on any other kind: I was not going to be in the room when somebody proposed changing it.
Brand character
First a session to find out what they actually expected the product to look like, which for a client like this is mostly a list of things they do not want to look like. Then I went away and came back with directions, and we refined them together over several rounds. Asking first and proposing second is slower and it is the only version that survives contact with a founder.
They wanted black buttons
They wanted the whole interface in black and white, with colour reserved for the risk chips. It is a defensible instinct: keep the palette out of the way so the only coloured thing on screen is the thing that means something.
Black and white everywhere, including the buttons. Serious, expensive, and no colour competing with the risk indicators.
A black button is not the absence of colour, it is the heaviest element you can put on a page. In a screen already carrying red, amber and green that mean something, it wins attention it has not earned.
We got past the black buttons. The direction they landed on is still not the one I would have chosen, and it was theirs to choose. It is their brand and they are the ones who have to sell with it.
What I took from it is the thing I have used most since: when someone is certain, arguing from design principles loses. Showing them costs less than you think. Put both versions in front of a person and let the screen make the case, and be ready for the screen to say they were right.
Looking at it now, the risk chips were doing too much on colour alone. There was a yellow in there that technically passed contrast and still worried me, and the categories were separated by colour with a number beside them, which is not the same as being readable without colour. I did not have the vocabulary for that yet. I learned it the year after, at BlackRock, where accessibility was a delivery requirement rather than a preference, and it is the first thing I would redo here.
And the system underneath it
Not a component library. The rules that let somebody build the next screen without asking me, which on an agency project is the whole point: I was going to leave and the file was going to stay.
Colour that has to mean something
A primary, a secondary, a set of backgrounds and five status colours, each defined once with its hex value and then applied everywhere a business partner has a state. The header component alone carries seven of them: in evaluation, go, terminated, no go, not started, critical. In a product where somebody signs off on a risk decision, colour is not styling. It is the fastest thing on the screen and it has to say the same thing every time.
The rule of 8
White space divisible by eight: inside an element, between elements, and between sections, each with the values drawn out. It is the least glamorous page in the file and the one that decides whether somebody can build from it without asking me. A system is not a set of components. It is the rules that let a person who has never met you place something correctly.
Every state, not just the happy one
A text field is not a rectangle. It is default, labelled, focused, error, disabled, and the same again as a text area. The same for buttons, selection controls, sliders, loaders, even the scrollbar. Whatever is missing here gets invented later by whoever happens to be building that day, and then there are two versions and nobody knows which one is right.
A product rule, living as a component
The disclaimer that appears when the partner you are adding already exists, telling you that continuing will take you to the existing relationship instead. That decision came out of drawing the flows, earlier in this project. It ended up in the system as a component with its wording already written, which is how a decision survives the person who made it.
There are no tokens and no variables in this file, and that is a date rather than an omission. Figma shipped variables two years after this project ended. What the file does instead is what you could do in 2021: styles named by role rather than by size, a spacing rule written down, and colour that carries meaning instead of decorating.
If I rebuilt it now the first thing I would add is a token layer, so the status colours stop being hex values somebody has to remember and become names an engineer can import. The rest of the thinking would stay where it is.
A design system, three flows, and one of them finished
Not a product. A thing solid enough to sell with, and specific enough that whoever built it afterwards knew what they were building.
A base design system
It started as the brand work and turned into components: inputs and their states, tables, pills, alerts, the navigation, the status colours. Enough for somebody else to keep building without inventing.
All three flows, in low fidelity
The collector, the evaluator and the administrator, end to end. Low fidelity on purpose: at this stage the argument is about sequence and structure, and a finished-looking screen ends that argument early.
The main flow, finished
One complete path in high fidelity, from adding a business partner to evaluating its risk. The one they could put in front of a buyer.
Add a business partner
You type a name and a headquarters, and the screen answers with what it already knows.
The same supplier gets added by three departments under three slightly different names, and then the same risk work happens three times, or once and nobody knows which. So adding one starts by looking for it. It costs a step at the moment somebody is in a hurry, which is exactly why it had to be tested rather than argued about.
Say what it is
Before anything can be evaluated, somebody has to say what this company is to us. A supplier, a customer, a sales agent, and how far the relationship goes.
That classification is not admin. It decides which risk model applies, which questions get asked and who has to answer them. So it is four short steps with one decision each, instead of one long form that people fill in badly and nobody checks.
Collect the data
Twenty-eight data items, seven filled in, six steps in the process and you are on the second. The state of the work comes before the work.
Some of it arrives on its own from an external system, and some has to be researched by a person: public documents, an interview, a form somebody fills in. The screen keeps the two apart, because one of them is free and the other one is somebody's afternoon.
Evaluate the risk
The last step, and the only one where a person overrules a machine. The system has scored every red flag it found. This is where somebody goes through them and confirms, or does not.
The requirement was theirs and the format was mine, and I tried several before this one. It stays dense on purpose: the alternative is a summary that the person whose name goes on the decision has to take on trust.
Testing a product for five companies
A researcher at the agency recruited and analysed. I was in the prep sessions where we wrote the questions, in every session listening, and asking follow-ups when something needed pushing.
What the research could and could not settle
Learning the domain. I could not have read my way into this. Every time somebody walked through a real example an assumption turned up underneath it, theirs or mine, and those were the questions worth taking back into the design.
Change their mind. The client recruited their own contacts, which in a field this narrow is understandable and is not a clean sample. They were very sure of their hypotheses, and findings that pointed elsewhere had a hard time landing.
A finding that cannot win an argument this month can still be there when somebody asks the same question next year. So the findings went onto the architecture itself, attached to the node they were about, instead of into a report that gets read once and filed.
On an agency project you are gone long before most decisions get revisited. The artefact is the only part of you that stays in the room.
What did make it through is on this map. The navigation, with the findings stuck to the node they belong to: what people expected there, what they did instead, and what it broke.
One that I still think about came from the last round. Everybody completed every task without help, and then said they would rather the system led them. “It is not immediately clear to me which steps come first and which come next.” Usable and guided are not the same thing, and a task-completion score will never tell you the difference.
Every box carries what we learned about it.
I never saw it launch. I heard about how it ended.
BlackRock came up and I took it, in the middle of a project I liked. Another designer picked it up and we overlapped for two weeks, and I left a Figma file built to be inherited: what existed, what was missing, and why the decisions were the decisions.
Jardin launched in July 2022, for exactly the customer the kickoff had argued about. targens was acquired the following year, and during the integration the product was discontinued. It is not out there any more.
There are no metrics I can give you, and I have made my peace with that. What I have is that a product with no design at all in July was being sold to customers a year later, that the client kept extending an engagement they could have ended at any milestone, and that they sent an external agency team a Christmas present.
The product is gone. The work still counts.
My first properly technical project, and the one I still borrow from
I did not know this world existed. I had never thought about the people whose week is spent checking, at that level of detail, whether a company is what it says it is. Finding out that a job like that exists, and then making the tool that makes it lighter, is the most satisfying thing I have done as a designer, and it is the shape of nearly everything I have worked on since.
Concretely, three things came out of here and went straight into BlackRock and then Jimdo. How to run a workshop when a room does not agree. How to organise information when everything is important to somebody. And the one about the black buttons: when someone is certain, design principles are the weakest argument in the room. Test it, show them, and let the result do the talking. Sometimes it says they were right.