From discovery to revenue

Context

Product DNA is a B2B SaaS traceability platform. To enter construction, it needed an offer that traces key materials and their footprint across suppliers. The hard part was the scope: complement the site management tools clients already use, or replace them? Calculate CO2, or sync it from other tools?

Users & my role

Buyers, CSR teams and decision-makers, working from the office. I co-defined the vision and roadmap with the CTO, led discovery and user testing, designed the product end to end, and took 6 developers from user stories to functional QA.

What I found

• Traceability starts with orders, not with the construction site.
• Clients trace key materials, not every component of the chain.
• Tier-1 suppliers reach their own suppliers far more easily than the client can.
• Site management tools are complex, and clients did not expect traceability from them.

Product decisions

• Orders as the entry point, where traceability starts.
• Key materials only, instead of mapping the entire supply chain.
• Tier-1 suppliers cascade the request: the most data for the least effort.
• Complement, don't replace existing site management tools.
• A CO2 calculator: cheap to build, directly useful to CSR teams.

UX decisions

• Desktop-first, built for analysis: compare the footprint of each product, material and supplier.
• Supplier follow-up made visible: every request and response in one place.
• Compliance, due diligence and reporting come straight out of the collected data.
• Prototypes in days with Claude and Claude Design, tested with clients before development.
• An AI-friendly PrimeNG design system that cut design-to-dev friction.

Also delivered: the website relaunch

The old site had an unclear message and an old-fashioned design. I rebuilt it with marketing and sales for executives and buyers, set up Mixpanel before launch, and mentored the intern who developed it. Bounce rate fell from 70% to 54% and p75 session duration doubled.

Context

Prospects struggled with a complex website, and few completed an online application. Behind it, advisors juggled several separate processes: documents scattered across tools, valuations from different external services, complex cases hard to track.

Users & my role

Prospective borrowers and mortgage advisors. As Product Designer at CBTW, I ran needs definition with business, IT and advisors, then designed the client journey and the advisor tool with the bank's internal experts and the CBTW product team.

What I found

• About 80% of applications follow the same steps; a minority need special handling.
• Documents and valuations sat in different places, which slowed follow-up.
• Few prospects completed an application on the old website.

Product decisions

• One product, two sides: otherwise the redesign only moves the bottleneck.
• 80%, not 100%: one standard workflow, exceptions handled separately.
• A simulator before the form, turning visitors into qualified applicants.

Context

The tool lets wealth managers track client portfolio performance and compare investment strategies. After years of features added on request, it suffered from overload and heavy UX debt.

What I found

• Features added over the years had overloaded the interface.
• Users needed clarity, efficiency and performance.
• Comparing portfolios was central to their daily work.
• Tests in 3 banks revealed friction that never came up in workshops.

Product decisions

• Start from needs, not from the old screens, to avoid copying their debt.
• Prioritize with the people who use it, in workshops with senior stakeholders.
• Desktop first, mobile later.

UX decisions

• A clear hierarchy for dense financial data.
• Comparison of portfolios and strategies as a core flow.
• Hi-fi prototypes tested in 3 partner banks; development followed through integration.

Context

TPG coordinates every event affecting the Geneva network through one internal tool: planning, coordination, real-time monitoring, legal and logistics. Built over 9 years without a product approach, it had a long onboarding, a fragmented experience, unused features and dependencies on systems such as SAP.

What I found

• The tool was full of friction and duplicated features nobody used.
• Departments shared needs, scattered across separate tools.
• Information was siloed, which made coordination slow.

Product decisions

• Audit before redesigning, for an objective basis.
• Map the whole system with three service blueprints.
• Cut, then unify: unused features dropped, shared needs merged.

UX decisions

• One platform adapted to each department's rhythm, unified in language and navigation.
• Clear roles for each department in every event.
• Current and upcoming events at a glance, with a fast path for emergencies.

Context

Tarotale is an AI-powered tarot app, live since February 2025. I built it alone, as a real business: a subscription product people pay for and keep using, in a crowded category.

What I found

• The paywall was converting poorly, at 1.1%.
• Users had no reason to come back between readings, which drove daily churn.
• Users questioned the readings' credibility, a risk for subscriptions.

Product decisions

• Monetization by experiment: offer, framing, price and timing tested in RevenueCat.
• Retention through habit: a free daily feature halved daily churn.
• AI quality as a product problem: LLM output and presentation iterated until trust complaints stopped.
• Getting to market: an App Store rejection appealed and approved; Android tester phase; Google, Meta and Apple Search Ads, ASO and UGC.

UX decisions

• Emotional onboarding: card animations, video and sound in the first minutes.
• A modern take on a traditional genre, respectful of its symbolism.
• One visual universe, generated with Midjourney and reworked by hand.