Project Overview
TL;DR: As part of a projekt202 team engaged on the FedEx Office Commercial account, this was a self-service Site Admin portal that let commercial print customers manage their own FedEx Office sites directly, instead of routing every change through a FedEx representative. The team validated it with eight real site admins and CTCs across three straight days of rapid iterative testing, shipping design changes overnight so each day's cohort tested a revised product, not the same one.
Role: Senior UX Designer, projekt202, engaged on the FedEx Office Commercial account. Focus: rapid iterative usability testing, the Site Admin portal, and the accessible component library it was built on.
The Challenge & Context
Commercial customers ordering print through FedEx Office, companies ranging from a handful of employees to enterprises with 500+, had no direct way to configure their own site. Adding or removing a user, restricting a delivery option, or changing branding meant routing the request through a FedEx representative or a CTC. Even the reference information admins needed most, like which permission level to assign someone, lived in a downloadable PDF instead of the product itself. Every change was a support ticket instead of a task an admin could do themselves.
The Process & Decision-Making
Eight admins, three days, one script
The team ran a rapid iterative testing methodology: eight participants across three one-hour sessions per day over three days, mixing current FedEx Commercial customers, recruited non-users who managed similar systems for their own companies, and CTCs who supported these accounts day to day. Sessions ran both in-person and remotely from projekt202's user testing lab, with each participant thinking aloud while role-playing a site admin setting up a brand-new commercial site end to end: 11 tasks total, from initial site creation through enabling the finished site for their team.
After each day's sessions, the team scored every task on a 1-to-5 ease-of-use scale and shipped design changes overnight, so the next day's cohort tested the revised version instead of the same one.
Simplicity versus configurability
The same tension surfaced across all three days: every single participant advocated for personalizing their site's URL, while locked, role-based UI states, delivery options an individual admin couldn't edit, for instance, caused real confusion about what was and wasn't in their control. One participant put it directly: "I don't like the lock. Do I have permission to change it?" Another wanted the URL editable outright: "I would like to personalize it. I would want the URL that they could easily remember."
Resolving that meant adding visual cues, like a lock icon and higher contrast on disabled controls, rather than just hiding the complexity, so admins could see the boundary instead of guessing at it. The same instinct applied to a proposed icon/avatar section: participants repeatedly couldn't identify where it would even appear ("I think it would be where the guy is," one guessed), so the team cut the section entirely rather than iterate on it further.
The Solution & Final Design
- Self-service Site Admin Dashboard. A single dashboard replacing rep-mediated setup, with dedicated sections for Site Basics, User Management, Delivery Options, Pricing & Payment, and Roles & Permissions; renamed from "Site Admin" to "Admin Dashboard" mid-validation after multiple participants described it that way unprompted.
- A live, in-product permission matrix. The role and permission reference that used to live in a static, downloadable PDF became a searchable table inside the product itself.
- Custom site creation with real URLs. New sites launch through a guided flow that removed internal user IDs from public-facing URLs and, in direct response to unanimous participant feedback, made the site's URL extension editable so a company's print site reflects its own brand instead of a generated string.
- Batch user management. CSV import for adding groups of users at once, inline permission editing, and a details page consolidating basic and contact information that had previously been split across two separate forms.
- Consolidated payment and billing. Credit card entry and billing address combined into a single step instead of a two-step flow that had been slowing participants down, plus a default payment method and custom billing reference fields for account-level billing needs.
An accessible, token-based design system underneath it
The portal was built on a documented, WCAG-tested color system. FedEx's signature orange, for example, only passes contrast requirements at large text sizes, so the team mapped it and the rest of the brand palette to accessible alternates for body copy and UI states.
That same standard fed a shared component library, buttons, form elements, selection controls, tags, product cards, and a configurator, reused across the admin portal, the print catalog, and checkout, plus a pinned-footer navigation pattern for the account switcher, so the same patterns behaved consistently everywhere a customer or admin encountered them.
Impact, Outcomes & Learnings
By the third day of testing, every one of the 11 core tasks scored above a 4 out of 5 on ease of use, the threshold the team considered strong; the lowest score across the entire study was a 4.17, on the final task, enabling the finished site. One participant summed up the bar the team was aiming for: "I'm not even a computer whiz, but it was easy enough for me, so I feel like if I can do it, pretty much anyone can."
Individual design changes tied directly back to what the team saw in sessions: removing the icon/avatar section entirely, cutting an address field from the site contact form that testers called unnecessary, and adding a lock icon with higher contrast to locked delivery settings after early participants mistook them for a bug rather than a permission boundary. The validation didn't just improve the shipped product, it set the agenda for the next round: pricing and payment accounts, groups and roles, document and print settings, and login and self-registration all moved into Validation #2 because this round showed exactly where the open questions were.
Reflection: Running the same 11-task script for three straight days, with real design changes shipped overnight between cohorts, showed the value of treating validation as a conversation instead of a single readout. A design decision that looked settled on day one could still fail with day two's participants, and the only way to know was to test the revision live rather than wait for a final report. It also sharpened how permission boundaries should be designed: making a locked control look disabled isn't enough. Admins need to see and understand why it's locked, a small but real difference between a control that reads as broken and one that reads as intentional.