Petco Careers

01.1 /

The project

Petco was moving its existing career site onto Radancy's platform. The project was primarily a rebuild rather than a redesign, but the new site would include significantly fewer pages, and I was also responsible for identifying and addressing existing UX issues.

Most of the project looked straightforward, and the UX brief pointed to two likely challenges. One involved combining content from three existing pages into a single "Life @ Petco" page, while the other was creating one CMS template flexible enough to build eleven pages.

Editability was also a priority, particularly for the shared template, so I generally favored patterns the client could manage directly in the CMS.

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 when I reviewed the existing content and found a third problem the brief hadn't surfaced. The existing benefits structure made it difficult for job seekers to tell which benefits applied to the roles they were considering.

01.2 /

Eleven pages, one template

The CMS template had to support eleven pages, ten of which 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 started with this wireframe because it looked like the most challenging part of the project. Establishing its patterns early meant I could reuse them across the rest of the work, and tackling it first would likely surface the bulk of my questions up front. Since some answers could take time to come back, asking sooner meant I could move to easier tasks while I waited rather than letting a slow response stall the project.

The Solutions Architect gave me a strong head start with an outline of the sections needed, the baseline elements to account for and visual references for inspiration. Before designing against it, I reviewed the existing pages to see how well that outline held up against the actual content and where sections could be consolidated.

I mapped those details in a spreadsheet, which showed that some content could be reconfigured to use a pattern already included in the outline. That eliminated the need for one of the patterns originally proposed.

That same mapping also showed where the template needed more flexibility. The brief anticipated career area sections ranging from three to eight items, but my review of the existing pages showed two distinct needs. Four pages had just one career area, which could use an existing pattern already included in the template, while the remaining sections contained three to five career areas and required a separate pattern.

Because the platform allowed patterns to be duplicated, pages with three or four career areas could utilize a single instance of a four-item pattern, while the only page with five could use two instances, with three items in the first and two in the second. That avoided leaving a single career area stranded on its own row without having to fill the template with pattern variations most pages wouldn't need.

01.3 /

The benefits problem

One of the bigger changes to the existing site was turning the benefits page into a reusable section that could be distributed across multiple relevant pages. That made sense because benefits matter to job seekers, and placing that information where it was most useful meant they wouldn't have to go looking for it.

But the existing benefits content couldn't simply be reused as-is. After taking a closer look, I found myself struggling to understand it.

From its original 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 still left basic questions unanswered. For example, if you landed a part-time role, did any of the other benefits apply to you? Since the only grouping that identified itself as full-time was specific to veterinarians, was it safe to assume the unspecified benefits applied to other full-time roles?

I remember thinking that if someone who designs career sites for a living couldn't confidently work out which benefits applied to which roles, how could a job seeker be expected to?

So I suggested we ask the client to clarify. Most of the buckets turned out to apply only to full-time roles, one applied to all roles, one was specific to part-time roles, and one bucket plus part of another applied only to full-time veterinarians. Better labels would have helped, but the larger problem was the structure itself. It seemed organized around keeping the content compact rather than helping job seekers understand what applied to them.

01.4 /

Reorganizing around the reader

Job seekers generally come to a career site knowing what kind of role they're looking for, so I used that as the starting point for reorganizing the benefit information. While the existing buckets still had value, I made role type the top-level structure and nested only the relevant categories underneath. Instead of leaving job seekers to map out their 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 was that some benefits had to appear more than once because several applied across all three role types. Repeating content isn't usually something you'd design toward, but in this case the alternative was leaving every job seeker to work out their own answer, which is what the original structure had already done.

I initially planned on just full-time and part-time groupings, but the benefits for full-time veterinarians differed enough that combining them with the other full-time roles would have meant relying on exactly the kind of footnotes I was trying to eliminate. They needed their own grouping.

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. Usability research has repeatedly shown that content hidden behind an interaction can be easier to overlook, introducing the classic "out of sight, out of mind" effect. That doesn't mean I never hide content, but I only do it when the tradeoff is justified.

That principle also aligned with one of the constraints of the CMS I was designing for. Most interactive patterns were difficult or impossible to make editable, which meant future changes would require a maintenance request instead of something the client could handle directly.

For the benefits section, I chose to make an exception by using the three role types as accordion sections, each expanding to reveal the benefits for that role type.

Several factors supported that decision. The benefits were moving from their own page into a section that would live among other content across multiple pages, where they wouldn't necessarily be the primary focus. Keeping the section compact helped prevent it from overwhelming the rest of the page. The hidden content changed infrequently, which kept the maintenance cost low, and most users would only want to see the benefits associated with the role types they were interested in.

The result was a more compact section that still made benefits easy to find when someone wanted them. Job seekers could expand the role type that mattered to them and ignore the rest, while anyone who wasn't interested in benefits could move past the section easily.

The choice to use an accordion over other interaction patterns was also deliberate. Tabs would have required one of the three sets of benefits to be visible on page load and introduced additional UX and accessibility tradeoffs, especially on small screens. Modals, sliders and "read more" interactions came with their own drawbacks, while an accordion gave users a simple way to reveal only the content relevant to them.

01.6 /

What shipped

On this project, wireframes came before official content and creative styling. Their job was to give the client and creative team a foundation that balanced the direction in the brief, what the experience needed and what the platform could support. I designed them with the client's brand in mind because a little familiarity made the wires easier to read and helped keep the conversation focused on structure rather than styling.

Once the wireframes were approved, some changes were expected as final content and visual design were applied. Major structural changes, however, typically came back through me. What mattered was whether the underlying structure survived.

For the benefits section, most of it did. Role type remained the top-level structure, with the relevant original categories nested underneath. Shared benefits still repeated across the three role types, all three accordion sections were collapsed on load and a separate veterinarian grouping remained.

Two things had changed by the time I reviewed the live site post-launch. My suggested "Full-Time Veterinarian Benefits" label had been shortened to "Veterinary Benefits," which added some ambiguity back into the experience. Without a full- or part-time qualifier, it was no longer clear whether that grouping was still intended only for full-time veterinarians or for veterinarians more broadly.

The other change was a note at the bottom of each expanded panel that read, "Benefits vary depending on role." I wasn't involved in that decision, so I don't know the reasoning behind it. It may have been intended as a safeguard for future changes to benefit offerings or to account for additional variation within the role groupings. Either way, the underlying structure still does its job. The note adds a caveat, but the role-based structure still gives users a much clearer starting point than the original six overlapping buckets.

01.7 /

Closing thoughts

Building the eleven pages from one CMS template did more than make them easier to maintain. It gave pages that had drifted apart a shared structure to start from, made gaps and inconsistencies easier to spot, and left Petco with a system that could extend more cleanly over time.

The benefits problem was more of a balancing act. The original structure presented a broad set of offerings compactly and efficiently, but sometimes efficiency and user clarity pull in different directions. Designing within platform constraints and established best practices is important, but sometimes the better solution requires making a justifiable tradeoff.

It's harder to prove that my solution was a major improvement since I don't have data on it. But it's reasonable to think that showing job seekers the benefits associated with the role type they select is better than leaving them to untangle six overlapping buckets themselves. And doing so should help a job seeker apply with more confidence that they're making the right decision, while reducing the chance that Petco has to correct a misinformed applicant later.