A redesigned internal review platform to eliminate the 5-tab nightmare reviewers endured every recruitment cycle. I defined the problem, drove the direction, and pushed toward simplicity.
Application Review Flow
IA
Interaction Design
Platform
Desktop Website
Timeline
Mar 2025 – Jun 2025
Team
Madison Plotkin
Johnny Tiangco
Hillary Co
Angelica Arguilla
Background
Fulcrum was a TSE's internal review platform built by developers, which causes it to lack visual interest, user-friendliness, and intuitiveness. To complete a single review, members juggled five separate tabs: Fulcrum, the applicant's resume, scoring rubric, a calculator, and their portfolio. The workflow wasn't a flow. It was an infinite loop: open Fulcrum → switch tab → back to Fulcrum → switch again, repeated across dozens of applicants.
Result: Reviewers spent more time navigating than evaluating. Reviewer agreement sat at just 50%.
When I audited the platform, there was no clear problem statement, just complaints. And so, a question was brought up…
How might we help reviewers evaluate multiple applications efficiently without cognitive overload?
Key issues with the current interface:
As a result, reviewers spent more time parsing information than evaluating candidates.
Design Objectives
Reduce cognitive load during high-volume application review
Improve information hierarchy so reviewers can scan, not search
Surface review actions such as scoring, reassignment without hunting
Support evaluation consistency across all reviewers
Understanding Users
Users
There is one thing I always kept in mind: reviewers are both TSE designers and developers, who use Fulcrum only during recruitment season. They're not "power" users. They open the platform, work through a batch of applicants, and close it. The interface needed to hold up on application 1 and application 40+.
I conducted 2 in-depth interviews and synthesized findings across 8 total interviews conducted by the team: a balanced mix of designers and developers. I identified two patterns that shaped every decision after.
When I asked whether there was anything worth keeping from the current platform, one reviewer didn't hesitate:
"Nope, I hate everything about it 😊"
That told me everything. This was a full rethink. I fortunately made that call early and it shaped the entire project direction.
Competitive Analysis
Most review tools unfortunately sit behind paywalls. Therefore, I had to work through constraints by reconstructing flows from demo videos, walkthroughs, and public documentation, including identifying patterns worth adopting and, more importantly, ones worth rejecting.
Patterns I adopted:
Modular layouts for scannable, chunked information
Separated reading and action zones to reduce context switching
Progressive disclosure; secondary details available, not default
What I ruled out: The team gravitated toward a dashboard aesthetic, things as bento grids and data visualizations. I however pushed back. Fulcrum's data is a list of applicants and aggregate numbers. Imposing a dashboard layout without data to visualize would've been unclear. I chose table and list structures: they are familiar, fit better to the information we work with, and faster to scan.
Design Direction
Guiding Principle
Reduce cognitive load so reviewers focus on evaluating candidates, not navigating the interface.
I set this principle and held it. Every feature request got filtered through one question: does this help a reviewer make a better decision? If not, it will not make it in.
Before: Fulcrum → tab → back to Fulcrum → another tab → repeat. Five tabs, one applicant, infinite context switching.
After: Everything inside Fulcrum. Select applicant → read → score → next. Most interactions never leave the page.
Exploring the Experience
Low-fidelity
I focused on information order before visual detail, what does a reviewer need to see, and in what sequence, to feel confident making a decision? I explored list, table, and block layouts, choosing based on two things: consistency across pages so reviewers never have to reorient and alignment with familiar patterns so the interface felt immediate, not "learned".
Mid-Fidelity Iterations
I worked through three decisions:
Where do scoring actions live relative to the content being scored?
How much information should be visible without scrolling?
What visual weight separates section headers from body content?
Each round was shared with teammates for feedback before moving forward.
Usability Testing
I tested with 2 participants directly and synthesized notes from 6–8 total sessions run by the team, the same mix of designers and developers from the interview phase.
What came back:
“I want to see notes immediately — I don’t want an extra click.”
— Designer
Viewing/adding notes were behind a button. Imagine…. 1 extra click, multiplied across 30+ applications, breaks review rhythm fast.
A harder piece of feedback: reviewers wanted scoring at the top for quick access. I understood the instinct, but chose to dive deeper rather than simply accepting it. Fulcrum assigns two reviewers per applicant who then compare scores independently. Putting a score at the top risked anchoring bias; reviewers would evaluate against someone else's judgment, not their own. I built a version with scoring at the top, confirmed the concern was real, and held my original placement, which is placing score near the complete review button, after the reviewer has worked through the application.
Not everyone agreed immediately tho. I held the position because the evaluation process needs it.
Final Design
The final design collapses a 5-tab workflow into a single structured view:
Unified applicant view — resume, portfolio, and materials on one screen. No tab switching.
Persistent scoring panel — anchored as reviewers scroll through longer responses
Notes visible by default — the extra click cost more than the clutter it prevented
Score placement — input fields anchored near the complete review button to protect independent evaluation; combined scores surface at the top only after both reviewers submit
Consistent layout across all applicants — same structure every time, no reorienting
Impact
Reviewer agreement rose from 50% to ~75% — clearer hierarchy directly reduced evaluation inconsistency
Review time estimated at ~5 minutes per application, down from a 5-tab, context-switching workflow
100% of participating members preferred the redesign over the previous version
The most meaningful outcome wasn't speed; it was consistency. When the interface stops creating more friction, reviewers can finally make thoughtful judgments.
What I've Learned
I've learned that iterative design sometimes means dive deeper into what users say they want. Reviewers asked for scoring at the top. I understood why, explored it seriously, and push back because independent evaluation mattered more than the feeling of quick access, in this case of course.
I also learned that users in the same user group doesn't mean they are the "similar". They can have the same role, but completely different mental models. Designing for that means building structure flexible enough to support different approaches, not averaging them.
Fulcrum transforms application review into a clear, efficient workflow that enables reviewers to focus on making right decisions.
Explore the Prototype here
