Skip to content
Alina Kabanets
← All work

Case study 01 · Vigorant, Borna Care, US healthcare SaaS

Two healthcare MVPs, designed from scratch

Borna Care, product demo
Scene 1 of 4
Patient, booking
Patient app: choosing a service, doctor and time slot
Admin, clinic dashboard
Admin dashboard with services, forms, pending users and today’s appointments
11pm, patient books

Sarah opens Borna Care at 11pm and books her dental appointment without calling anyone. She picks her service, doctor and time slot in under two minutes.

Role
Lead product designer (UX/UI), front-end contributor
Team
Founder, product manager, back-end/DevOps and front-end developers, supporting designer (mentored by me)
Timeline
Nov 2025 – Feb 2026 to MVP · contract Oct 2025 – Mar 2026
Tools
Figma, Design system, React, TypeScript

Key results

  • Patient portal and admin portal designed and shipped in ~4 months
  • Standalone Forms product won Borna’s first paying client
  • One permissions matrix that engineers implemented without rework
  • 60+ bugs caught and documented before launch

Team

A small team building a new product from zero.

  • Me

    Lead product designer, front-end contributor

  • Founder

    Product direction, clients

  • Product manager

    Roadmap, requirements

  • Back-end / DevOps developer

    APIs, infrastructure

  • Front-end developer

    Web app build

  • Supporting designer

    Onboarded and mentored by me

Context

An agency building its own product.

Vigorant is a healthcare marketing agency working with dental clinics. In 2025 it set up a small in-house team to build its own SaaS product, Borna Care, as a new revenue stream: software that takes a clinic’s patient admin off the phone and off paper.

I joined to design marketing websites. A month later I moved to the product team full-time, as its only product designer.

The problem

Patients book by phone during office hours, fill in the same paper forms at every visit and chase invoices. Clinic staff re-type all of it.

What we had to achieve: two connected products, one for patients and one for clinic staff, designed from zero, ready for real clinics within months, and built as the foundation for a five-product platform.

Dash Vigorant analytics dashboard with traffic charts, before the redesignDash Vigorant leads and business metrics charts, before the redesign
The starting point: Dash Vigorant, the agency’s analytics dashboard, with its own visual language. The new products needed a system that could hold five products, not one.

01 · Discover

Learning a new domain, fast.

  • Learned the dental and healthcare domain from scratch, including what HIPAA means for UI.
  • Reviewed more than 10 patient-portal and practice-management products: what patients expect, and where clinic workflows break.
  • Mapped the recurring pains: repetitive paperwork, scheduling by phone, confusing billing and managing family members’ care.
Desk covered in research notes, needs and pains grids, and paper sketches
Research notes turned straight into sketches. The question on every page: how can we make this as few steps as possible?

02 · Define

Every journey, for every role, before any screen.

I mapped the full product for patients, clinic admins and providers: every action, decision and edge case, with open questions pinned next to the step they affected.

Complete patient user flow: sign-up and login, homepage, and ten branches from booking to educational content
The patient journey, one of three role maps. It became the team’s shared map for scoping, estimating and building.
Detail of the patient flow: new-patient and forgotten-password decisions leading to the homepage
Detail: entry into the portal. Decisions in blue, screens in yellow, open questions in grey.

The hard trade-off: cutting to an MVP

The flows described the whole product. The MVP kept what a clinic needs on day one: appointments, forms, payments, family members and notifications. It deferred messaging and telehealth, treatment history and educational content.

I rebuilt the information architecture and flows around that smaller scope, so the MVP felt complete rather than unfinished, with room for the deferred features to slot back in without a redesign.

03 · Develop

Exploring widely before narrowing.

On paper, exploration was cheap. I sketched several models for the patient home, from a “puzzle” dashboard and a bookshelf metaphor to an assistant asking “what do you need to do today?”, and six ways to show treatment history.

Sketches of patient home layouts: cards, puzzle, bookshelf, tailored statsSketches on minimising steps, and AI ideas: smart prioritising, voice panelSketches of a unified booking calendar and notes on making it more humanSketches of six treatment history visualisations: timelines, steps, columns
Four of the sketch pages. Treatment history was explored here, then deferred at the MVP cut.

Directions that didn’t ship

My early concepts used a soft, neumorphic style: a home for the future five-product platform, Dash redrawn in the new language, and the first patient form.

Exploration: a platform home listing apps, today’s snapshot and recommendationsExploration: patient form with a step tracker and a My Self / My Child toggleExploration: Dash Vigorant paid advertising dashboard in a neumorphic style
They set the structure (a platform home, the stepped form, the “My Child” toggle) while the visual style was simplified for the shipped product.

A design system for five products

I built the system in Figma (colour, type, spacing, components and interaction patterns) and owned it as the product scaled to multi-clinic setups.

Early palette: deep red, amber and three greensFinal palette: deep red, amber, teal, pale teal and off-white
Two palette directions. The second kept the brand’s red and amber as accents and moved the base to a calmer teal, better suited to a healthcare product.

Key moments

Two decisions that saved the team time.

Super profiles: redesigning around the clinic

The product grew fast: Forms, then the patient portal, then the admin portal, then multi-clinic support. My first super profile nested clinics inside the owner’s account. As clinics were added, admins needed to work inside a clinic rather than hunt for it. I redesigned the IA, menus and profiles so that entering a clinic became the first step.

RBAC: one table instead of guesswork

Role and permission requirements were ambiguous. Rather than design screens on assumptions, I made a comparison matrix of roles and permissions and resolved every open question with the founder and developers. Then I revisited every flow and annotated the handoff.

Engineers implemented it without rework, which saved the team a couple of days.

04 · Deliver

Two portals, shipped in four months.

The patient and admin portal MVPs were ready in February, four months after I started on the product. Then we kept shipping features on top.

Patient portal home: upcoming appointment, forms, payments, dependents and notifications cards, with a calendar
Patient home: everything a patient needs to do, one step away. The cards replaced the long menu from the first sketches.
Appointment detail with provider, time, location map and required formsPatient billing: pending payment requests and recent transactions
Appointment detail and billing: everything about a visit, and what’s owed, in one place.
Dependents: managing appointments and profiles for family membersAdmin: creating a payment request in four steps
The family-care pain from research became dependents: one account, the whole family. On the clinic side, a payment request takes four steps.
Admin: weekly service availability slots per providerAdmin dashboard: services, forms overview, pending users, payments and today’s appointments
The clinic side: provider availability, and the admin dashboard with today’s appointments. Confirmations go out by email and SMS automatically, so nobody has to phone the patient.

Forms: from exploration to first paying client

Intake forms became a standalone product, Borna Forms. It was the first part of Borna to be sold, and it won the product’s first paying client.

First exploration of the patient intake formShipped patient intake form with sections for demographics, dental and medical history
From the first concept to the shipped form. The “My Self / My Child” toggle grew into the dependents feature.

Handoff and QA

  • Annotated handoffs and component consistency reviews, working directly with both developers on feasibility.
  • Fixed a few UI bugs in code myself.
  • Tested the built product before launch and logged 60+ bugs in Azure Boards.

Results

What shipped, and what changed for me.

From a blank Figma file to MVP UI for two products
4 months
From a blank Figma file to MVP UI for two products
Paying client for Borna, won by the Forms product
1st
Paying client for Borna, won by the Forms product
Bugs caught and documented before launch
60+
Bugs caught and documented before launch

My role grew with the product. I was given lead product designer responsibilities because the team saw high potential. My work spread beyond design, into product decisions and a few front-end fixes in code. The founder started asking me product questions, like whether to sell features separately or as one package, which is how I started learning product management.

Reflection

What I’d do differently.

  • Test with real clinic staff earlier. I proposed and planned user testing before launch. Ideally it goes into the plan from week one, not at the end.
  • Define success metrics up front. We shipped fast but didn’t instrument the launch. At Deaku I now set activation criteria before designing.
  • Next on the roadmap was bringing Dash Vigorant into the new system and designing two more products on the same foundation.

Beyond the brief

Mentored and onboarded a supporting designer · designed three marketing landing pages and an email template · contributed to the logo and brand book · designed the Borna AI website · completed HIPAA compliance training · introduced AI design tools to the team.