Employee Dossier

No brief. No research plan. Just the module.

The only direction was “redesign the Employee Dossier.” No user complaints were handed over, no support tickets were flagged, no specific pain points were pre-identified. So the first step was using the product myself, methodically, and documenting every point where I got stuck, confused, or had to guess. That self-directed audit surfaced the structural problems: the two-axis tab navigation, the ambiguous update button, the false save prompts, the visual noise from unnecessary scrollbars and inconsistent underlines. But auditing alone only reveals what’s broken. It doesn’t tell you what people have silently adapted to, or what they’ve given up trying to do.

Existing employees had adapted. New employees hadn’t. Both perspectives were necessary.

I spoke to coworkers across the company, deliberately splitting conversations between long-tenured employees and recent hires. The two groups surfaced completely different problems.

Long-tenured employees had internalized the dossier’s quirks. They couldn’t immediately point to issues because they’d stopped noticing them. Direct questions didn’t work. Instead, I asked specifics: “Do you know what this button does? Did it do what you expected? What does HR typically ask you to provide that should already be in your dossier? What did the employee dossier look like at companies you’ve worked at before?” Those questions broke through the familiarity and surfaced frustrations they’d stopped articulating.

Recent hires were the opposite. They hadn’t built workarounds yet, so every friction point was still visible. I gave them simple retrieval tasks and watched where they hesitated, where they looked first, and whether the information was where they expected it to be. The combination was critical. Tenured employees told me what the dossier failed to do over time. New employees told me what it failed to communicate on first contact.

The obvious solution broke against ZingHR’s product model.

The first design direction replaced the vertical tabs with a persistent left navigation menu that expanded on hover, and converted the sub-sections into horizontal tabs, each with its own dedicated “Update Details” button. This solved the original ambiguity about what the update button controlled.

My design manager and the implementation team manager flagged the fundamental flaw: ZingHR is a product-based company that customizes modules per client. Every buyer configures the dossier differently depending on their size, function, and requirements. Some clients need twelve sections. Others need four. Clients can also add custom fields to any section, meaning one company’s “Personal Details” tab might contain thirty fields while another’s contains three.

The tabbed layout I’d designed already occupied the full page width with a fixed set of tabs. There was no room to add more. And for clients with sparse configurations, a tab containing a single custom field would leave the rest of the page visually empty. The design solved the navigation problem for one hypothetical configuration but broke for the range of configurations ZingHR actually ships. That feedback killed the tabbed direction entirely. The next solution had to work for a dossier with four sections and a dossier with twenty, with no layout changes between them.

A conversation about LinkedIn profiles reframed the problem.

The connection came sideways. A colleague was updating his LinkedIn profile ahead of a job search and asked me for feedback on how to optimize it. That conversation surfaced something obvious in hindsight: a LinkedIn profile and an employee dossier are structurally the same thing. Both are single-person records with variable sections, each independently editable, designed to be scanned rather than read end to end.

I brought the idea to my design manager before exploring it further. She approved the direction, and the structural fit became clear immediately. LinkedIn’s profile pattern resolved every concern that killed the tabbed approach. Scalability was no longer constrained by tab count or page width. New sections simply extend the page, whether a client configures four or twenty. Sparse sections with a single custom field sit naturally in a scroll layout without leaving a screen of empty space. And the continuous scroll eliminated the cognitive overhead of switching between tabs to build a complete picture of an employee’s record.

The key design decision was treating LinkedIn as a structural reference, not a visual one. The layout pattern transferred. The information density, hierarchy, and edit interactions were designed for ZingHR’s specific content types, client configurations, and user permissions.