Jardin was targens' first product for mid-sized companies, and I was its only designer. I joined two of them into one record, from adding a business partner to the person who signs off its risk.
targens had built compliance software for banks for thirty years. Jardin was its first product for mid-sized companies that have to prove who they do business with, and it existed as a vision deck, with every role worked out in detail and each one in its own flow.
I was the only designer, with a researcher and the client's product manager. In six months, from two days of kick-off, the deck became one process, tested with people who do this work and solid enough to show to buyers before it was finished being coded. I ran the information architecture workshop, designed every flow and screen, and built the design system, including the brand and colour work.
They knew the domain. I knew the questions I needed to ask.
Their product manager had worked in compliance for years: the departments, the stages, the data sources and the approval rules were all clear. Every role was worked out in so much detail that each one lived in its own flow, and the process running across the three was still to be drawn. The questions I asked as a newcomer were the ones the people using it would ask too.
I set out to understand the work of a risk analyst and a data collector in depth: what they look at, how, and where. The flow came out of that.
The collector and the evaluator turned out to be looking at the same company at two different moments of its life: same business partner, same documents, picked up later by somebody else. I noticed it when I put the two role descriptions side by side on one page. Described one at a time, they looked like two different jobs. Drawn as one record moving through stages, most of the duplication was never built.
For the client, every field was essential. The job was not to hide information. It was to decide what the person needed to know first.
I facilitated the information architecture workshop with their product people in the room, laying out what lives where together instead of me proposing a structure for them to react to. A structure the client helped build is a structure the client defends later, and on an agency project that matters: I was not going to be in the room when somebody proposed changing it.
One status for the whole case, the same on every screen.
How much data is still missing, so everybody can see how far the case is from being evaluated.
No result is not the same as a clean result, so it gets its own state.
When a system does part of the work, the screen has to make clear what came from the system and what the person still decides.
The scoring was in the client's vision. What it should look like was not: the analyst has to see how the system reached a score, and be able to disagree with it. Any score can be changed, as long as the evidence for the change is attached. I tried several formats before landing on the order the decision is actually made in. It is dense on purpose, because the alternative is a summary somebody has to take on trust. The requirement was theirs. The format was mine.
The number is always there, never a label on its own.
Every red flag underneath carries its own weight.
The data item, its value and its source, one click away.
The analyst confirms each flag, or changes the score with the evidence attached.
In a product where somebody signs off on a risk, colour is the fastest thing on the screen, and it has to say the same thing every time.
I wrote the system so somebody who had never met me could build the next screen: status colours defined once, every state of every component, and the decisions from the flows turned into components. I was going to leave, and the file was going to stay.
Wherever the business partner appears, its state reads the same. Five status colours, each defined once with its hex, and the header carries them all.
Including the one nobody has looked at yet. A risk nobody has examined is a different fact from one that came back clean, and the person who signs it off needs to see the difference.
It came out of drawing the flows, and it went into the system with its wording already written. That is how a decision survives the person who made it.
This was 2021, and there are no tokens in the file: Figma shipped variables after the project ended. Today I would add that layer, so the status colours become names instead of hex codes, and make the risk chips readable without colour, which I learned a year later at BlackRock.
A researcher at the agency recruited and analysed. I was in the prep sessions where we wrote the questions, and in every session, asking follow-ups when something needed pushing. The client recruited their own contacts, which in a field this narrow makes sense, and they were very sure of their hypotheses. So what we learned went onto the architecture itself, next to the node it was about, where it would still be when somebody asked the same question after I left.
The one 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.
The screens worked; the order of the steps was not obvious yet. A task-completion score would have called that round a success. Usable and guided are not the same thing, and that was the next thing to design.
Jardin was my first product in compliance. Since then, from the charts at BlackRock to Bicho Feliz NGO, I keep designing for people who have to trust what a system tells them.
Hola, I'm Lu. Senior Product Designer, 6+ years across different industries. I start with the real problem, make complexity understandable, and stay close to the outcome. More about me →
