Nike Global HR Website

The Problem

One policy search on the old HR site returned six paginated pages of results, every country, language, and category mixed into one list, with no way to narrow it down. That was the front door. HR content, tools, and answers were scattered across a sprawl of sites and SharePoint pages, with no single place that felt authoritative. "A lot of Nike platforms you need to click through a lot to get to what you need and it opens so many windows, which is maddening," one WHQ employee told the research. The research surfaced the same workaround: people stopped trusting the site and asked a person instead, turning a tool built to answer at scale into one-at-a-time human help.

The Case I Made, and the Work I Owed Anyway

The platform was not the one we recommended, or anywhere near the top of the list. The team had done the research, and engineering, design, the employees we tested, and the evidence all pointed the same way: away from a ticketing tool as the foundation for a site 86,000 people use. I brought that case, and a set of options, to the VP of Global HR Strategy and Chief of Staff to Nike's Chief Human Resources Officer. He agreed. The direction we chose was an in-house experience layer that would sit on top of whatever vendor ran the services beneath it and unify the whole thing, one interface, one design system, one set of data integrations, built from the reusable components and services we were already standing up across Enterprise Search, the Time Off app, and the other platforms. We had started building the prototype.

A few weeks in, the decision was taken out of our hands. A mandate came down from above the team to build on a platform that had not made our shortlist, chosen for reasons that had little to do with the people who would use it. The backend became ServiceNow, wired in through one of the big consulting firms, with hard, fixed limits that would not bend. I disagreed with the call then, and I still do.

So we set out to make the mandated platform serve people as well as it possibly could. We took a system that was never built to be a consumer web experience and worked to make it navigable, manageable, logically organized, on-brand, and as close to a real digital employee experience as we could get it, inside constraints set by both the implementation vendor and the stakeholders who held the decisions. I built much of the front-end myself, the HTML, CSS, and JS, rather than send every small change through a vendor change order, and designed hard around the limits instead of pretending they were not there.

I will be straight about the ceiling. Design does not hide the system underneath it, and here it sometimes made the gap sharper rather than softer: a polished front door sets the expectation of a modern web app, and when the platform cannot meet that expectation, people feel the shortfall more keenly, not less. What we could control was refusing to treat the constraint as an excuse, and getting the experience as far as it would go inside the box we were handed. That is the honest scope of the win, and I am proud of how far we pushed it.

This was one of four enterprise platforms I led at Nike through COVID, alongside Enterprise Search, Onboarding, and the Global LMS, for a workforce of 86,000. On this one we owned the digital design and experience, as much as the box allowed: the information architecture, the two rounds of employee research behind it, the component and journey system, and the accessibility and brand standards we held it to. Those standards came from the Human Design System, the internal Nike HR digital design system I had established, and we met them as far as the platform would let us. Sergio Slansky worked alongside me on the UI and the UX. The build itself we ran cross-functionally with a large team from one of the big consulting firms, who engineered the platform underneath. Those two rounds of research ran in sequence: a generative concept test to set the front door's character, then an evaluative navigation test to validate the structure beneath it.

The front door is where that landed. An employee is greeted by name, "Hi [name]! How can Nike HR help?", with one search across all of HR and their own tools a tap away: The Source, Total Rewards, Time Off. Underneath it sits the full content system: benefits explained plainly, a personal dashboard, Health and Wellness, Community, and, when something is wrong, a clear path to Speak Up.

We wanted the language to change as much as the layout. HR writing had drifted into jargon, corporate boilerplate, and legalese, and we worked to pull it back into something a person could actually read: more personable, relatable, and conversational, with as much of the legalese stripped out as we could manage. The rule we held to was simple, speak to employees the way any of us would want to be spoken to, not talk down to them. Explaining a benefit plainly was a stance, not a nicety.

Early concepts got tested with real employees before any of it shipped, and personalization was what they reached for: bookmarking and a personal dashboard, the tools that let someone make HR their own ("I feel like a member of HR now. I feel included, like maybe HR cares for me," one participant said). That same testing is also where the case for restraint came from, which is why the shipped site favors what a person deliberately chose over what a system guessed.

Testing Four Directions

The study behind that finding was a moderated concept test, run in January 2020, and it did not start from scratch. It stood on three years of prior research into the HR website: its structure and content, how people actually found what they needed, and which tools and integrations were the most used and the most useful. We pulled in as much of that as the constraints would let us. The test put four possible directions for the HR front door in front of real employees: Personalization, Search, Exploration, and Timing, each built as its own clickable prototype. Testing them one at a time let people react to a single idea instead of a finished site.

Each direction came back as its own board of unfiltered reaction, dozens of verbatim quotes in all.

The work was reading those boards down. For each direction we distilled the raw voice into one main takeaway and the few findings beneath it, turning dozens of loose quotes into a decision we could defend.

The readout came back with one finding well ahead of the rest: personalization, and above all the plain ability to bookmark and save your own tools, the clear winner of the four directions. Search came back as table stakes, "just a function, not what Nike HR stands for," as one person in EHQ put it, useful as a backup but not the thing an HR site should lead with. Exploration, showing employees new or highlighted HR topics, was welcomed but never a priority for the HR site itself; people said that kind of content could just as easily live outside it. And timely content mattered, but only at specific moments in the year, and only up to a point: the closer HR guessed at what was happening in someone's life, the faster 'helpful' turned to 'creepy.'

One of those takeaways was quietly an accessibility decision: employees wanted the same HR topic offered in more than one format, and the reason was who had to read it. Someone checking a policy on their phone between tasks needs the quick facts, someone at a desk can take the ten-minute read, and one page has to serve both. The tested Time Off page put all three on a single screen, quick facts, a short "How it works," and a longer read stacked in order of depth.

What made the study worth trusting was who it reached. Every quote was attributed by site and org, never by name: WHQ and CHQ in the US, EHQ in Europe, APLA and Taiwan across Asia Pacific, an Arizona distribution center, AirMI, Converse, Berlin Accounting, NA Retail. That spread is what surfaced problems a headquarters-only test would have missed, like employees on a retail floor or in a distribution center who count on a manager, not a website, for time-sensitive dates.

We could reach that many kinds of people, that fast, because we had built the Experience Insiders platform on the HR Service Innovation team: a standing panel of more than 800 Nike teammates across geographies, locales, and roles that we could tap the moment a piece of research or a prototype was ready to run.

Choosing Restraint Over a Feature That Could Hurt People

Personalization, the winning direction, was also where the sharpest caution came from. The tested home greeted a persona, "Welcome, Janet!", with her own tools and a saved list of favorites. Directly beneath her bookmarked Maternity Leave, an automated "You might also like:" row suggested Paternity Leave. An employee flagged it on the spot as a hazard for a single mother, and they were right: a system that volunteers Paternity Leave there is not helping, it is guessing at her life and getting it wrong in the most personal way it could. I left that slide in the deck exactly as it tested.

So we refused to crown a single winner. The recommendation was to combine all four directions, and that is what shipped, each with a human hand kept on it: the greeting and saved tools from personalization, the "Search HR" bar kept as a backup rather than the headline, a Featured row for timely items like the year-end process, and content cards mixed by length underneath.

The full readout, all 26 slides, is the interactive deck near the top of this page.

Designing the Way In

The January study settled the front door's character. What it had not settled was the structure beneath it: how an employee would actually move from the home to the one page they needed. The sprawl in the problem was really a navigation problem: too many places to look, and no structure a person could predict. So before the homepage or a single content page, the navigation had to be settled, and I tested it before it was built.

In April 2020 I ran a comparative navigation study with a fellow product designer. I collapsed the old sprawl into four plain-language categories: Pay and Benefits, Time and Vacation, Career, and Policies and Forms. Then I built a set of interactive prototypes in InVision that opened those categories in different ways. Three of them went into a task-based test: a menu that slides down from the top, a drawer that slides in from the left, and a full-page overlay. Each one handed a participant the same honest task, find the pages under Employee Discounts, then asked how easy it felt. Nineteen employees ran the task on all three and ranked the three against each other, rating how easy each one felt, so every pattern came back with two signals: how easy people found the task, and how they ranked it against the other two.

The menu that slides down from the top won the ranking outright, and it held up on the task itself: about 89% of participants, 17 of the 19, rated finding Employee Discounts easy or very easy. A category opened right under the top bar, where people expected to find it, so they could zero in on one area instead of scanning the whole site. That was the pattern to build on.

The winning pattern still had a flaw the test exposed. Opening a category poured every page in that area onto the screen at once, and testers said so: "too much information displayed in the secondary menu, felt overwhelming and I wasn't sure where to start reading," one wrote. The fix defined the shipped design: group those pages into a short list and let people drill in, rather than dumping the whole area onto one screen. Testing did not just pick a winner, it corrected the winner, and that restraint, a short grouped menu instead of a wall of links, turned out to be the whole point.

The ranking held up because the two runners-up each aced one measure and failed the other. The left-hand drawer read as clean, and a few people liked its role-based Manager and HR sections, so it ranked second overall, but it was the worst on the actual task: under half rated finding Employee Discounts easy (9 of 19), and 3 of the 19 found it very difficult. It cost an extra click and tripped up anyone not expecting a hamburger menu on a desktop HR site. "Older customers might not be accustomed to hamburger menu types," one participant said flatly.

The full-page overlay was the mirror image. It tied the winner on the task, 16 of 18 found Employee Discounts easily, a base one short of the other two patterns, yet it ranked last because it felt bland and visually noisy. "Many font sizes and weights, horizontal and vertical searching at the same time. I found myself looking all over the place," one wrote, and another called it "too similar to what we're doing on Dot Com." Task success alone would not have separated the overlay from the winner. Preference and visual load did, and that is the call the study let me make on evidence instead of taste.

What This One Taught Me

This is the project that made me realize just how highly I value certain leadership, product, and design principles, and it surfaced the truth of them to me the hard way. I made the case, backed by the research and by engineering and design, and my leadership agreed with it. Then the direction was overridden from higher up. I committed to the outcome and did the best work I could inside it, because walking away was never the honest option: real people would live with this decision, and someone has to stay and advocate for them. I still disagree with the decisions made, and faced with the same situation again, I'd make the same case I made back then to today's executive leadership.

The principles have outlasted the project. Build for the people who have to live in the product, not the ones who administer it. When an organization spends real money on something employees lean on at defining moments - a leave, an enrollment, a hard conversation - the job is to build the right thing and then build it right, not "good enough" to tick the box. I hold my design convictions because I believe them, not because a method told me to, and the best calls stay close to the work and the people it serves. When the evidence, the engineers, the designers, and the people all point one way, that is a case worth making in full and standing behind. Even after a decision made from afar flies in the face of your convictions. Committing to a call you argued against is not the same as agreeing with it. You commit because a step forward can beat standing still, and because the people that your product, design, or strategy serves deserve your best effort to surface their voices and to advocate for their experience regardless of the constraints.

Impact

The six paginated pages of mixed results became a single, search-first front door, and the wall of duplicated tools collapsed into one predictable, grouped home: one authoritative place for HR, in place of a scatter of sites and SharePoint pages. It was built to belong to the same family as the connected application ecosystem we had shipped before it, and that is what brought a third-party platform closer to the experience Nike employees expect and hope for than a generic install ever would have delivered.

What shipped was validated before launch, not tracked long after it. The navigation that won cleared its task for about 89% of the employees who tried it (17 of 19), and we were able to deliver some of it. This was a COVID-era build; the reorgs of that period moved teams and priorities on before anyone followed adoption end to end, so the site-level payoff was never fully measured.

What testing did buy was restraint: no algorithmic "you might also like" guessing at an employee's life, and a short grouped menu to drill into instead of a wall of links. The repeatable capability underneath is worth naming: take organizational sprawl, six-page search results and endless SharePoint, and reduce it to a structure a distribution-center employee can navigate on the first try. The real deliverable was never the feature list. It was one place an employee could trust, and it earned that by choosing not to guess at them.