Mais Terapias
Designing a scalable healthcare SaaS for complex operational workflows
Overview
Mais Terapias is a B2B healthcare SaaS platform designed to support therapists and clinics in managing appointments, patient records, and clinical workflows. Initially designed for individual professionals, the product evolved to support multi-professional clinics, introducing significant challenges related to data privacy, permissions, and legal responsibility.
This case focuses on how I contributed as a Product Designer to redesign the platform’s user architecture, permission system, and collaboration flows, ensuring scalability, safety, and clarity in a highly sensitive health context.
Context & Challenge
As the platform grew, clinics began using workarounds that exposed critical risks:
Shared logins among multiple professionals
Implicit access to patient records
Lack of clarity around who could view, edit, or manage clinical data
Different operational models (CLT, percentage-based, room rental, multidisciplinary teams)
In a health product, these issues are not just UX problems — they represent legal, ethical, and trust risks.
The core challenge was not adding features, but redesigning the system to support real-world clinic behavior without compromising data security or usability.
The Core Problem
How might we design a platform that:
Protects sensitive patient data by default
Supports multiple user roles with different legal responsibilities
Scales from solo practitioners to large clinics
Makes collaboration explicit, intentional, and auditable
Keeps complexity out of the interface while respecting its necessity in the system
My Role
Product Designer
Focused on UX architecture, system thinking, and product strategy.
I worked closely with product and engineering to:
Conduct qualitative discovery with real clinics
Map user roles, permissions, and edge cases
Design invitation-based collaboration flows
Translate legal and operational constraints into clear UX patterns
Balance usability, security, and scalability
Key Constraints
Health data privacy and professional ethics
Different responsibilities across therapists, admins, and secretaries
Legacy behavior from earlier versions of the product
Need for fast iteration without compromising safety
Limited tolerance for error in clinical records
Design Approach
1. From Implicit to Explicit Collaboration
Previously, patient data was often shared implicitly within a clinic.
Decision:
All collaboration became explicit and intentional.
Professionals must be invited to join a clinic
Invitations require acceptance
Access to patients and records depends on role and context
No automatic or invisible data sharing
This increased short-term friction but significantly reduced long-term risk.
2. Role-Based Permission Architecture
We designed a clear permission model:
Admin: Manages clinic structure and team, but cannot edit another professional’s clinical records
Therapist: Full control over their own patients and records
Secretary: Operational access only (scheduling, basic data), no access to clinical content
This structure mirrors real-world accountability and prevents accidental violations of privacy.
3. Designing for Multiple States (Not Just Happy Paths)
The invitation and onboarding flows had to support multiple states:
User already has an account
User does not have an account
Invitation pending
Invitation accepted
Invitation expired
Invitation resent
Instead of hiding this complexity, I focused on clear system feedback, visibility of status for admins, and recovery paths through notifications and actions.
4. Complexity in the System, Simplicity in the Interface
The product has inherently complex rules, especially around permissions and data ownership.
My role was not to eliminate complexity, but to:
Reduce cognitive load in daily workflows
Hide configuration behind intentional actions
Surface only what users need at each moment
Prevent dangerous actions through structure, not warnings
Key Product Decisions
Some important decisions shaped the product:
Explicit invitations instead of automatic access
Restricting secretarial permissions to avoid legal risk
Accepting short-term friction to ensure long-term trust
Prioritizing safety and clarity over speed and convenience
Designing for scalability instead of one-off clinic behaviors
These decisions required close collaboration with engineering and product, as each rule introduced multiple edge cases.
Impact
Although still evolving, these changes resulted in:
Reduced risk of unintended data access
Greater trust from clinics handling multidisciplinary care
Clearer accountability between professionals
A scalable foundation for onboarding clinics of different sizes
A system aligned with ethical and legal expectations of health software
Key Learnings
This project reinforced a key principle in health product design:
Great UX is not about removing complexity, it’s about making responsibility, consent, and trust clear and intentional.
Designing for healthcare means designing for consequences. Every interaction must respect not only usability, but also ethics, safety, and accountability.
