Implemented during the internship
Overview and task-based navigation.
I delivered Today's overview and the adjacent navigation that groups daily monitoring, reconciliation and reporting tasks.
Work experienceInternal tool · Company of about 30 · 2025
VortexNet:
Finance dashboard.
Bringing daily finance information into focus through clearer hierarchy and task-based grouping.
- My scope
- Information hierarchy and consolidation for Today's overview and its task-based navigation.
- Implemented
- Today's overview and the adjacent sidebar navigation, tested inside the company and shipped during the internship.
- Shown here
- Three stages side by side: the original tool, the build that shipped and was tested, and a later refinement made for this case study.
- Result
- In task-based testing with 10 colleagues, locating a day's work dropped from 20–30 seconds to about 8.
The redesign
A starting point for daily decisions.
The dashboard connects a cash summary, settlement progress and a prioritized work queue. Each view supports a different daily decision. Use the toggle to separate what shipped from what was refined later.
Outside my implemented scope
Downstream workflows.
The destination pages and their end-to-end workflows are not presented here as work I implemented.
Refined afterward
Data clarity and action detail.
For this case study I later refined the metric definitions, cash chart, settlement schedule, owners and next actions, keeping the tool's test data. That version is the third toggle above, and none of it was part of what was tested.
Cash movement
A trend compares incoming and outgoing funds over the same period, with a shared currency and scale.
Settlement progress
Batch completion sits beside the pending amounts and their cutoff times, making the next deadline visible.
Needs attention
A short queue connects each exception to its priority, owner and next action.
VortexNet is a company of about 30 people, and this dashboard is where its operations and finance teams start the day. The overview and navigation were tested with 10 colleagues before they shipped; the results follow below. The internal tool itself cannot be shown, so all three screens are reconstructions drawn from recollection and filled with the tool's test data - the shipped one is the delivered scope as it went live, without the later refinements. The counts above describe the delivered structure rather than usage analytics.
User testing
Faster to the day's work, on the same tasks.
Task-based sessions with 10 colleagues at the company compared the original interface with the build that shipped - the second toggle above - on the same tasks.
01
Testing everyday lookup tasks.
I tested the dashboard with ten colleagues who used the internal tool. I timed lookup tasks in the original and redesigned interfaces, including finding Pending settlement and locating Trend in the left-hand navigation. Participants were asked to locate a specified data item or section. Timing started when I gave the task instruction and ended when the participant opened the correct page. I checked that they had reached the intended destination before marking the task complete.
02
Recorded lookup times improved.
The recorded summaries showed that finding the day’s information took roughly 20–30 seconds in the original interface and about eight seconds in the redesign. Finding a requested item in the left-hand list fell from more than ten seconds to around five. These are approximate task-summary figures; some existing users initially took longer to find relocated items.
03
Trend understanding was an observation.
I also observed that participants appeared to grasp the overall data trend more quickly. This was a qualitative observation, separate from the timed lookup results.
The findings supported clearer labels, stronger typography and task-based grouping, with color as a supporting cue. Because these changes were introduced together, the results reflect the combined redesign rather than any single visual change.
The problem
Daily work competed with reports and administration.
The existing structure grouped information by document type. A morning check required interpreting the menu and metric labels before deciding where to go.
01
A flat menu mixed different jobs.
Fourteen entries put reports, operational queues and administration at the same level.
02
Labels reflected the system.
Abbreviations such as PEND_CNT required interpretation before someone could act.
03
The overview emphasized records.
A dense transaction table dominated the screen, without a dedicated list of items needing attention.
A decision changed by testing
From color contrast to a clearer reading order.
An early test changed my explanation of the problem and the direction of the next iteration.
01 · Initial hypothesis
Color could make priorities clearer.
The dashboard used similar colors and gave information similar visual weight. I first explored color changes to make the screen easier to scan.
02 · Early test
Color changes had limited impact.
The improvement I observed was limited, and feedback was mixed. I reconsidered whether the screen communicated what to read first.
03 · Revised decision
Build the hierarchy through type and layout.
I shifted to typography, text size and placement to establish clearer priorities. Color became a supporting cue within the hierarchy.
Explore a metric-hierarchy study
This reconstruction illustrates the shift in visual emphasis: primary figures lead, and supporting metrics follow.
Information consolidation
Organize around the work people arrive to do.
I used task-based questions to regroup the information, then worked through priorities with product and data.
Placement decision
Daily checks get the landing screen.
I asked colleagues what they checked first when starting their daily work. Their feedback shaped the priority model below and the order of information on the dashboard.
- Design trade-off
- Prioritizing monitoring gives periodic reports less prominence. Named reporting and admin groups keep those destinations available.
| Information | Team | Cadence | Placement |
|---|---|---|---|
| Awaiting settlement | Operations | Every morning | Landing screen |
| Failed items | Operations | Every morning | Landing screen |
| Reconciliation queue | Finance | Daily | Direct entry |
| Daily / monthly reports | Finance | Weekly | Reporting group |
| Accounts, permissions, logs | Data team | Occasional | Separate admin |
Information architecture
Three task groups. A separate admin entry.
The reconstructed navigation has nine main entries grouped by task. Accounts, permissions, configuration and logs sit under Admin.
Inspect the landing-screen hierarchy
Constraints & trade-offs
Designing within operational constraints.
Data freshness
Show when the data was updated.
The dashboard could not refresh continuously. After colleagues explained the update cycle, I added an “As of” timestamp so users could judge how current the figures were.
Team input
Let daily work set the order.
I asked users what they checked first each morning, then placed their highest-priority information at the top. The hierarchy reflected their working routine.
Navigation trade-off
Clearer groups, unfamiliar locations.
Existing users found top-level categories faster, but some initially took longer to find relocated items. One new hire, with little familiarity with the old menu, found items considerably faster in the redesign. I interpreted this as a possible adjustment cost; one employee cannot establish long-term adoption.
Next, I would follow returning users over time and consider familiar terminology or temporary navigation cues to ease the transition.