I make complexthings clear.

Context

A national financial system made of independent cooperatives.

1. 3.9M+MembersProducers and account holders who own the cooperatives
2. 116CooperativesLocal, autonomous, each with its own way of working
3. 5Central cooperativesRegional coordination and supervision
4. 1Sicredi (CAS)Confederation and Cooperative Bank: shared services, products and risk

The challenge

A critical process was still being built manually.

Every Sicredi cooperative created its Technical Rural Credit Projects its own way, in isolated tools, many running outdated technology, with no data structure or reusable history.

The result: constant rework, zero visibility into project status, and delays releasing funds to rural producers who depended on this credit to plant their crops.

• Manual creation, no standard across cooperatives
• No centralized visibility into status
• Constant operational rework
• Data from previous projects lost
• Delays releasing funds to producers

My role

The sole product designer, from discovery to final interface.

I was directly responsible for UX decisions and information architecture within a multidisciplinary team, with no other designer to share scope.

• Led discovery with cooperatives, technicians and external partners
• Mapped journeys and personas for the 4 user profiles
• Translated 148 user stories into product architecture
• Designed wireframes, prototypes and the final interface
• Ran usability tests and iterated based on real-world use

Method

From 47 business opportunities to 148 mapped user stories.

1. 01

   Kickoff & context

   Immersion in the Rural Credit business with business areas, cooperatives and external partners.

2. 02

   Personas & journeys

   Mapping of the 4 profiles involved and the specific journey of each within the same process.

3. 03

   Story mapping

   Translating business complexity into 148 stories: 104 user stories and 44 technical stories.

4. 04

   Wireframes & prototypes

   Information architecture and flows validated before any visual decision.

5. 05

   Real-world testing

   Validated on cooperatives' real laptops, not on agency reference screens.

Product inception

Personas

Built in group dynamics with the people who live the process every day, one board per profile: who they are, what they need, and what gets in their way.

Chico Bento

Associate

“Fast, no red tape, to release the money.”

The rural producer requesting financing.

NeedsA fast, simple process with minimal bureaucracy and quick access to resources.

João / Pedro

Technical Expert

“Money in the associate’s account.”

Responsible for preparing the Technical Rural Project and providing the required technical information.

NeedsAn efficient way to create, manage and submit the project.

Paula / Ivan / Gallyzé

Cooperative

“Standardization: operations and business.”

Responsible for managing and reviewing the financing operation.

NeedsStandardized information, greater visibility and less operational effort.

Teresinha

CAS

“Reliable, agile and flexible.”

Sicredi's central Rural Credit area, responsible for overseeing operations across the cooperative system.

NeedsA reliable, agile and flexible process with visibility and control across the system.

Wireframes

Styleguide

The solution

A rural project broken into structured blocks, no longer one continuous form.

Protec Agro split the Technical Project into independent modules (associate data, budget, feasibility, environmental licensing, among others), reducing cognitive load and enabling data reuse across blocks.

Design decisions

Three decisions that sustained the product at scale.

Learnings

What we only discovered by testing with real users.

01The design didn't fit the user's screen

We designed the screens at 1920px wide. But cooperatives mostly worked on laptops with factory-default settings at 1366px, the most common resolution in Brazil. We found this out in the very first round of testing, and adapted the entire interface to that real resolution.

1920px→1366px

02Modals hid the information users needed

Users needed to reference data already shown on screen to complete or calculate a new entry. The modals we used hid exactly that reference. We replaced them with sliding side panels that keep context visible while the user enters new data.

Modal→Side panel

Impact

From a manual document to a product at national scale.

Results

Two years from launch to national adoption.

Next steps

A foundation for the rest of the Rural Credit ecosystem.

Protec Agro's modular architecture was designed to sustain scenarios beyond the initial scope. After launch, it became the foundation for new fronts across the ecosystem:

• Vehicle Financing
• Compliance & Inspection
• Process Standardization
• Investment Solutions
• Directed Credit Lines
• Credit Bureau Integration
• Classification Engine
• External Data Inputs

Context

A hospital-wide record system, and one of its most demanding specialties.

1. 01Diagnosis & stagingType of cancer and how far it has spread. It defines everything that follows.
2. 02ProtocolThe treatment plan: which drugs, in which doses, on which schedule.
3. 03Cycles & sessionsTreatment repeats in cycles, each with planned days of administration.
4. 04AdministrationPharmacy prepares and checks each dose; nursing administers and records it.

Oncologists, pharmacists and nurses all work on the same treatment, each from a different angle, and they need to see where the patient is in that sequence at any moment.

The problem

The complexity wasn't in the information. It was in the navigation.

Tasy already held every clinical data point needed: diagnosis, staging, protocol, medications, doses, cycles, sessions, authorizations. The problem was never a lack of data.

It was structural: every clinical context lived in its own panel, and every panel required opening a new system session to be consulted. In practice, a doctor or pharmacist trying to answer a simple question like “what's this patient's next cycle, and what's already been administered so far?” had to:

• Open one session to check diagnosis and staging
• Open another session to check the defined protocol
• Open another to see cycles and status
• Open another to check medications and doses for the current session

Every panel switch broke the context already built mentally. The professional carried information “in their head” from one screen to the next, in a domain where a context error has a direct consequence for the patient.

Legacy flow: panel fragmentation

Step through the original navigation. The numbers in each description point to the matching markers on the screen.

010203040506

My role

UX Lead heading a team of three designers.

My responsibility went beyond the final interface.

Discovery

Understanding the problem with the people who live the treatment.

To validate and deepen this hypothesis, I ran direct conversations with three key roles in the clinical journey.

These conversations confirmed the diagnosis: the problem wasn't the absence or excess of clinical data, but the navigation architecture that artificially separated it into sealed compartments.

Design decisions

From panel-based navigation to a layered view.

01

From isolated panels to a multi-level component

The core decision of the redesign was to build a single component able to group up to three levels of information at once, on the same screen: patient context, treatment context, and progress context (sessions, medications, history). Instead of forcing the professional to open a new session for every layer, that information now coexists on one screen, with a clear visual hierarchy between what's essential and what's supporting detail.

Why this approach, and not others

Simplifying by removing fields was ruled out early: data like dose, medication and status is critical for safety and auditability. The alternative chosen was to keep the data depth intact, but eliminate the navigation cost between it.

02

Making treatment a journey, not a collection of screens

The experience was reorganized around the real treatment sequence instead of mirroring the system's internal module structure:

1. Diagnosis
2. Staging
3. Protocol
4. Cycle
5. Session
6. Administration

This aligned the interface with the professional's mental model: they think in terms of the patient's treatment, not the software's features.

03

Progressive disclosure as an answer to data volume

To sustain the unified view without overloading the screen, information was organized into depth layers:

1. Summary
2. Detail
3. History

This lets the professional access the level of granularity they need in the moment, without losing the rest of the context.

The solution

One continuous view instead of sessions opened in succession.

The same task, locating a patient's full treatment history, used to require multiple sessions opened in succession. Now everything lives in a single continuous view.

BeforeAfter

Before and after. Drag the handle to compare the protocols list with the new layered view.

Outcome

One visual context instead of rebuilding reasoning at every screen.

The simplification was real in how sessions and sub-sessions were handled: professionals started navigating within a single visual context instead of rebuilding clinical reasoning at every screen change.

The new structure was validated qualitatively with the doctor, the pharmacist and the oncology specialist, who confirmed it better reflected day-to-day clinical reasoning.

Learnings

In clinical systems, the design work is in the relationships between information, not in isolated screens.

In a clinical system, a single piece of information rarely has meaning on its own:

1. Diagnosis influences staging
2. Staging influences treatment
3. Treatment defines the protocol
4. The protocol defines medications
5. Medications are organized into cycles and sessions

Showing less was never the answer. The job was to make that chain visible and navigable in one place, turning a collection of records, protocols, medications, cycles and sessions into a coherent picture of the patient's treatment.

The goal was simple: make treatment visible.

Next steps

Where this approach could go next.

Building on this approach, a few opportunities could evolve in future iterations:

• Treatment timelineExpand the temporal representation to cover the patient's entire journey, not just the current cycle.
• Personalized viewsAdapt the information density to the professional's role: physician, nursing, pharmacy or administration.
• Clinical decision supportExplore how to surface relevant clinical information at the exact moment of decision, without increasing cognitive load.
• Integrated dashboardConsolidate diagnosis, staging, protocol, cycles, sessions and administration into a single tracking view.
• Smarter notificationsMake changes, pending items and next steps more visible without creating an excessive number of alerts.

Context

A close runoff, and a flood of information that is hard to compare.

The challenge

Comparable, verifiable and neutral, in a format people can actually read.

The site had to hold a large and sensitive body of information without taking a side, and stay readable for someone deciding their vote on a phone.

• Promises, approved laws and opinions mixed together in coverage
• Investigations reported as if they were convictions, and the reverse
• Different depth of coverage for each candidate
• Facts changing every few days: polls, endorsements, debates, votes in Congress
• Dense legal and economic language that excludes most readers

Principles

Three rules that shaped every screen.

Design decisions

Turning editorial rules into interface.

01

Mirrored pairs instead of separate profiles

Every topic is a row with two cells, one per candidate, always in the same position and color. A sticky header keeps both names visible while reading, so the comparison happens at a glance instead of in the reader's memory.

02

Labels that separate fact from promise

A small set of labels tells the reader what kind of information they are looking at: in the registered plan, said in public, depends on Congress, approved law, under investigation, procedural decision. The labels are explained once, before the content, and reused everywhere.

03

Who gains, who pays

For the proposals with the biggest impact, the first thing shown is who benefits and who bears the cost, as plain chips. Below come the legal path, the arguments for and against, and their sources. Readers get the consequence first and the detail on demand.

04

A fixed format for investigations

Every case, for both candidates, follows the same template: a four-step bar showing the most serious stage reached, then what it is, what is proven, what changed and whether guilt was recognized by the courts. The format prevents tone from doing the judging.

05

A one-minute summary in plain language

A full-width band, in inverted contrast, answers the question most people actually have: what could change if each one wins. It is written for anyone to understand, and it still keeps the source numbers and the views of supporters and critics side by side.

The solution

Built for the phone, where people decide.

Most of this content is read and shared on a phone. On small screens the pairs stack, each cell names its candidate, the section menu scrolls sideways, and a share button sends a link to any section through WhatsApp, Telegram and other networks.

Iteration

A living document, corrected in public.

The campaign kept moving, so the site did too. Each update is logged in a public "What changed" list, with the date and what was added or corrected.

• First version from a comparative report, then expanded with Congress, endorsements, polls and the legal basis of each proposal
• A source audit checked 345 statements and corrected details in four investigation cases
• "Who gains / who pays" brought to the top of each high-impact proposal, with a summary per candidate
• Polls, debates, endorsements and a constitutional amendment added as they happened, up to two days before the runoff

Learnings

In civic information, neutrality is a design decision, not a tone of voice.

Fairness here came from structure more than from wording: the same slots for both sides, the same labels, the same template for every case. Once the rules were part of the interface, they held even when the content was difficult.

The second lesson was about trust. Showing the source of every line, and logging every correction, did more for credibility than any claim of being impartial.

The goal was simple:
Help people compare, not tell them what to choose.