The brief flagged the hard parts. Just not the hardest one.

01.1 /

The project

Petco was moving their existing career site onto Radancy's platform. Although the project was primarily a rebuild rather than a redesign, the new site was scoped to include significantly fewer pages and I was also tasked with identifying and addressing existing UX issues along the way.

Most of this project seemed pretty straightforward, and based on the UX brief, two things looked like they'd be challenging: combining content from three existing pages into a single "Life @ Petco" page, and creating one CMS template flexible enough to build eleven pages.

Editability was a priority throughout the site and especially important for the template, so I generally avoided sliders, tabs and other interactive patterns that weren't editable or easily managed in the CMS. That tradeoff was reasonable: content the client cannot maintain will eventually stop being maintained.

Once the work started, the "Life @ Petco" consolidation turned out to be more manageable than expected, while the template was every bit as difficult as it looked. The surprise came elsewhere. A third problem, one the brief gave no indication of, only became apparent once I dove deeper into the existing page content. The way benefits information was originally presented made it difficult for job seekers to figure out which ones applied to their desired role.

01.2 /

Eleven pages, one template

The first big challenge was developing a single CMS template used to build eleven different pages. Ten were based on existing pages that didn't share the same structure, features or amount of content. The eleventh was new, with no content to reference.

I wanted to start with this wireframe because it was the hardest one. Establishing its patterns right away meant I could reuse them across the rest of the wires, but the bigger motivation was timing. Working through the most complex task early meant surfacing the bulk of my questions up front, and those answers could take a while to come back. Asking sooner meant a slow response wouldn't stall me, since I could move to easier tasks while I waited.

The Solutions Architect gave me a strong head start: an outline of the page sections needed, the baseline elements to account for and visual references for inspiration. Before designing against it, I wanted to familiarize myself with the existing content the brief was based on. That would help me determine which patterns would work best, verify the outline held up against what was really on those pages and look for opportunities to consolidate or reduce the number of sections proposed.

I decided to build a spreadsheet that mapped out the details the brief didn't capture. The mapping revealed that some content could be reconfigured to use a pattern already included in the outline, eliminating the need for one of the patterns it had proposed.

That same mapping also made clear where the template needed more flexibility. For example, the career area section had to hold anywhere from one to five items while staying visually balanced, so the layout rules had to adapt rather than assume a fixed count. I could have included a variety of possible options in the template, but then building a page would start with removing most of them. However, if I provided too few, the client would be stuck with a template that breaks the moment a page doesn't fit the mold.

01.3 /

The benefits problem

One of the bigger changes to the existing site was that the benefits page needed to become a reusable section that could appear across other relevant pages. This made sense because benefits matter to job seekers, and distributing that information contextually across the site meant they wouldn't have to go looking for it.

But leveraging the benefit page's content as-is wasn't an option. After taking a closer look, I found myself struggling to understand it.

From its six-bucket structure, I could tell that some benefits were for full-time veterinarians and some were for part-time roles, while the rest seemed to apply universally. But that raised more questions than it answered. If you landed a part-time role, did any of the other buckets apply to you? Since there was no callout specifically for full-time roles, was it safe to assume any unspecified buckets applied to them? I remember thinking that if someone who designs career sites for a living can't work out which benefits apply to which roles, the average person had no chance.

So I suggested we ask the client to clarify. It turned out most of the buckets applied only to full-time roles, one applied to all roles, one was only for part-time roles and one and a half were for full-time veterinarian roles. Better labels would have helped, but the structure seemed organized around keeping the content compact rather than making it easy to read.

01.4 /

Reorganizing around the reader

One thing you can safely assume is that job seekers already know what kind of role they're looking for. The benefit categories themselves were a reasonable way to group the information, but only some of them indicated which roles they applied to.

So it made more sense to present the benefits by role type at the top level with only the relevant categories nested underneath. Instead of mapping a role's benefits across six overlapping buckets, all you needed to know was whether you were full-time, part-time or a full-time veterinarian.

The tradeoff is that some benefits had to appear more than once, since several applied across all three role types. Repeating content isn't usually something you'd design toward. But the alternative was leaving every reader to work out their own answer, which is what the original benefits structure already did.

Initially I planned on just full-time and part-time groupings. But full-time veterinarians' benefits differed enough that folding them into the full-time grouping would have meant relying on exactly the kind of footnotes I was trying to eliminate, so they got their own.

01.5 /

The exception

There's a UX principle I start from on nearly every project. It's better to show content than hide it. Research consistently shows that hiding content behind an interaction reduces the chances of it being seen, creating the classic "out of sight, out of mind" problem. That doesn't mean I never hide content. I just make sure I can justify it before I do.

This approach worked well with one of the more challenging constraints of the CMS I was designing for: most interactive patterns were either very difficult or not possible to make editable. That meant when using one, any future changes had to be handled via a maintenance request rather than being something the client could handle themselves. This gave me two different reasons to avoid the same thing, both pointing in the same direction.

However, for the benefits section I chose to go the other way by utilizing the three role types as individual disclosures that expanded one at a time to reveal the selected option's benefits.

Three things made this an exception. The content went from living on its own page to a section that would live among other content across multiple pages, so keeping its height to a minimum needed to be considered. The hidden benefits content rarely changes, so the maintenance cost of using a non-editable section was low. And because each set was tailored to one role type, the only content that mattered to a given user was the one they chose.

After balancing those reasons against the impact of hiding content and losing CMS editability, I felt confident this was the right decision. A user who reached this section would clearly understand that this is where benefits information lived, be able to choose whichever role types they were interested in, and be presented only the content that applied to the role type they chose. Anything else would just be noise to them. And if a user wasn't interested in benefits information at that time, they could easily scroll past the section in one scroll or swipe.

The choice to use disclosures rather than an alternate interaction was deliberate. Tabs would require one of the three sets of benefits copy to be visible on page load, and can require other difficult UX and accessibility tradeoffs, especially on small screens. Similarly, modal windows, sliders and "read more" style interactions had their own pros and cons that just didn't compete with disclosures.

01.6 /

What shipped

In this workflow, wireframes came before official content existed. Their job was to give the client and the creative team a foundation that took the direction in the brief and balanced what the experience needed against what the platform could support. I designed them with the client's brand in mind, not to dictate the visual direction, but because clients typically have a hard time reading pure wireframes, and a little familiarity keeps the conversation on structure instead of styling. Once the wireframes were signed off on, official content was written and creative styling was applied. Shifts from my wires were expected, and major structural changes usually came back through me. The thing to look at is whether the structure survived.

For the benefits section, most of it did. Role type sits at the top level. The original categories are nested underneath. Shared benefits still repeat across the three role types, all three disclosures are collapsed on load, and full-time veterinarians kept their own grouping.

Two things did change that I wasn't aware of until I reviewed the live site post-launch.

My suggested "Full-Time Veterinarian Benefits" label was shortened to "Veterinary Benefits," which I felt added a small amount of ambiguity back to the experience. Without the full-time qualifier, a part-time veterinarian wouldn't know whether they receive those benefits or only the part-time ones.

The other change was a note added to the bottom of each expanded panel: "Benefits vary depending on role."

I don't know the reasoning behind it, but it's safe to assume it wasn't arbitrary. Benefit offerings change, and a line like that protects the company. But overall the structure does its job. That note is setting expectations rather than helping someone decipher what's in front of them.

01.7 /

Closing thoughts

The career area template is a good example of why Petco moved to Radancy's platform in the first place. Building pages from a CMS template does more than save time. It brings order to a set of pages that have drifted apart, which is what usually happens when pages get built and updated by different people over time. Each decision is reasonable on its own, but eventually the set stops looking like it belongs together. More importantly, a job seeker deciding whether to apply can read that inconsistency as a signal about what working there might be like.

Rebuilding the eleven pages individually would have carried the same inconsistencies forward. Instead, giving them one shared structure to follow made the gaps between pages visible and left Petco with something easier to maintain and extend.

The benefits section had originally been structured to present a robust set of offerings across multiple role types as efficiently as possible. That's a reasonable goal, but sometimes efficiency and the reader's experience pull in different directions. My solution traded some of the first for the second. It's harder to prove that it worked, since I don't have data on it. But it's reasonable to think a job seeker who can find their own answer, without wondering whether they've interpreted it correctly, is better off than one who finds out later in the hiring process. That lets someone apply with more confidence that they're making the right decision, and it means Petco has one less misinformed applicant to correct.