I design intuitive, useful products for SaaS, B2B, B2C and AI-driven teams, working closely with stakeholders so the result serves both the business and the people using it.
6 years in product design
AI, B2B/B2C, SaaS products
Remote, CET
Selected work
Under NDA · 2026
AI copilot for insurance underwriters
I designed the UI and interactions for an AI agent that helps underwriters regain control of their submission queue. Working from the team's intent map and scenarios, I designed how conversation and workspace move together: the agent briefs after an absence, proposes and waits for confirmation before anything irreversible like sending decline emails, and shows its sources and reasoning inline when asked. Visuals can't be shared; happy to walk through the work in a call.
An AI agent for biology that turns multimodal patient data into answers researchers can trust
Client
Owkin
My role
Lead UI/UX Designer
Year
2025
Scope
Discovery, MVP, design system, launch
Where it started
Owkin is a biotech company that uses AI and federated learning to personalise treatments, speed up clinical trials and build diagnostic tools. K is their AI agent for biology: it brings multimodal patient data, literature and gene knowledge together so biopharma teams can make better research decisions.
104academic partners
156key opinion leaders
$304Mfunding raised by Owkin
My role
I led the design of K end to end, from the first kickoff to launch, including the whole chat experience. I shaped the MVP scope together with product and engineering, built the design system from scratch, ran stakeholder reviews and turned feedback from research and internal demos into continuous improvements. Closer to launch, I made sure the product and the marketing materials felt like one thing.
The design problems I solved
Ask anything, without learning a tool first
Most biologists don't code, and complex query builders slow everyone down.
I reduced the home screen to one open input, with no forms and no filters, so researchers can start with a question instead of building a query.
Depth on demand
For a scientist, how an answer was reached matters as much as the answer itself, but AI responses on scientific data get long and dense very quickly.
Each response opens with a structured summary and key findings. Right above it sits an expandable thought process that shows how K got there: which data it used, which steps it took and which methods it applied. Transparency became my main design principle, so researchers can check the reasoning and trust what they see.
Patient data, literature and prior knowledge sit in collapsible layers underneath, and charts open in their own panel. The first read stays light, and all the detail is one click away.
Making the data itself explorable
Researchers couldn't ask good questions without knowing what data was available.
I designed a data catalogue that organizes complex biomedical datasets into one clear view. Summary metrics show the scale of each dataset, and tables break it down by modality, key variables and cancer indication. Each modality links straight to relevant prompts, so browsing turns into asking.
Approachable, not intimidating
Scientific software is usually dense and overwhelming, and the competitors looked exactly like that.
I wanted K to feel calm and welcoming instead. Working with Owkin's marketing team, I moved the interface to warm beige surfaces and Owkin's own typeface, with a clear, quiet hierarchy, so it felt friendly while staying on brand.
A design system the whole team can design with
The team wanted to explore ideas and test hypotheses quickly, without every change waiting in a design queue.
I built K's design system from scratch on top of shadcn/ui, with color tokens, a surface hierarchy and accessibility principles. Because it maps directly to code, the system can be loaded straight into Claude Code. That means anyone on the team can work with Claude to design new screens on the real components, try ideas and test hypotheses, while everything stays consistent with the product.
One experience on every screen
Researchers move between the lab, meetings and their desk.
I designed K to adapt across desktop, tablet and mobile, with layouts and components that keep the experience consistent on every screen.
How I worked
Ran kickoffs and discovery sessions with Owkin's product owners, biologists and developers to understand their goals and pain points
Mapped the biologist's journey from first idea to validated hypothesis and used it to prioritise MVP features
Benchmarked competitors in a feature comparison table to decide what to include and what to do better
Worked in weekly sprints, from wireframes to high-fidelity screens
Built the design system on shadcn/ui and set it up to work with Claude Code
Designed a marketing video, animations and an interactive demo prototype for an industry conference
Delivered, tested, and kept supporting the team with UX reviews of implemented features
Outcome
Biologists now have one place to work with scientific data: they ask in plain language, see the evidence behind every answer and explore results through clear visualizations. Workflows that used to need a coder became something a researcher can do on their own, so their time goes into hypotheses, not into fighting tools.
An AI-powered observability platform that helps telecom and energy operators keep huge networks running
Client
Byanat
My role
Lead UI/UX Designer
Year
2024
Scope
SaaS platform, AI insights, design system
Where it started
Telecom and energy companies manage enormous networks of assets: cell towers, IoT SIM cards, data centers and the equipment inside them. Devices fail every day, and each failure can mean an outage for thousands of people.
Byanat builds connected intelligence for this infrastructure. The platform brings data from all of these assets into one place, analyzes it and makes it visible, so teams can spot problems and act on them. It started with telecom and is growing into utilities and smart cities, and it runs as a white-label product for several operators.
My role
I was the lead designer on the platform. I turned business requirements into a complete SaaS product, built a token-based design system in Figma with light and dark themes, led the high-fidelity prototypes and worked closely with stakeholders and the development team.
The design problems I solved
One product for engineers and the CEO
An engineer needs cell IDs and packet drop rates. A CEO needs to know in five seconds whether anything is wrong, without calling anyone.
I designed different depths of information on one shared foundation. Executives get a map coloured by regional performance, a short list of critical outages and recommended actions. Engineers can drill from the same map down to a single cell and its parameters.
Thousands of assets on one map, without overload
Showing every site, sector and SIM at once would make the map unreadable.
Users decide how much they see. Layers, legend, widgets and outages switch on independently, widgets can be hidden, a heatmap shows density, and colour coding keeps status readable at a glance.
From alert to action
When a tower goes down, every minute counts, and an alert alone doesn't tell you what to do.
I designed a flow that leads from the problem to a decision: which sites are affected, how many users lost service, the likely cause, the risk if nothing changes, and the next step, such as adjusting parameters or sending a maintenance team.
AI inside the work, not in a separate chat
Operators work on the map and in dashboards. A chatbot in another tab would rarely get used.
The AI Insights panel sits right next to what people are already looking at. Insights appear inside widgets, and the assistant ranks issues by priority and offers direct actions: show the sites on the map, generate a report or recommend next steps.
Deep asset hierarchies people don't get lost in
A site holds towers, each tower runs 2G to 5G, and each technology has its own cells. Customers own groups of SIM cards.
I built one pattern for every asset type: a tree or list on the left and a detail page with clear sections on the right. Once you learn it for towers, it works the same for SIMs and customers.
Data work without code
Preparing network data usually needs a data engineer.
I designed Workflows, a visual builder where analysts connect sources and ready-made components for cleansing, conversion, transformation and anomaly detection, and configure each step in a side panel.
One platform, many clients and industries
The same product serves telecom operators, energy companies, data centers and emergency services, each under its own brand.
I built the design system on tokens, with light and dark themes, so the platform can be rebranded for each client without redrawing the product.
How I worked
Translated business requirements into product structure, flows and screens
Designed separate views for engineers, managers and executives on one foundation
Built a token-based design system in Figma with light and dark themes
Led the creation and delivery of high-fidelity prototypes
Worked closely with stakeholders and the development team throughout
Outcome
Byanat got a complete platform that turns a complex network into something every role can read: engineers see details, managers see trends and executives see what needs attention, all in one product that adapts to each client's brand.
Yseop: moving design into the product with AI, without losing design judgment
How our team moved design into production code with AI, and how I adapted the design process to it
Company
Yseop, AI for regulatory medical writing
My role
Product designer
Year
2026
Scope
Editor redesign, configuration panel, adapting the design process
A product for medical writers, and a process that drifted
Yseop helps medical writers produce regulatory documents, such as clinical study reports, with AI. I redesigned how writers read, edit and configure those documents, across the web app and the Word add-in.
Medical writing is precise work. Every sentence in a regulatory document has to match the data behind it, and writers spend much of their day reading, checking and correcting. The tool they work in has to stay out of the way and earn their trust.
Halfway through, the way design got made changed too. This case tells both stories, because every screen below was made with the new process.
How design used to move
Prototypes lived in a separate AI tool. They were fast, good for showing a direction, and some were tested with users.
They were not connected to the design system. Stakeholders saw something that looked finished but could not ship.
Developers rebuilt each idea from scratch. Over a few months, the app drifted away from behaviour users had already tested.
None of these steps was wrong on its own. The problem was the gaps between them. Each step translated the idea into a new format, and every translation lost a little. Nobody decided to change what users had tested; it simply drifted.
Before
Mockup in a separate tool
Handoff to developers
Rebuilt from scratch
Product drifts from what users tested
After
Inside the real product
Feedback or an idea
Built with design system parts
Team reviews a live link
Developers refine and ship
repeat
What “designing” means here
The team moved to designing directly in the real product, with Claude Code and a design system built on shadcn. My part was to adapt the design process to it.
The goal was not to design faster for its own sake. It was to close the gaps: one place where an idea is shaped, reviewed and handed over, so that what users test is what ships.
Every change now goes through the same short loop:
Start from real input: review notes, a meeting transcript, or a marked-up screenshot of the current product.
Build it in the product: Claude changes the real app on a separate branch, where nothing can break the main product.
Review and correct: I check the live version, correct it, and repeat until it is right.
Share a link, not a mockup: stakeholders open the working product with real data.
Comparing options inside the product
To compare directions, I build two or three options into the same live page with a small switch. A product manager flips between them and clicks through each one with real data.
This changes the conversation. Instead of debating a static picture, people try each version on a real document, with real sections and real tables, and the discussion moves to what works for the writer.
What stays with the designer
AI builds quickly, but it does not know medical writers. Deciding what to build, which option is right, and when something is finished is still design work. Most of my time moved from drawing to reviewing: reading what AI produced, correcting it, and saying no to what it invented.
Three levels of fidelity, one rule
Building in the product is not always the right move. I pick the format by the question I need answered.
A working product is convincing, and that is exactly the risk. A finished-looking screen invites comments on polish instead of on the idea, and to a client it can look like a promise.
Level 1 · Greyscale prototype
Is this the right idea? I use it when:
the idea is new and may be wrong;
I want honest criticism, not comments on polish;
a client needs to see an idea, not a promise.
Level 2 · Concept prototype
Is this the right direction? I use it when:
stakeholders need to see a direction quickly;
a flow should be tested with users before it is built;
several directions compete and should stay cheap.
Level 3 · Working product
Is this the right solution? I use it when:
the direction is validated and the question is how;
interaction and real data shape the design;
review feedback must become a fix the same day.
My rule: the fidelity follows the question, not the tool.
A design guide written for AI
When anyone can ask AI to change the interface, consistency becomes the risk. So I wrote the design rules for the whole product, both the web app and the Word add-in, as a guide for AI. Whenever someone on the team asks Claude to change the interface, it reads the guide first and only then writes code. Every screen follows the same rules, whoever builds it: me, the developers, or anyone else working in the product repository.
Why it was needed
AI does not remember last week's correction. Each request starts from zero, so without written rules the same mistakes come back, and every screen drifts a little in its own direction. The guide is how a decision made once stays made.
Built from corrections, not from theory
The rules come from my own corrections over three months of working with AI. I counted which ones came back most often: alignment and “use only design system components” alone came up more than 17 times. With AI's help I gathered the corrections from the history, then picked the rules, resolved contradictions, left out anything I had changed my mind about, and approved every wording.
What the guide covers
Principles. Start from the writer's task, reuse validated UX, guide the user, content first, one product on two platforms.
Design system. Only its components, unchanged; one element looks the same everywhere.
Interface copy. No stating the obvious, the writer's language, one name for one thing.
Colour. Stable status colours, document structure colours, contrast, active states.
Typography. Interface and document fonts, one simple type scale.
Layout and spacing. Alignment, spacing that groups, no empty gaps, nothing shifts under the user.
Behaviour patterns. Undo instead of confirmation, errors that lead to the fix, clear navigation back.
The wording matters as much as the rule. “Keep it consistent” gives AI nothing to act on. “Use only design system components, unchanged” does. I wrote every rule so that it can be followed and checked.
The product: making the app feel like the document
Usability tests with medical writers showed that the app did not feel like the documents they were writing.
The document did not look like a document. Structure and text lived in separate places, and much of the screen was interface instead of content.
Logic was written for machines, not for the writers who had to read and edit it.
Configuration was scattered across several panels that used different words for the same ideas.
“It's hard for me to understand where I am in the whole process.”Medical writer, usability test
I set five principles before any screen:
The document opens as a document. Nothing on the page that will not be in the final file.
Who wrote the words decides what a click does. Human text: a click places the cursor. Generated text: a click selects the block.
Design from the writer's job, not the feature. If a flow needs an explanation, redesign the flow.
Reuse what is validated before inventing. Start from behaviour that already worked with users.
The design system only. Every screen is built from its components, with no invented styles.
Part 1 · One editor instead of two tabs
A single Word-like page that writers can read and edit in place. Sections show their status in the navigation, and the guideline for each section sits right above it.
The second principle lives here. In text a writer typed, a click places the cursor, just like in Word. In generated text, a click selects the whole section and opens a bar of actions on it, such as group, condition, repeat and duplicate. The writer always knows which part of the page they own and which part the system writes.
Part 2 · One configuration panel
I started with words, not screens: the team agreed on one shared vocabulary before any layout. The result is one panel for every part of the document, with three tabs that follow the questions a writer asks.
Content: what does this say? Sources, parameters, transformations and guidelines.
Appearance: how does it look? Section style, heading and table styles, references to the source.
Quality: is it right? Edits made in Word, a comparison with the last generated content, and data coherence checks.
Content · what does this sayAppearance · how does it lookQuality · is it right
Part 3 · Sources the writer can check
Every uploaded table sits in one list with its type, what it can be used for, and what still needs an answer. When something is unclear, the writer reviews it one question at a time and sees the sentence each answer will produce.
Showing the sentence matters. A question about a data table is abstract; the sentence it produces in the report is not. The writer answers in terms of the document they are responsible for.
What changed in the team
Feedback became concrete. People react to what they click, not to what they imagine, and feedback from a review can become a working solution the same day.
The handoff disappeared. Developers take the working version, harden the code and ship it. My working prototype became their reference for the new editor.
Everyone can prototype now, so the designer's job moves. When a non-designer colleague built a strong prototype of the panel, my job was to read the intent, keep what was right and make it consistent with the product.
What shipped, and what I learned
The new editor was built directly from my working prototype.
The configuration panel shipped, built from my design.
The design guide for AI runs in every AI session in the product repository.
Learned by doing
The bottleneck did not disappear. It moved from making to judging. When making was slow, the effort itself filtered ideas. Now that filter has to be a conscious choice: telling a good solution from a well-presented one, and stopping a weak idea before it gathers a prototype and supporters. AI produces an option in minutes; it cannot know what a medical writer needs.
Faster design is not faster product work. The cheaper a solution is to make, the more it matters to see early which ones should not be made at all, and that still takes the same time.
Saying no is the core skill. Much of my work was rejecting what AI invented or got wrong.
Clear rules make AI fast; vague requests make it invent.
Research to working solution takes days. A finding on Monday can be something the team clicks on Tuesday.
Limits I keep in mind
A working version looks like a decision. The more finished something looks, the harder it is to question the idea behind it. For new ideas, I still start in greyscale.
AI repeats mistakes unless the rule is written down. A correction made in one session is gone in the next; only the guide carries it forward.
Speed can hide a missing question. When a solution appears in minutes, it is easy to skip asking whether it solves the right problem. That is when I go back to greyscale.
When everyone can build, consistency needs an owner. More people changing the interface means more small differences. Someone has to keep the whole product coherent, and that is design's job.
