The Challenge

The platform supported several different user roles, each with different responsibilities and permissions. A single user could even have more than one role.

At the same time, the product needed to make large, complex datasets usable. Much of the information lived in long tables with many columns, while details pages contained large amounts of supporting information.

And uploading a dataset was only the beginning. Before information could receive final approval, it needed to move through a review process involving different users, statuses, and potential rounds of changes.

The work centered around three questions:

How should the experience change based on who is using it?

How can we make large amounts of information easier to understand and navigate?

How can we make the review and validation process visible to everyone involved?

My Role

I worked as a UI Designer within a team that was exploring the broader UX and workflow of the product.

My work included:

• User Research: Participated in stakeholder workshops and used research findings to understand user roles, workflows, data requirements, and validation processes.

• Interaction Design: Explored different ways users could navigate complex workflows and move information from upload through review and approval.

• Information Architecture: Worked through how large datasets, tables, details pages, and supporting information should be organized and prioritized.

• UI Design: Designed interface patterns for data-heavy screens, role-specific experiences, statuses, and review workflows.

• Prototyping: Created interactive and animated walkthroughs to communicate potential design directions and make complex workflows easier to evaluate.

• Stakeholder Collaboration: Used workshops and design reviews to surface questions, compare potential approaches, and validate decisions with subject-matter experts.

Rather than designing each screen in isolation, I focused on how the screens worked together as part of a larger system.

Research and Discovery

1. Designing for Multiple Roles

How do you design one experience for users with different responsibilities?

The first challenge was understanding how the product should respond to a user's role and permissions.

Different users needed access to different information and actions. But the situation wasn't always as simple as one person having one role. A user could carry two roles, which meant we needed to think beyond creating separate experiences for each type of user.

Exploring the role model

I worked with stakeholders to map the different roles, responsibilities, and permissions within the system.

We explored questions such as:

• What information should each role be able to see?

• Which actions should be available to each user?

• How should restricted information be communicated?

• What happens when a user has multiple roles?

• How can the experience adapt without making the interface feel fundamentally different for every user?

Rather than creating completely separate interfaces for every role, we explored how the same underlying experience could adapt to a user's responsibilities.

The goal was to make the product feel like one coherent system while still reflecting the permissions that existed underneath it.

This became an important foundation for the rest of the product. The user's role didn't just determine what they could access—it influenced what they needed to see and what actions made sense at each point in the workflow.

02 — Making Complex Data Manageable

How do you give users access to everything they need without showing everything at once?

The product dealt with large scientific datasets, which meant users often encountered long tables with many columns and details pages containing extensive supporting information.

The challenge wasn't deciding whether the information was important. Much of it was.

The challenge was deciding how and when users should encounter it.

Finding the right information hierarchy

I explored different ways of organizing dense information across tables, details pages, and supporting sections.

We worked through questions like:

• Which table columns should appear first?

• Which information needed to remain visible?

• What could be grouped into accordions?

• What belonged in a table versus a details page?

• What information should users encounter first?

• How could we preserve access to detail without creating an overwhelming screen?

For tables, we looked at the information users needed most often and prioritized the columns accordingly.

For details pages, we explored how information could be grouped into logical sections, allowing users to focus on the information most relevant to their current task.

The goal wasn't to hide complexity.

It was to organize complexity so users could understand what they were looking at, find what they needed, and move through the product without being overwhelmed by the amount of information available.

03 — Designing the Validation Workflow

How do you make a multi-step review process understandable to everyone involved?

Uploading a dataset was only the beginning.

Once information was submitted, it needed to be reviewed by a designated Reviewer before receiving final approval.

That created a chain of handoffs between the person who uploaded the information and the person responsible for reviewing it.

We needed to answer:

How does the Reviewer know something is ready?

How does the Reviewer know what to review?

How does the Uploader know what's happening?

What happens when changes are required?

How does everyone know when the process is complete?

Mapping the journey

I worked with the team to map the lifecycle of a dataset from upload through review and final approval.

We explored different ways to communicate:

• When something was ready for review

• Who was responsible for the next step

• The current status of the review

• When changes were requested

• What the Uploader needed to do next

• When the Reviewer had approved the dataset

Rather than treating notifications, statuses, and review screens as separate features, we considered them as connected parts of the same workflow.

Making the workflow tangible

Because the experience involved multiple roles and potential paths, static screens weren't always enough to evaluate the design.

I created animated walkthroughs of potential design paths and used them during stakeholder workshops.

The animations helped stakeholders see the experience unfold and made it easier to identify questions and edge cases:

What happens next?

Who sees this?

What happens if changes are requested?

How does the Uploader know what to do?

What happens after approval?

These conversations helped us refine the workflow before moving further into implementation.

Validation & Iteration

Stakeholder workshops were an important part of the design process.

Because the product involved complex scientific workflows, security requirements, and multiple user roles, there were often several possible ways to solve a problem.

I used prototypes and animated walkthroughs to make those possibilities tangible.

Instead of asking stakeholders to imagine how a collection of screens might work together, we could walk through a scenario and discuss it together.

Map the workflow → explore a direction → prototype → walk through the experience → identify gaps → iterate.

This approach helped us surface issues that weren't always visible when looking at individual screens.

Outcome

The work helped define a more structured experience for managing scientific datasets across upload, organization, review, and approval.

Key outcomes included:

• A role-based experience that accounted for different responsibilities and permissions

• A framework for users who could hold multiple roles

• Clearer information hierarchies for data-heavy screens

• More intentional table and detail-page structures

• Patterns for grouping secondary information without hiding it

• A defined workflow for review, requested changes, and final approval

• Clearer communication between Uploaders and Reviewers

• Interactive and animated prototypes that helped stakeholders evaluate complex workflows

Because this project involved sensitive information, the final interface cannot be shown publicly. The visuals in this case study are reconstructed to communicate the design process and decisions without exposing confidential content.

Reflection

This project changed how I think about designing for complexity.

What initially looked like separate UI problems—a table, a details page, a status, or a notification—were actually connected by the larger system behind them. A user's role affected what they could see. Their permissions affected what they could do. The amount of data affected how information needed to be organized. And the state of the data affected what could happen next.

The biggest lesson I took from the project is that complex products don't necessarily need to feel complex to use. The complexity can exist underneath the experience while thoughtful information architecture, clear interaction patterns, and visible workflow states help users understand what matters and what they need to do next.

It also reinforced the value of prototyping complex ideas early. The animated walkthroughs gave stakeholders something tangible to react to and helped turn complicated workflow discussions into collaborative design conversations.