15+ years in design, across large organisations and early‑stage teams. Today, interfaces for dense tools: what each screen shows, in what order, and every state in between.
Freelance for now, open to a full-time role, on-site or remote. A 20-minute call is the quickest way to see if it fits.
Lagoon lets professional managers run investment funds on the blockchain. A manager, called a curator, deploys a vault, sets its rules and fees, and runs its strategy. Depositors pick a vault, put in stablecoins like USDC, and earn its return. Since everything runs on-chain, every holding, fee and permission is public. I was the first designer: the brand, the landing pages and the whole app, for both sides.
RoleFounding designer
ScopeBrandProduct
Scale$300M+ deposits at peak
The landing page: the brand's sky behind one promise, modular infrastructure for on-chain vaults.Further down the landing page: one block per capability.
2024 to 2025, a small team. The contracts and the specs existed; there was no interface and no brand. The specs said what data each page needed. How it flowed and how it read was mine, on both sides of the product. The engineers built the front-end.
The list keeps the convention: one rate per vault, over three periods, with a mark when extra rewards apply.
Yield is not one number
In this market, yield comes from very different places: the manager's strategy, rewards paid as extra vault shares, tokens claimed elsewhere, points. The convention on a vault list was one number.
We kept that number, because people expect it there. On hover it opens into four groups, each with one line saying where it comes from. A figure that can't be computed on-chain says "est.", and the rate shows over all time, 30 days and 7 days, so a new vault can't look better than it is. That shipped, and the logic is still in the product.
A vault card and the breakdown behind its rate: base yield, additional yield, external rewards, points.
Every decimal, without the noise
Managers need every decimal: a price per share runs to sixteen of them. Depositors need one figure. So the significant digits are bright and the rest is dimmed. The manager can check, the depositor reads it at a glance.
The share price, and a second curve with the rewards it can't show. Magnified: the bright digits and the dimmed ones.Composition, activity, details: what a depositor used to read in a block explorer.
Show where the money is
A deposit is a request: it waits until the manager settles the vault. So pending requests sit next to the balance, each with its state, and every action ends on a confirmation.
Every state a request can be in, next to the balance it will change.Confirm, depositing, deposited. The same condition is repeated at each step: the position activates when the curator approves.A full position: deposit, claim the shares once the vault settles, request a redemption, withdraw.
Check a valuation before it moves the share price
In the first version, whoever valued the vault typed one figure and checked it by hand somewhere else. I designed a live simulation: type the new total, see every figure it changes, fees included, then submit. The manager approves and settles.
The valuation typed, then simulated: every consequence on screen before anything is submitted.
Trust in layers
Anyone can deploy a Lagoon vault. The public list only shows managers Lagoon has onboarded. Any other vault can still be shared by link, and it opens under an alert: unverified, closed, or suspicious settings. The vault page then holds the full detail.
A vault reached by link, and the three alerts it can carry.
The brand
The symbol in three parts, one per promise: yield, flexibility, security.Marketing visuals for launches, integrations and partnerships.
Lagoon, in depth
10 min read
Lagoon lets professional managers run investment funds on the blockchain. A manager, called a curator, deploys a vault, sets its rules and fees, and runs its strategy. Depositors pick a vault, put in stablecoins like USDC, and earn its return. Since everything runs on-chain, every holding, fee and permission is public. I was the first designer: the brand, the landing pages and the whole app, for both sides.
RoleFounding designer
ScopeBrandProduct
Scale$300M+ deposits at peak
The landing page: the brand's sky behind one promise, modular infrastructure for on-chain vaults.Further down the landing page: one block per capability.
Lagoon is permissionless vault infrastructure. A manager, called a curator in the product, deploys a vault and runs its strategy. Depositors put money in and get vault shares back. The first release came out in November 2024; from April 2025 anyone could deploy a vault. Deposits on the platform passed $300M at their peak while I was there: the platform's figure, not a design result.
Role & team
First designer, freelance. Full time from August 2024, part time from May 2025. The brand, the landing pages and the whole product, depositor side and manager side. The engineers built the front-end.
Specs first. The CTO acted as product manager. The team had started on the contracts before I arrived, and the specs came as event-storming boards for deposit and withdrawal, then lists of what each page had to show. What the data was, was settled. How it flowed and how it read was mine.
Wireframes before the interface. The wireframes went to the developers in October 2024, before any visual design, after a structured feedback session with the team. The interface followed from mid-November. A two-day preview for advisors and shareholders came before launch, and a second version in spring 2025 was redesigned from what the first one taught us.
The vault page in the October 2024 wireframe, and in the design it became. One APR field became a rate over three periods.
Constraints
No direct access to users. Requests came through the founders and business development. The reference user was the CEO, himself a fund manager: the tool was first built for his fund.
We were our own depositors. The whole team had used these products for years. Fast, and blind to anyone new to them.
The contract set rules the interface had to make obvious. Deposits and redemptions are requests that wait for a settlement. A deposit request can be cancelled, a redemption can't. Some vault settings can never change once deployed.
Wording under regulatory pressure. Regulators were starting to look at the sector, and the market avoided words that imply a regulated activity. In November 2024 "Asset manager" became "Curator" and "NAV committee" became "Price oracle". The interface had to be exact without promising what the law reserves.
No product analytics. Nothing was tracked.
The real job
Before Lagoon, a careful depositor did their due diligence in a block explorer: who manages the fund, where the money sits, what the fees are, who deposits and who withdraws. Technical and slow. So the job wasn't "show vaults". It was let me trust a stranger's fund without reading the blockchain myself.
Lagoon's positioning was transparency. Everything is verifiable on-chain anyway, so making it readable served depositors and the business at once: it made the managers' numbers credible.
Yield on the list
I benchmarked every product doing on-chain fund management. The convention on the list was one number; some put rewards in a separate column or explained them only in their docs, some didn't split them at all. What was missing was a breakdown at the moment of choice, the same for every vault, with uncertain figures labelled.
Three options. One net rate: expected, but it hides the sources. The full breakdown on every row: honest, but unreadable with many vaults side by side. The convention, opened on hover, with a marker when extra rewards apply and three time windows: that's the one we shipped. The cost: the headline number still flatters the vault for anyone who doesn't hover.
The list keeps the convention: one rate per vault, over three periods, with a mark when extra rewards apply.
The breakdown sorts very mixed rewards into four groups, broad enough to hold them and narrow enough to avoid exceptions: base yield from the curator's strategy, additional yield paid as vault shares, external rewards claimed elsewhere, and points. A figure that can't be computed on-chain says "est.". Managers often wanted to show raw performance; I held that not all yield is equal, and the breakdown shipped with that copy.
A vault card and the breakdown behind its rate.
Performance the share price can't show
The price per share rises with the manager's work. But much of the gain in this market arrives as extra tokens from the protocols the vault uses, passed on to depositors as additional shares. The share price alone understates what the vault returned. So the chart carries a second curve with those rewards included, and marks each reward event.
The same chart shows the precision rule: "1.09" bright, the rest of "1.0924 USDC" dimmed.
Two curves, reward events marked. Magnified: the bright digits and the dimmed ones.
The vault page as due diligence
Everything a depositor used to dig out of the explorer, in tabs: performance, overview, composition, activity, details. Composition goes down to the wallets and exchanges that hold the money; details lists every contract and every role with its address.
The CTO wanted the activity log to show only the vault's lifecycle. I proposed filtering it by audience, all, depositors, curators, mine, because "valuation" and "settlement" mean nothing to an average depositor, and renamed "Transaction history" to "Activity". Both went in. We disagreed on the table layout: I recommended a two-line row with a colour-coded icon, he preferred a type column. Both versions went to the CEO.
Composition, activity, details: what a depositor used to read in a block explorer.
Show where the money is
Money moves on a delay, so every waiting state is named. Pending requests sit next to the balance, in one block. The deposit dialog went down to two steps, deposit, then settlement underway. And every action ends on a confirmation: before that, withdraw and claim ended on nothing. When I proposed the pending-request block, the CTO's answer was "I really like the system you found".
Every state a request can be in, next to the balance it will change.Confirm, depositing, deposited. The same condition is repeated at each step: the position activates when the curator approves.A full position: deposit, claim the shares once the vault settles, request a redemption, withdraw.
Valuation, on the manager's side
The base spec didn't have it. The first version showed only the final figure, to be recomputed by hand somewhere else. I designed the whole step: the person in charge of valuation types the new total and sees the simulated result live, fees and pending requests included, then submits. The curator approves and settles. It stops a figure nobody could check from reaching the depositors' share price.
The valuation typed, then simulated: every consequence on screen before anything is submitted.
The curator needed every decimal for their own calculation, up to sixteen on many figures at once. The precision rule is what keeps that screen readable: bright significant digits, the rest dimmed, and the asset named next to every figure even when it repeats.
Deploying a vault
Some settings can't change after deployment, so the wizard asks for the minimum first and flags what is fixed for good. Everything optional moves to after deployment. The last step is a review with an edit button per section. Copy mattered here too: "custodial wallet" read like an exchange account, so it became "vault custody wallet".
Cut on purpose. I had designed the full creation flow. With the CTO, we cut it live to a v0 with only what the first vaults needed, and it went to the developer the same day. A drag-and-drop permission builder was postponed: too heavy while each role had one or two flows.
The fee step, and the review that repeats every setting before deployment, one edit button per section.Vault information, roles and permissions, fees, review, then the deploy transaction.The manager's home: the vaults they run, and the deployments still in progress.
Trust in layers
Once anyone could deploy, anyone could create a vault that looked like the others. The public list only shows managers Lagoon has onboarded. Any other vault can still be shared by link, and it opens under an alert: unverified, closed, or suspicious settings. The vault page then holds the full detail.
Managers gave feedback directly in their own channels. One change it drove: whitelisted vaults got a "Request access" path, for managers who wanted to let in wallets they hadn't listed at first.
A vault reached by link, and the three alerts it can carry.
How decisions were made
The CTO and a founder filtered requests on direction. I filtered on consequences: what a request would break, shown as several design options they could choose from. Decisions lived in Figma comments with a 24-hour window, in recorded weekly meetings and in the backlog. Requests were weighed by how often they came back.
The brand
I also did the identity and the landing pages, and built the first landing page myself. The current visual design of the app was redone after I left; the screens in this case are my design files.
The symbol in three parts, one per promise: yield, flexibility, security.Marketing visuals for launches, integrations and partnerships.
How it was validated, and what wasn't
Before: clickable prototypes at each stage, and a structured feedback session on the wireframes before any visual design. During: testing sessions with the developers, and builds checked against the mockups. After: a handful of managers followed directly, with fast qualitative feedback. Nothing was measured. What I'd track now: the share of new depositors who open a vault's detail before a first deposit, which says whether they do their due diligence; and fewer questions about valuation and settlement in the managers' channels.
What I'd do differently
Design for the build you have. I put too much into visual polish and underestimated how faithfully it would be built. The cost was a live product that drifted from the design, and time spent fixing code myself. Now the effort goes into the system, the states and the specs that survive implementation, and into build reviews with the developers.
Being your own user is fast and blind. It gave us speed, and no outside view once Lagoon moved toward institutional depositors. I'd put the product in front of a handful of them early.
UGAP
3 min read
UGAP is France's central public purchasing body: schools, hospitals and towns order from its catalogue without running a tender of their own. It works like B2B e-commerce, with hundreds of thousands of references and buyers who buy for work, under approval rules. Research before the redesign showed they couldn't find, couldn't choose, and couldn't finish an order inside their own process. I redesigned the journeys that fix those three things.
RoleProduct designer
ScopeBrandProduct
ScaleAbout 4M visits a year
The V4 redesign rebuilt every journey of the site, desktop and mobile, and shipped in 2023. It is the site UGAP runs today. Four designers shared it; I designed the quote journey end to end and owned the visual treatment.
The storefront. Search sits at the top of every page, because that is where buyers start.
Buyers who answer to someone else
Before the redesign, UGAP ran focus groups and on-site tests with real buyers. I sat behind the one-way mirror. Three things came back.
Search didn't find. Buyers went to Google, or called their sales rep.
Nothing helped them choose. Weak filters, thin product pages, no way to compare.
The order didn't fit the organisation. The person who orders is often not the one who signs, so the basket went to the accountant as a screenshot.
The benchmark run before the redesign: twelve sites in columns, five purchase stages in rows, red weak and green strong. UGAP is the outlined column.
Search as a guide
One field for a product, a reference or a page. Each suggestion carries its category and a count, results come grouped, and an empty field already shows the buyer's history, where a repeat order begins.
The overlay while typing, and the results page it leads to.The listing, in grid and list view: the category tree, filters that fit the category, and a buying guide among the products.
A product page buyers can match
A buyer asked in the tests for "a column with the UGAP, the distributor and the manufacturer reference". The page puts all three side by side, and the price reads excluding VAT first: the figure a public budget runs on.
The product page, with its customer reviews beside it.
Compare, then hand it to whoever signs
Up to five products, differences highlighted on demand, and print, download and share, because the person who approves is rarely on the site.
The comparator, with the differences highlighted.The quote, with its status and total at a glance.The client area and its activity feed: one card per request, with its state.
When the catalogue can't answer, start from the need
For complex purchases, buyers know the problem, not the product. So the journey opens on a needs-expression form, lets several suppliers answer in one place, and ends on one quote shared by the buyer, the supplier and UGAP.
Needs expression, desktop and mobile: three steps, starting with the need in the buyer's own words.The whole path: pick the suppliers, express the need, exchange with the supplier, receive the quote, turn it into an order.
Mobile
The same components carry the whole site on mobile, for checking an order, a quote or a product on the move.
Home, listing, menu, magazine and sign-up, on mobile.
A visual language without product photos
A public buyer can't promote one product or one brand. I proposed generic 3D objects, one per product universe, in the universe's colour; they still sit on the homepage. I also wrote the pictogram rules that let several designers extend the set to more than 130 icons in one style.
Every product universe, each with its 3D object and its colour.Buying guides: the 3D object taken apart, one part per choice the buyer has to make.The pictogram set, drawn by several hands from one set of rules.The design system behind every page: buttons, tags, cards, pictograms.
CPB Paris 2023
Beyond the catalogue: the event UGAP ran to bring central public purchasing bodies together in Paris, with a brand of its own. I did the full web design and front-end integration of the event site, in a register that has nothing to do with the catalogue.
CPB Paris 2023: a different register, web design and integration end to end.
UGAP, in depth
10 min read
UGAP is France's central public purchasing body: schools, hospitals and towns order from its catalogue without running a tender of their own. It works like B2B e-commerce, with hundreds of thousands of references and buyers who buy for work, under approval rules. Research before the redesign showed they couldn't find, couldn't choose, and couldn't finish an order inside their own process. I redesigned the journeys that fix those three things.
RoleProduct designer
ScopeBrandProduct
ScaleAbout 4M visits a year
The V4 redesign rebuilt every journey of the site, desktop and mobile, and shipped in 2023. It is the site UGAP runs today. Four designers shared it, each with an area of reference: the UI library, accessibility, integration, and mine, visual treatment. I was often the one asked to give a journey its first shape, and I designed the quote journey end to end.
The storefront. Search sits at the top of every page, because that is where buyers start.
Role & team
Four designers, one area each. One colleague owned the UI library, one accessibility, one integration once the agency's base was taken in-house. Mine was visual treatment: anything that had to look right, the iconography, the imagery. Across all of it I was often asked to give a journey its first shape; refinement was mine or the UI-library colleague's.
Specs came down, prototypes went back up. Needs reached us through the head of the design department and the product owners. We prototyped the journeys against their specs, tested them with UGAP's IT purchasing team, who deal with suppliers every day, then handed them for build: first to an agency, then to in-house developers, with whom I worked on design adjustments and the UI library. Over the four years the team moved from long V-cycles to a more agile rhythm, because both sides were losing time.
Two work-study designers sat next to me. I wasn't their official tutor, but they brought me most of what they made. The pictogram rules further down came out of that: written so they could draw without me and still land in the same style.
Tools. The company ran on Adobe XD; Figma came late. Prototypes that would be one file elsewhere had to be split into pieces.
Buyers who answer to someone else
Before the redesign, UGAP commissioned two agencies. One ran five focus groups in Paris, Bordeaux and Strasbourg (local authorities, hospitals, the State purchasing directorate, and people who browse the site but still order by phone) and ten one-hour tests at buyers' own desks, half with buyers who chose the site, half with buyers who had to use it. The other audited the analytics and benchmarked the site against eleven others. I sat behind the one-way mirror for the sessions, and we worked closely with both teams afterwards.
The numbers framed the rooms. About 4 million visits a year, around 2 million unique visitors. Identified buyers were loyal, 60% of them back every month, but their visits were short and utilitarian: home, login, search. Most searches were by keyword, a large share returned nothing, and that share didn't fall despite the fixes. The FAQ reached 1.2% of visitors; help requests were mostly about quotes.
Search didn't find. No tolerance for typos, different results for "battery" and "batteries", over a thousand results for the plural. Buyers went to Google, or called their sales rep.
Nothing helped them choose. Filters were missing or beside the point, product pages lacked the basics, and there was no way to compare.
The order didn't fit the organisation. The person who orders is often not the one who signs. So they took a screenshot of the basket and emailed it to the accountant.
The benchmark run before the redesign: twelve sites in columns, five purchase stages in rows, red weak and green strong. UGAP is the outlined column.
Constraints
Neutrality. A public buyer can't push one product or one brand on most of its pages. The buyers said it themselves: products and suppliers on equal footing.
Catalogue size. Hundreds of thousands of references made some patterns hard to build at acceptable performance.
A proxy for users. The research had real buyers; our own prototype tests had UGAP's IT purchasing team standing in for them. Close to buyers, but not buyers.
Every change has a cost. Many users were not at ease with computers and had their habits on the old site. A better screen they had to relearn still cost them something.
The insight
Buyers don't browse. They come to get a job done, often a repeat order, and they answer to someone else. So the site's job wasn't to look like a shop. It was to find the right reference fast, give enough to decide without leaving, and produce something the approver can sign.
That turned into three choices. Search as a guide, rather than only tuning keyword matching. Start from the need for complex purchases, rather than assume the buyer can pick a supplier from a catalogue. And make every decision shareable, the comparator and the quote above all, rather than build an approval workflow into the site that would have differed from one public body to the next. Small disagreements inside the team, a button's place or a label, we settled with A/B tests on emails and the purchase journey rather than by opinion.
Search as a guide
Most visits came to get a job done, often a repeat order. So search had to understand three kinds of query in one field: a product, a reference, or a page.
Suggest the aisle, not only the word. As the buyer types, each suggestion carries its category and a count, so "laptop in IT" and "laptop in furniture" stop looking the same. Results come grouped: products, suppliers and brands, then buying guides.
Start before the first letter. An empty field shows the buyer's own history and the popular searches, which is where a repeat order begins.
The overlay while typing, and the results page it leads to.
Filters that fit the category
A thermometer filtered by "Teflon" or "PVC" helped nobody. Filters follow the category instead, show as removable chips, and the panel counts the matching products live, so a buyer sees the list shrink before applying anything.
The listing, in grid and list view: the category tree, filters that fit the category, and a buying guide among the products.
A product page buyers can match
Buyers reconcile every line against their own systems. One asked, in the tests, for "a column with the UGAP, the distributor and the manufacturer reference". The product page puts all three side by side, with the supplier, the date the public contract ends and who ships. The price reads excluding VAT first, with the eco-contribution under it, because that is the figure a public budget runs on.
The product page, with its customer reviews beside it.Two of its panels: options with their price, and the colour selector.
Compare, then hand it to whoever signs
Buyers asked to compare "like on a consumer site", for IT and medical equipment above all. The comparator takes up to five products and can highlight only the differences. It also prints, downloads and shares, because the person who approves the purchase is rarely on the site.
The comparator, with the differences highlighted.
When the catalogue can't answer, start from the need
For complex purchases, software for instance, a catalogue assumes the buyer can pick the right supplier. Many can't: they know the problem, not the product. So the journey opens on a needs-expression form built for the buyer's category, then lets several suppliers answer in one place, with the messaging inside the request instead of in someone's inbox.
Needs expression, desktop and mobile: three steps, starting with the need in the buyer's own words.The whole path: pick the suppliers, express the need, exchange with the supplier, receive the quote, turn it into an order.
One quote, three parties
The quote is shared by the buyer, the supplier and UGAP. It lives on one page with its status, its dates and its total, and it prints and downloads for the internal sign-off. Quotes were the best-known feature of the old site and the first reason buyers asked for help, so this is where the work went deepest.
The quote, with its status and total at a glance.
The client area follows every request as a card with its current state: awaiting details, in validation, delivered. In the tests, buyers kept discovering features they valued and had never found, like repeating an order. The client area puts those on the first screen.
The client area and its activity feed: one card per request, with its state.
Mobile
Buyers order on a work computer; the research was clear about that, and a dedicated ordering app was one of the ideas they turned down. Mobile still had to carry the whole site, for checking an order, a quote or a product on the move, with the same components as desktop.
Home, listing, menu, magazine and sign-up, on mobile.
A visual language without product photos
A public buyer can't promote one product or one brand on most of its pages, and users themselves insisted that suppliers stay on equal footing. Category colours existed, imagery didn't. I proposed generic 3D objects, one per product universe, in the universe's colour: a bulb, a spray, a chair, a microscope. They still sit on the homepage today. I also drew the first pictograms and wrote the rules for the rest (colour, stroke weights, spacing, reusing parts of existing icons), so two work-study designers and others could extend the set to more than 130 in one style.
Every product universe, each with its 3D object and its colour.Buying guides: the 3D object taken apart, one part per choice the buyer has to make.The pictogram set, drawn by several hands from one set of rules.
Accessibility
A colleague led accessibility for the team. Together we designed an accessibility mode for a public audience: a panel, always one click away, to raise contrast or stop animations.
The mega-menu and the accessibility panel: raise contrast, stop animations.The design system behind every page: buttons, tags, cards, pictograms.
CPB Paris 2023
Beyond the catalogue: the event UGAP ran to bring central public purchasing bodies together in Paris, with a brand of its own. I did the full web design and front-end integration of the event site, in a register that has nothing to do with the catalogue.
CPB Paris 2023: a different register, web design and integration end to end.
How it was validated, and what wasn't
Before: the research and the analytics baseline framed the work. During: prototypes went through the IT purchasing team before the product owners signed them off, and small A/B tests settled the details. After: the rollout was progressive and I left as it went on, so nobody I know of read the baseline again. That is the gap I'd close first.
What I'd do differently
A baseline only helps if someone reads it again. We had good numbers before the redesign and never closed the loop. Today each journey gets one number before design and a date to check it: searches without results and exits after search, filter use, comparator to basket, quote request to signed quote, and the time from need to quote. The failure signal I'd watch first is a buyer calling their sales rep instead of finishing online.
Seeing users beats reading about them. An hour behind the mirror did more for me than the report. Needs reached us through layers of hierarchy, and I waited for them too often. When research doesn't land on my desk now, I go and get it.
DeFi Collective
2 min read
Decentralised finance runs on software that no single company owns. The DeFi Collective defends the protocols that keep it that way, the ones nobody can alter or switch off, including the people who wrote them. It makes that case in public, to developers and to regulators.
RoleDesign + front-end
ScopeBrandWebsite
Treasury$3.6M at the end of 2024
The founders had been arguing for decentralisation since the beginning, and that is where the credibility came from. The Collective was the vehicle: lobby for the protocols they had always defended, and prove the case at the same time by running its own treasury in public, with no compromise on decentralisation and mostly through those same protocols.
They needed an identity that policy people would take seriously without losing the web3 crowd that had backed them from the start. I built it from zero, and the site it runs on.
The lockup. The mark is an ant, and the same drawing is a network of connected nodes.
Why the ant
A colony is a structure: a lot of actors, each doing a local job, no commander. That is the Collective too, an organisation with no owners and no shareholders. Today they call themselves the Ants.
No queen
People hear colony and think monarchy, one sovereign and a workforce that obeys, which contradicts everything the Collective argues. So the mark has no queen. What is drawn is a worker and the network it belongs to.
Saturated violet and pink, to be recognisable in a category that defaults to dark dashboards and blue accents. The site runs in both themes, and I built the front-end.
The mark
The two readings came out of simplification. The joints became nodes, the legs became links. I kept removing detail until the ant still held at the size of an avatar, and the network at the size of a page.
The editorial block, for the research they publish: data reports, deep dives, field notes. I designed it, drew the covers, and built the front-end.The same system on their public channels: profile, banner, avatar.The mark in embroidery, where it loses its finest detail and still reads.A commission for one of the founders: he defends decentralisation without compromise, and wanted to be drawn that way.
