Organizing a complex product before implementation.

The product aims to centralize management activities for physiotherapy and Pilates clinics. The considered domain includes schedules, patients, appointments, classes, packages, finance, documents, and communication, as well as distinct operational rules.

The challenge was to organize a broad idea into a coherent product structure and validate the experience before defining production architecture.

The work moved through connected stages, keeping decisions and prototype aligned.

1. Product definition

   Organizing the problem, audience, and considered domain.

2. Flows

   Mapping relevant journeys, rules, and exceptions.

3. Screen architecture

   Structuring navigation and relationships between modules.

4. Identity and UI/UX

   Visual direction and the states needed to make flows legible.

5. Prototyping

   Validating decisions early and identifying inconsistencies.

The schedule brings individual appointments and classes into the same context. During scheduling, supporting actions — such as registering a patient who does not exist yet — happen without leaving the flow or losing data already entered.

×

×

Light and dark as part of the same system

Both themes preserve the same hierarchy, states, and interaction structure. The adaptation is not just a color inversion: surfaces, contrast, and functional elements still need to remain readable in both contexts.

LightDark

The decisions below belong to product definition and prototyping; they do not describe implemented functionality.

• Individual and group schedules

  Both contexts require their own rules and readings instead of one generic flow.

• Recurrence and conflicts

  Recurring appointments need to make exceptions and overlaps explicit.

• Two status layers

  The operational state and appointment state are related but distinct information.

• Quick patient registration

  Scheduling can open an essential registration step and return to the original flow.

In prototyping

The product direction is defined. Implementation comes later.

Movune remains in prototyping. Product definition, the main flows, screen architecture, and visual identity already have a consolidated direction, while the prototype continues to be refined before production architecture is defined and implementation begins.

Refine before building.

The next step is to finish refining the flows and the experience in the prototype. From that foundation, architecture and stack can be defined with the product’s real needs already established.