Designing a Role-Based Investor Portal

This project was completed under NDA. Client details are confidential, and every screen shown uses dummy data.

Context

A cloud infrastructure company needed a dedicated portal where investors could monitor the performance of the physical computing hardware they own.

They also have portfolio managers and admins that needed to run the same platform behind the scenes.

Team

There were three of us: me, an engineering representative, and the investor relations manager.

That small crew got the job done. The portal shipped on time, with 50+ screens once you count every edge case, form, and validation. It also came in dark mode, with tablet and mobile layouts.

The Problem

Dense Data for Non-Technical Readers

The products were technical hardware, so the data was full of engineering specs and performance numbers.

Investors needed the opposite: their returns and the current state of their assets, up front, without wading through technical detail.

Three Roles in One Product

The platform had three kinds of users: investors, portfolio managers, and admins. They were arranged in layers.

Admins oversee managers, managers oversee the portfolio persons under them, and there is the investor themself. Each level sees less than the one above it.

Showing the wrong data or controls to the wrong role could cause real financial and operational damage. This is beacuse the platform directly affects revenue, so it had to be reliable both in how it worked and in how it looked.

I didn't have access to the real users, so I sketched three general archetypes to keep each role's needs in front of me while designing.

User Journeys

The real user flows are under NDA, so here's the simpler picture.

I used them as a mood check while designing. For every screen, I asked one simple question: will this leave someone calmer, or more annoyed, than when they arrived?

Design Process

The CTO gave me a set of wireframes and a large amount of data to display. Both were confidential and messy.

A wrong chart for a metric is enough to leave someone confused about their own investment.

My job was deciding how to present each one so a user would know exactly what they were reading.

Trimming the Brief Down

Because the client's wireframes were rough, I worked backward.

For each page, I pulled out just a list of the metrics that had to be there and ignored how they were laid out. That gave me a clear view of how the pages related to each other.

Only then did I make a rough wireframe of where each piece of information would go.

Moodboard

The client gave me a reference too. It's not the best one, but I understood what they meant, and the skeleton they were after was clear.

So I made my own moodboard from real visual references, and I used it to search for something specific: information hierarchy and placement.

Choosing Shadcn (and What I Gave Up)

Given the deadline and the reliability requirements, we chose an existing component library over building our own.

After discussing it with the client, we went with Shadcn for its broad set of components, its predictable patterns, and its documentation, which would make handoff smoother for developers.

Filling the Gaps with Custom Components

Shadcn is comprehensive, but some metrics were better shown in a different way. So I made custom cards and layouts for those metrics.

Designing the Dashboard

The dashboard homepage had eight metrics to show. Showing all eight as cards would have been overwhelming.

I put the most important numbers in the top left, because its where people look first. Then its followed by the other three metrics.

For rest of the metrics i put them on a tabs view for 2 reason.

These metrics are important so i need to make them big.

Second, showing them all at once would be overwhelming, so i implement tabs as a means for progressive disclosure.

The idea was to show only what's needed at first glance and let people reveal more when they want it.

Small Trend Graphs Inside the Cards

The standard Shadcn metric card only shows a name, a value, and the change since last month. That's not enough for investing.

"Up 20% from last month" only compares two points in time. It doesn't show what happened in between.

That number could be a steady climb, or a sharp spike followed by two weeks of decline, and the card would look the same in both cases.

To solve that, I added a small trend graph inside each card. It's just a glimpse and not a full chart, so it still fits in the same space.

Filters That Remember

I added a recently used time range filter, so someone who tracks the same date range every time doesn't have to pick the dates again. This reduce usage friction.

Designing Around Roles

Because admins have more access than everyone else, I built from the bottom up.

I started with the investor view, which is safe for everyone, and only then layered the admin capabilities on top. That way, nothing sensitive could slip into the base experience.

Corrections That Leave a Trail

Data entry isn't perfect, so admins need to correct data manually, but that's an intrusive operation. And the platform needed to be transparent about it . The edited event also need to be stored in detail for tracking purposes.

To solve that i make a mecahnism that indicate if a metric was edited, along with a link to the event detail.

Assigning Assets

Unassigned portfolios can't operate properly, so I wanted assigning them to be fast. But showing every unassigned folio is overwhelming to the user.

So i came up with a persistent notice that shows the two most recent unassigned portfolios.

This allow for quick assigning without cluttering the UI.

Dark Mode and Screen Sizes

I designed dark mode along with tablet and mobile layouts. On tablet, the sidebar mostly just collapses.

On mobile, the dashboard is completely different, because many investors wanted to check their assets from their phones.

Prototype and Feedback

For the prototype I used Figma's built-in features, which kept everything in one tool and saved time.

Feedback

The first version wasn't perfect. Feedback came from the investor relations manager, who presented the designs to real stakeholders and investors and came back with what they said. Here's a couple notable things that were changed.

A missing column

I left out a column in the investor's asset table that I thought was minor since they all held the same value at the time. Turns out it they still need the column for further expansion later.

Search bar

I added a general search at the top, and it was removed because it only search for something general and no specific data set. That kind of general search are costly to implement and yield no significant gain.

Instead we implement a search for only specific table which is much cost effective and beneficial to implement.

Shipment tracking

At first I made it very simple, just a timestamp and a shipped date. After feedback, they wanted predefined messages, like a clear statement that an item has shipped to certain location. This gives more reasurrance to user about their part shipment process.

Result

The portal was delivered on time, and the handoff to developers went smoothly.

In total its about 15 primary screens for investors, and around 64 for the admin panel once you count edge cases, forms, and validations.

All of it came in dark mode, with tablet and mobile breakpoint as well.

The client also kept working with me. It led to about two more projects afterward, and the CTO told me himself that they trust me. This is a large company, and that meant a lot to me.

Reflection

Looking back, im proud the collaboration turned out the way it is.

The investor relations manager understands how investors think in business terms. And I understand how users consume information.

What I Would Do Differently

I couldn't see how the feedback was gathered. Feedback reached me through the investor relations manager, who presented the designs to stakeholders and investors and came back with what they said.

He's smart, and I'm not doubting him, but interpretation can drift. Next time, I'd ask for real quotes, or at least a written summary of what came out of his presentations

Conclusion

This project taught me that my value wasn't in deciding what the data was. It was in deciding how to show it, so that a user could understand something complicated in a glance.