HPE Services Management

Agree on the problem before specifying the interface

The study establishes a user-centered approach spanning understanding, definition, design, and delivery. Knowledge-transfer sessions with business and technology teams are used to align on the platform, product vision, requirements, and constraints.

The early strategy emphasizes structuring information, understanding platform modules, and reducing friction in service discovery. Later high-fidelity and development stages are described as part of the approach; the supplied work itself concentrates on strategy and journeys.

Build architecture and navigation from tasks

The approach moves from persona mapping to user journeys and information architecture. Card sorting is described as an input to restructuring, with low nesting and preservation of the user’s mental model as principles.

Concepts are compared through navigation, layout, use of available space, and simplicity. Wireframes are deliberately grayscale so functional decisions can be evaluated before visual styling. These pages describe the design method; they are not published usability-test results.

Five roles, different responsibilities

The questionnaire asks who configures and approves a quote, how requests reach sales and partners, and how people track progress. Those questions establish the handoffs that a service configuration experience must support.

Reference personas describe a customer seeking suitable services, a sales representative guiding the customer, a partner configuring quotes, an operations role resolving processing issues, and a solution architect associating services with products.

The source explicitly states that these personas are derived from role-play with dummy data because of NDA restrictions. Their concerns are illustrative design inputs, not validated participant findings.

A quote moves across people as well as platforms

A role-to-platform relationship view situates users among OCX, Smart Swap, Configurator, Diagnostics, Test, OCA, and Gypsy. The customer task flow then connects product selection, service configuration, quote handling, and order checks.

The customer and sales-representative journey maps make tracking, notifications, and assistance visible. The sales representative acts as a bridge rather than an isolated user. The published journeys are reference-only under the source’s NDA caveat.

Two entry paths into service configuration

A service-led path handles people beginning with services, including registered, non-registered, and guest contexts. A product-led path begins with a selected product and retains that context while relevant services are selected.

The product-led diagram includes auto-attached services, bundles or individual services, and basic, standard, and optimized options. Cross-platform handoffs between NGQ / OCX and CPQ are explicit. The documented outcome is a proposed system flow, not proof of a launched configuration service.