Good design in complex products isn't about 〰〰 making things pretty. It's about making hard things feel inevitable.

I currently lead UX at PointFive, where I've helped build the product from the ground up alongside the founder, turning complex FinOps data into clear, actionable interfaces and shaping how people trust the AI agents that act on their cloud costs.

Before that I spent several years deep in cybersecurity and enterprise AI: at Laminar (data security), and earlier alongside teams like Sygnia (threat detection) and BeyondMinds (enterprise AI). I gravitate toward complex, technical products where good design genuinely changes how people work.

Across all of it, one thread repeats. I build the systems underneath the screens, establishing design systems from scratch: the components, tokens and standards that keep a whole product coherent as it scales.

I trained at Shenkar College in Visual Communication, and I still keep an active artistic practice on the side: drawing, sculpture, mixed media. It shapes how I approach product work, trusting intuition early and refining ruthlessly later.

EXPERIENCE

  • PointFiveSenior Product Designer2023 – Present
  • LaminarSenior Product Designer2022 – 2023
  • BeyondMindsProduct Designer · Enterprise AI2020 – 2022
  • SygniaProduct Designer · Cyber2020 – 2022
  • FreelanceUX/UI & Graphic Design2017 – 2021

EDUCATION

  • Shenkar CollegeBA Visual Communication2015 – 2019

CONTACT

BeyondMinds · AutoML / MLOps · 2021

Helping people trust a model retraining

BeyondMinds built automatic machine learning (AutoML) that lets teams create models for fields like production and finance. I designed how non-technical users decide when and how to retrain a live model, with confidence.

The model was already accurate. My job was to make people trust it enough to act.

IMG-01
Hero image · IMG-01Hero image · IMG-01
The retrain screen — comparing a new model's results against the previous one before deploying (PCB Defect Detection).
My role
Product Designer

Wireframing, visual design, user journeys, prototyping, dev handoff and support through development.

Tools

Figma, Miro, Notion, Zeplin, pen and paper.

Team

1 Product Design Lead
1 UX Designer
1 Project Manager
2 Full-stack Developers

Context
01

The challenges & user needs

Retraining is one of the most technical moments in the life of an ML model — but the people who needed to do it weren't all data scientists. There was no existing screen to improve here; I designed this experience from the ground up, starting from one question: what would make a non-technical user actually trust this process?

The real challenge was trust. Asking a non-technical user to retrain and deploy a model is asking them to take a risk they don't fully understand — so the design had to make the process approachable, transparent, and predictable, or people simply wouldn't use it.

  • User-friendly interface — make a highly technical process approachable for non-technical users, reducing complexity and helping them retrain with confidence.
  • Access to relevant data — help users easily identify and select high-quality data for retraining, building confidence in the process and the resulting model.
  • Feedback and transparency — give clear visibility into the retraining process: progress, expected outcomes, and the impact on model performance.
  • Managing expectations — set realistic expectations around the time, effort, and limits of retraining, reducing uncertainty and keeping users in control.
Research
02

Competitive analysis

I ran a competitive analysis of existing ML model-retraining platforms, and found a consistent pattern: most suffered from generic design, no user-friendliness, no clear hierarchy, and an overload of data. That gap mattered — industry research shows the vast majority of models silently lose accuracy over time. If the people who need to retrain can't understand the tool, the model decays.

91%
Of ML models degrade over time (MIT/Harvard, 2022)
35%
Error-rate jump for models left unretrained 6+ months
4
Core user needs the design was built around

What competitors got wrong

  • Generic design that didn't fit the task or the user
  • No clear hierarchy — everything competed for attention at once
  • An overload of data, with no guidance on what mattered

Trade-offs

  • Kept technical metrics (Precision, Recall, AUC, Dice Loss) front and center — pairing each with a plain comparison makes them readable, not intimidating
  • Showed the new model side-by-side with the previous one — turns "is this better?" from a judgment call into something you can see
  • Built a guided step-by-step flow rather than a single dense control panel — more screens, but each step asks for just one decision
IMG-COMP-1
DataRobot · IMG-COMP-1DataRobot · IMG-COMP-1
DataRobot — powerful, but dense and built for data scientists, not everyday users.
IMG-COMP-2
RapidMiner · IMG-COMP-2RapidMiner · IMG-COMP-2
RapidMiner Studio — a complex node-based canvas with a steep learning curve.
IMG-COMP-3
H2O.ai · IMG-COMP-3H2O.ai · IMG-COMP-3
H2O.ai — data-heavy dashboards with little visual hierarchy.
Design exploration
03

Wireframes

I explored wireframe directions for the core screens — the inference list, the retrain comparison, and the monitoring view — working in low fidelity first so the conversation stayed on flow and hierarchy, not visual polish. This is where I worked out what had to be visible at each step and what could wait: which metrics belong on the retrain screen, how to show a model mid-training, and how much monitoring detail to surface at once.

3
Core screens wireframed: inference, retrain, monitoring
Low-fi
Started in grayscale to focus on flow before visual design
0→1
Built from scratch — no existing screen to improve
IMG-02
IMG-02IMG-02
Wireframes for the inference list — where a model's status and metrics first surface.
IMG-03
IMG-03IMG-03
Wireframes for the retrain comparison screen — new model against the previous one.
IMG-04
IMG-04IMG-04
Wireframes for the monitoring view — class predictions, confidence, input quality and feedback.
Research
04

User flow

I mapped the full retraining journey — entering the system, selecting a model, viewing its metrics, spotting a drop in performance, investigating the cause, deciding whether to retrain, and tracking the results. Mapping it end to end showed where users needed reassurance and where a wrong turn would cost them trust.

IMG-05
IMG-05IMG-05
The retraining user flow — from spotting a performance drop to deciding to retrain and tracking results.
Foundations
05

Design system

I built a dedicated design system for the product, starting from inspiration that matched BeyondMinds' brand identity — robust, innovative, modular, fresh and user-friendly. It covered typography, components, layout rules, data-visualization patterns, tables, charts and form elements, so the dense dashboards stayed consistent and legible.

IMG-08
IMG-08IMG-08
The design system — moodboards, UI foundations and a component library built on BeyondMinds' brand identity.
Final
06

The final design

The final design walks a user through retraining without ever losing them. The inference screen flags when a model needs retraining and shows a clear process bar while it runs; when a new model is ready, it's surfaced for review. The retrain screen puts the new model's results head-to-head against the previous one — Precision, Recall, AUC and Dice Loss — so the deploy decision is based on evidence, not a leap of faith. A monitoring view tracks the model's health over time.

IMG-09
Screen 1 · IMG-09Screen 1 · IMG-09
Notification for retraining a model — surfaced in the inference screen, in context.
IMG-10
Screen 2 · IMG-10Screen 2 · IMG-10
The retraining process bar — clear progress while the model retrains.
IMG-11
Screen 3 · IMG-11Screen 3 · IMG-11
New model available — surfaced for review when retraining completes.
IMG-12
Screen 4 · IMG-12Screen 4 · IMG-12
New model vs previous model — Precision, Recall, AUC and Dice Loss compared side by side before deploying.
IMG-13
Screen 5 · IMG-13Screen 5 · IMG-13
Monitoring details — class predictions, confidence, input quality and feedback over time.

"Every screen answers one question: can I trust this model enough to deploy it?"

Reflection
07

Reflection & what I learned

This was an early project, built from the ground up — there was no "old version" to fix, just a hard problem: how do you let someone who isn't a data scientist make a confident decision about retraining and deploying a model? The answer wasn't more data on screen. It was hierarchy, comparison, and a guided flow that made each step feel safe.

The research backs why this matters: retraining that feels unpredictable erodes trust and slows adoption, even when the model itself is sound. Designing for confidence — showing the new model against the old, surfacing only what each step needs — is what turns an accurate model into one people actually deploy.

  • Built a dedicated design system from scratch — moodboards, UI foundations and a component library — so dense, data-heavy dashboards stayed consistent and legible.
  • Reframed a deeply technical task as a trust problem: the design's job wasn't to show the model worked, but to help a non-expert believe it enough to act.