top of page
As UX and Product Designer, I co-designed a complex medical SaaS platform from scratch alongside Brainsway's Design Manager and the team

2022–2024 | Remote, with Alex Ritvin (Design Manager)

1. Information architecture and OOUX mapping
2. Figma design system and component library
3. Prototype rounds, research, and MVP build

1. Information Architecture and OOUX Mapping

Brainsway was making a fundamental shift: from storing data on individual medical devices to a cloud platform that serves all their devices and clinics simultaneously. There was no existing system to inherit. Everything had to be designed from the ground up.

Working alongside Alex Ritvin, Brainsway's Design Manager, the first phase was about structure. Before any wireframe, before any visual decision, we had to understand what the system was actually made of.

That started with defining the information architecture together. Sessions with Alex and conversations with internal domain experts across the company gave us the raw material. Then I used OOUX, Object-Oriented UX, to map every object in the system and surface gaps and inconsistencies in what we were building.

OOUX (Object-Oriented UX) is a methodology that treats a product as a set of interconnected objects, each with its own attributes, relationships, and actions. Applied before wireframing, it catches structural problems that would otherwise only surface late in development, when they cost far more to fix.

The Challenge

The system had to handle real medical-domain complexity from day one. Multiple device types. Multiple clinic workflows. Clinical data with strict consistency requirements.

The risk with this kind of project is starting too fast. Jumping to screens before the structure is solid creates a system that looks complete but falls apart as soon as edge cases appear or the platform needs to expand.

The Process

Alex and I started with collaborative IA sessions. We brought in company experts from different areas to make sure we were capturing domain knowledge we did not have ourselves. Medical device platforms carry terminology, workflow logic, and data relationships that are not obvious from the outside.

From there, I ran the OOUX mapping. Every entity in the system: devices, clinics, patients, sessions, reports, users, was mapped as an object with its own attributes and relationships. The map immediately revealed gaps. Objects that were assumed to be simple turned out to have multiple states. Relationships that seemed clear were ambiguous when you pressed on them.

We built the overall platform structure diagram jointly: the full architecture, how sections connected, what navigation had to support. Only after that was solid did we move to low-fidelity wireframes for the entire platform.

I also prepared a visual direction proposal at this stage, demonstrated on individual screens, to establish the design language before committing to the full system build.

The Solution

A fully mapped information architecture covering all objects, relationships, and states in the platform. Built before any visual work began.

An OOUX object map that surfaced structural gaps early and gave us a shared language for discussing the system across design, product, and development.

A platform structure diagram that defined navigation logic and section relationships for the full product.
Low-fidelity wireframes for the entire platform, grounded in the IA, ready to carry into the design system phase.

The Result

The structural phase gave the rest of the project a stable foundation. When we moved into visual design and component building, we were not discovering new structural problems. The architecture held.

That foundation also meant that when stakeholder interviews surfaced feedback later, we could evaluate it against a clear system model rather than renegotiating structure under pressure.

Main image

Brainsway, designing a Medical SaaS Platform from Scratch

- Designing a cloud-based platform from zero: IA, system architecture, and full UX
- OOUX methodology to identify structural gaps before visual design begins
- Atomic design component library built and maintained across 2+ years
- Two prototype rounds, stakeholder interviews, and MVP handoff to development

2. Figma Design System and Component Library

With the architecture solid, the next phase was building the visual system that would carry the platform through MVP and beyond. This meant one thing above all: the component library had to be built correctly from the start, because a medical SaaS platform that spans clinics, devices, and multiple user roles cannot afford to patch its design system midway through development.

I built the Figma component library using Brad Frost's atomic design methodology. Atoms to molecules to organisms: each layer built from the one below it, each component cleanly defined before being composed into larger patterns. The library was maintained and expanded across the full two-year engagement.

The Challenge

A component library for a system this complex is not a one-time deliverable. It is a living document that has to stay reliable as the product evolves. Components that are poorly named, inconsistently structured, or built without edge cases accounted for create compounding problems at every subsequent design decision.

The challenge was building it with enough rigor at the start that it could absorb two years of product growth without losing its integrity.

The Process

I followed the atomic design framework strictly. Every component was built from its base state before variants were added. Naming conventions were consistent. States were fully specified. The library was organized so that any designer, or any developer reading the Figma file, could navigate it without needing a walkthrough.

In parallel with the component build, I conducted best-practices UX research for specific features. Medical software has a body of prior research on information density, error states, data display, and user trust that it makes sense to draw on rather than rediscover.

Research and component work ran simultaneously because they informed each other. A best-practice pattern found in research could immediately influence how a component was structured.

The Solution

A Figma component library built on atomic design principles: consistent, named, state-complete, and maintained across the full engagement.

Best-practices UX research feeding directly into component decisions and feature-level design choices.
A design system that could expand as the product grew without requiring structural rework.

The Result

The component library held across two years of product development. When new features were designed, the existing library provided the building blocks. When the platform scope expanded, components could be extended without breaking what already existed.

Alex's testimonial noted the scalability of the work specifically: "intuitive and scalable interfaces by leveraging object-oriented principles." That is not an accident of natural talent. It is a result of the system being built correctly from the beginning.

3. Prototype Rounds, Research, and MVP Build

With the design system in place, the platform moved into prototype-driven iteration. Two rounds of prototypes, a stakeholder interview process run by Brainsway's US-based team, and a final MVP build carried the project from validated concept to development-ready product.

This phase was about precision. The MVP had to be right. Not visually polished for its own sake, but correct at the level of edge cases, state handling, and developer clarity.

Final Takeaways

Two years on a project like this teaches you something that shorter projects cannot: the cost of getting the structure wrong early.

On Brainsway, the IA and OOUX phase happened before any visual work. That felt slow at the time. There is a particular pressure in the early stages of a build project to show something that looks like progress. Structural diagrams and object maps do not photograph well in a status update.

But the design system phase was faster because the architecture was clean. The prototype rounds were more useful because they were testing a coherent system, not patching structural decisions that should have been made earlier.

Credits: Alex, Moria and Udi from Brainsway.
Two years of close collaboration and a strong working relationship.

Image (used in this use case) rights belong to Brainsway.

bottom of page