Case studies/HP Managed Print Central

HP Managed Print Central: one lifecycle, two products

HP's managed print business sells and runs print fleets for large companies. The journey from first opportunity to active contract was spread across spreadsheets, email and separate portals. I worked on Managed Print Central, two connected platforms: one for sales (PMPS) and one for running contracts (CMPS). The application was always live, so I designed enhancements in Axure RP that were tested before handoff and then released into it.

B2B · enterpriseStrategic trade-offsShared componentsFigma ↔ code
Client
HP Inc. via Wipro
Role
Senior UX designer
Timeline
Oct 2022 – Apr 2023
Tools
Figma, Axure RP, Draw.io, HP Veneer
The problem

Sales reps and contract managers worked across spreadsheets, email and separate portals.

What I did

Interviews with three roles, a requirements matrix, and enhancements to both platforms, designed in Axure RP from one shared set of components that matched the coded components.

Result

Each change went through QA testing with the BA and the team before handoff, then was released into the live application.

Research

Three roles pulling in different directions

I interviewed HP sales reps, contract managers and their managers to map how work actually moved. I listed every tool being replaced and built a requirements matrix that tied each user need to a feature, which became the shared checklist for product and engineering.

Stakeholder interviewsCurrent-tool inventoryRequirements matrixSite map in Draw.ioPrototype reviews
What we heard
Sales reps tracked opportunities in personal spreadsheets, so nobody could see which proposals were live.
What it changedA shared opportunities list with Create / Existing / Archived tabs.
What we heard
Contract managers logged into several systems just to check a shipment.
What it changedCMPS brings fleet, shipment and supply status into one place.
What we heard
Managers couldn't see their team's pipeline until someone sent a report.
What it changedDashboard widgets for proposals by status, visible to managers.
Strategic trade-offs

The biggest decision was structural

One tool or two?

OptionOne large app with every module
ChosenTwo platforms (sales and contracts) with a shared entry point and an Onboarding handoff

Sales reps and contract managers think about the same customer at different moments. One app would have buried each group's work under the other's. The Onboarding module makes the hand-over between them visible.

Hide columns or keep them?

OptionShow 5 columns and move the rest to a detail page
ChosenKeep all 10 columns with horizontal scroll

Reps compared proposals across columns. Hiding them meant opening records one at a time, so we kept the density.

Toggle or dropdown for the main filter?

OptionDropdown with every filter in one place
ChosenToggle for Active/All, checkboxes for status

Active vs. All flips constantly; status filters change less. Two tiers matched how often each one is used.

Long create form or short?

OptionCollect every proposal detail up front
ChosenSix fields to create, details added later

A short form gets the record created. Details are added in the proposal builder once the deal is real.

Production screens

Annotated wireframes from the project

These are the actual screens used in stakeholder reviews and development briefings. Customer and partner details are placeholders.

Existing proposals screen with toggle filter, status checkboxes and a wide data table1234
Proposals · Existing
  1. Toggle for the frequent filter. Active vs. All, matching the Opportunities screen.
  2. Multi-select status. Approved, Alternate, In progress, Rejected, Won, Archived.
  3. Ten columns, horizontal scroll. Density was a deliberate trade-off.
  4. Pagination with page size for accounts with long proposal histories.
Archived opportunities with a Won/All toggle and status column1234
Opportunities · Archived
  1. Won / All toggle on archived records.
  2. Three sub-tabs for every module: Create, Existing, Archived.
  3. Statuses in plain words: Active, Lost, Abandoned.
  4. Consistent pager across both platforms.
Create proposal form with six fields and a single primary button123
Proposals · Create
  1. Linked fields pull customer and opportunity data instead of re-typing it.
  2. Coterminous, an enterprise contract option, as a simple checkbox.
  3. One primary action, so the next step is never ambiguous.
Figma file · Shared components

One component set, matched to the code

Axure was the client's sign-off format, but the UI was designed in Figma first. I built the shared components (module tabs, filters, table) as Figma components with variants, used them in both PMPS and CMPS screens, and recreated the same patterns in the Axure prototypes for review. All of it followed HP's Veneer design system.

Because the application was already live, the coded components were the source of truth. I checked the Figma components and Axure prototypes against them and kept names, states and spacing matching, so each enhancement could be built with existing components instead of new one-offs.

HP · Managed Print Central / Components
100%
❖ Shared components
DashboardOpportunitiesProposalsCustomersOnboarding
Opportunity filterActive All
ApprovedAlternateIn progressRejectedWonArchived
Proposal #DescriptionStatusCustomerCreated[id][description][status][customer][date]
Interactive fileClick a layer or anything on the canvas to inspect it
Outcome & reflection

Always live, improved release by release

The application was always live. I designed each enhancement as a clickable Axure RP prototype. The BA and the team tested it in QA before handoff, and then it went into the live application. Onboarding needed the most revision. The handover between sales and contracts was a new idea for users, and it took two rounds to make it clear.

“Her ability to map two completely different user types and design separate but coherent interfaces showed a maturity of thinking I rarely see.”
Shakila ShanmugnathanUI/UX Lead, HP Managed Print Services