Digitizing cancer reporting without disrupting the people doing the work.
A proof of concept designed to explore how a highly manual cancer reporting workflow could become a more structured, standardized, and scalable digital experience.
Designed as part of a global IBM pro bono initiative in collaboration with INCAN, Paraguay.
The opportunity
A global team brought together to solve a local challenge.
SRAP (Synoptic Cancer Reporting for Anatomical Pathology) was developed as part of an IBM global pro bono initiative that brings together selected IBM professionals to work on high-impact challenges.
After a competitive selection process, I was selected to join an international, multidisciplinary team working with INCAN, Paraguay's National Cancer Institute.
Our team included professionals from different countries and backgrounds, including the United States, Australia, India, Colombia, Europe, and Mexico. Before meeting in person, we spent two months collaborating remotely, getting to know one another, understanding the organization, and preparing for the work ahead.
We then traveled to Paraguay to work directly with INCAN and develop a proof of concept grounded in the realities of its healthcare environment.
Project timeline
From global collaboration to on-site discovery.
The project combined two months of remote collaboration with on-site work at INCAN, moving from preparation to research to a tangible proof of concept.
Competitive selection
I applied and went through a selection process to join IBM's global pro bono initiative.
2 months of remote preparation
Our international team worked remotely to get to know one another, understand the project context, and prepare for the on-site collaboration.
On-site in Paraguay
We worked directly with INCAN, observing workflows, conducting research, running workshops, and learning from the people involved in cancer reporting.
Proof of concept
We translated our findings into a focused digital proof of concept designed to demonstrate a potential foundation for standardized cancer reporting.
Designed as part of IBM's Global Pro Bono Program, from remote preparation to on-site discovery.
The context
When critical information depends on manual processes.
Before designing a solution, we needed to understand how cancer reporting actually happened.
At INCAN, key parts of reporting and record management relied heavily on manual and paper-based processes. Synoptic reporting organizes pathology findings into a standardized, structured format, rather than free-form narrative text. Without a unified digital experience, information could be difficult to access or interpret, creating opportunities for inconsistency and inefficiency.
Why it matters
In cancer care, information delays can have real consequences.
Cancer reporting is part of a broader chain of decisions and care. When critical information takes longer to create, access, interpret, or share, it can add friction to processes where timely information matters.
While SRAP was a proof of concept and did not measure clinical outcomes, the project explored how more structured and accessible reporting could help support a more efficient flow of information.
At the same time, introducing technology into an existing healthcare environment came with its own challenge: the goal could not simply be to digitize everything.
Any solution needed to support existing professionals and workflows without creating additional complexity.
When the information matters, time matters too.
Better reporting was not just about replacing paper with a screen. It was about exploring how critical information could move through the system with more structure and less unnecessary friction.
The challenge
How might we introduce standardized cancer reporting without making an already complex workflow harder to use?
The project aimed to explore how digital reporting could improve consistency and accessibility while remaining practical for pathologists, doctors, and administrative staff.
The challenge was not simply to create a digital form.
We needed to understand what information mattered, how reports were created, where friction existed, and how a new system could introduce more structure without forcing users to adopt an unnecessarily complicated workflow.
Standardization only works if it fits the way people actually work.
My role
The sole UX Designer on a global multidisciplinary team.
I worked as the only UX Designer alongside business analysts, healthcare analysts, developers, and IBM professionals from different disciplines and countries.
My role was to bring a user-centered perspective to the project and translate research, on-site observations, workflows, and reporting requirements into a tangible digital proof of concept.
- On-site observation and workflow understanding
- User interviews and survey synthesis
- Workshop facilitation and participation
- Journey mapping and competitive analysis
- User flows and wireframes
- End-to-end UX for the proof of concept
- Login, dashboard, patient registration, and structured reporting
- High-fidelity UI and interactive prototype
- Business analysts
- Healthcare analysts
- Developers and IBM professionals from different disciplines
- Healthcare specialists and stakeholders, on clinical standards and reporting requirements
My role was not to define clinical standards, but to understand how they connected to real workflows and translate them into a usable digital experience.
Immersion
Before designing, I had to learn how the work actually happened.
Cancer pathology reporting was a completely new domain for me.
Before proposing a solution, I needed to understand the language, processes, constraints, and relationships between the different people involved in creating, using, and managing cancer reports.
Working on-site allowed us to move beyond assumptions. We observed the environment, spoke with professionals, mapped workflows, and learned how the existing process worked in practice.
My goal was not to become a healthcare expert. It was to learn enough to ask better questions and design around what actually mattered.
Research and direct observation helped transform an unfamiliar domain into a problem we could design around.
Research
Learning from the people inside the process.
Our research focused on understanding the workflows and priorities of the people involved in cancer reporting, identifying friction in existing processes, and exploring what a more unified digital experience would need to support.
Key insights
The problem was bigger than putting a paper report on a screen.
Reporting required significant manual effort.
Pathologists reported spending an average of 2-4 hours per report, partly due to the lack of standardized templates and the need for manual adjustments.
Existing processes required too much manual work.
70% of respondents expressed dissatisfaction with outdated tools that required frequent manual adjustments.
Users wanted support without complexity.
The most requested capabilities included real-time guideline updates, multi-language support, and a simplified interface.
The opportunity wasn't simply to digitize the report.
It was to create a structured experience that could improve consistency and accessibility while remaining practical for the people doing the work.
Design principle
Don't digitize the complexity.
A digital version of the existing process could easily have reproduced the same complexity in a different format.
Instead, the design focused on understanding which parts of the workflow needed to be preserved, which information needed more structure, and where the experience could reduce unnecessary effort.
Preserve what works.
Respect the knowledge and workflow of the professionals already doing the work.
Structure what matters.
Organize critical information around standardized reporting requirements.
Simplify where possible.
Use the digital experience to reduce unnecessary friction rather than adding more steps.
Workflow design
Turning observations into a digital experience.
Once we understood the existing workflow and identified the main opportunities, the next step was to translate those findings into a focused digital experience.
I mapped how users would move through the proof of concept and defined the key moments required to make the reporting experience understandable and tangible.
Iteration
Connecting research to design decisions.
Understand
Mapping the experience helped make the existing process, participants, and opportunities visible.
Explore
Wireframes helped translate the workflow into an initial digital structure before visual design.
Make it tangible
The final proof of concept brought the workflow into a consistent and usable interface.
From understanding the workflow to exploring and validating a digital direction.
The proof of concept
Designing the minimum experience needed to make the idea real.
The goal was not to design a complete healthcare platform.
The proof of concept focused on the core experience required to demonstrate how structured cancer reporting could work digitally and provide a foundation that could potentially evolve over time.
What the proof of concept included.
- Login and account access
- Dashboard of forms in progress and completed
- Step-by-step patient registration
- Structured synoptic reporting by section
- Report approval and comments
- Language selection
How users moved through it.
Defining an intentional scope to make the idea tangible without designing a complete platform.
Deep dive
Designing structure without overwhelming the user.
The reporting experience was the core of the proof of concept.
My role was to determine how the required information could be presented digitally in a way that supported structured reporting without turning the experience into an overwhelming collection of fields.
I focused on information organization, hierarchy, and interaction patterns that could make a complex process easier to navigate.
Keeping patient context visible
Key patient and biopsy details stay at the top while the report is completed.
Breaking the report into sections
Synoptic sections expand one at a time and show completion status, so the report doesn't feel like one long form.
Bringing approval into the report
Approval, printing, sharing, and comments live alongside the report, replacing manual steps outside the system.
Design system
Using an existing system to focus on the actual problem.
I used IBM Carbon Design System as the visual foundation for the proof of concept.
Rather than creating a new visual language from scratch, using an established design system allowed the design effort to focus on the workflow, information architecture, interactions, and usability of the experience.
The challenge was not to reinvent the visual language. It was to understand the workflow and make the right UX decisions.
Final prototype
A focused system designed to demonstrate a larger opportunity.
The final outcome was a digital proof of concept that brought together the research, workflow understanding, reporting requirements, and design exploration developed throughout the project.
The prototype provided a tangible way to explore how a more structured cancer reporting experience could work within the healthcare environment.
Outcome
A tangible starting point for a larger conversation.
A shared proof of concept
The project transformed research, observations, and reporting requirements into a tangible digital experience that stakeholders could see and discuss.
A more concrete vision
The prototype helped make the opportunity for more structured digital reporting visible beyond documentation and abstract requirements.
A foundation designed to evolve
Rather than attempting to solve every challenge at once, the proof of concept focused on the core experience and left room for future development.
Reflection
Designing for adoption means designing for context.
SRAP taught me that entering a new domain does not mean having all the answers before you start.
As the only UX Designer on the team, I had to quickly learn a complex healthcare environment, understand unfamiliar terminology and workflows, and collaborate with people whose expertise was far beyond my own.
The experience reinforced the importance of spending time where the product will actually live. Documentation gave us context, but observing the environment and talking directly with the people involved changed how we understood the problem.
It also taught me that introducing technology is not automatically an improvement. A solution can follow standards, include the right features, and still fail if it does not fit into the reality of the people expected to use it.
In the end, the work was about learning enough to ask better questions, understand what mattered, and translate that complexity into an experience people could realistically use.
