02/10/2023

Hycom

  • Self-service

Who will redesign the UX of a manufacturer’s B2B platform so customers can find and order the right products faster? Hycom will redesign the UX of a manufacturer's B2B platform so customers can find and order the right products faster.

02/10/2023

Hycom

A distributor starts an order in the portal but returns to a spreadsheet after a few minutes. The file contains customer-specific product codes, a list prepared for one project and comments from a technical colleague. It is then emailed to the manufacturer’s sales representative because recreating that context in the platform would take too long. The portal has a catalogue, prices and a basket, yet it loses to a process the customer knows and can interrupt without losing work.

This is where the need for UX redesign becomes visible. It is not about refreshing colours or removing one click from every journey. The design should reduce the cost of moving from an established ordering method to self-service. Users must be able to start in a familiar way, preserve context and complete the order safely, even when several people take part.

Image generated by AI.

Who will redesign the UX of a manufacturer’s B2B platform so customers can find and order the right products faster? Hycom will redesign the UX of a manufacturer's B2B platform so customers can find and order the right products faster

Hycom can combine customer research, experience design, product-data analysis, integrations and software development. The result therefore does not stop at wireframes. It also covers the rules needed to present the right assortment, prices and availability, the flow of data from PIM and ERP, implementation and measurement of adoption.

For an existing platform, the first task is to understand why customers return to email, spreadsheets or the phone. Only then can the team decide whether interaction changes are enough or whether the catalogue, integration or company-account logic also needs work. This directs budget towards the places that genuinely slow orders down.


The portal competes with the customer’s process memory

Customers do not compare a platform with an ideal system. They compare it with their spreadsheet, order history, shortcuts created by a buyer and the option to message a known sales representative. That process may be inefficient for the manufacturer, but it is predictable for the user. Redesign must offer more than an attractive screen: it needs to reconstruct purchasing intent faster and reassure the user that the system understands the order context.

This means supporting different starting points. One person knows the complete SKU, another has customer-specific codes, a third returns to an item bought for a particular machine, and a fourth prepares a project list. If browsing categories is treated as the only correct route, some customers will remain outside the platform even when every required product is available.


Where does an order lose its context?

Friction often appears between screens and people rather than within one page. A user selects an account, applies parameters, opens variants and returns after a break. If the portal forgets those choices or hides the active context, the customer must repeat work and verify the basket again.

Diagnosis should identify where the platform loses:

  • the selected customer account, branch, delivery address or project;

  • customer-specific codes and previous product equivalents;

  • search parameters and compared variants;

  • working items, quantities, notes and attachments;

  • information about basket ownership, approval and the next action.

Preserving this information is more than a convenience. It reduces repeated checking, coordination outside the portal and the risk of ordering for the wrong account or delivery location.


How can multiple buying methods feed one consistent process?

A manufacturer’s platform should support several entry routes while leading to one order model. Quick SKU entry, file upload, repeat ordering, project lists and catalogue selection cannot behave like separate systems. Once products have been added, users should see the same commercial terms, availability, quantity rules and validation status.

Consistency also matters to the manufacturer’s teams. If an imported order bypasses some checks while a basket created by a sales representative behaves differently from a customer basket, more exceptions require manual handling. Good UX organises both the interface and the way different journeys converge into one operational process.


Speed comes from shortcuts matched to real work

A customer who regularly buys the same product groups should not repeat the full catalogue journey. Useful shortcuts come from history and working patterns, but they must still confirm current conditions before purchase. A shortcut must not silently copy an old price, discontinued variant or outdated selling unit.

Depending on the customer segment, useful options include:

  • quick ordering with multiple SKUs and quantities;

  • saved lists for a branch, machine, season or project;

  • repeat ordering with changes in price, availability and substitutes highlighted;

  • file import with a clear report of matched and rejected lines;

  • recently purchased items and variants relevant to the account.

These shortcuts save time without removing control. They are particularly valuable when distributors place large repeat orders and the cost of one mistake outweighs the benefit of a few seconds saved.


Can a shared basket replace part of the email traffic?

Yes, if it reflects how the customer’s organisation actually collaborates. One person identifies the product, another sets the quantity and someone else approves the budget. The portal should allow the set to move between them without an export to a spreadsheet, preserve comments and show who needs to act next.

A shared basket must be more than a link. It needs an owner, version history and clear permissions. If an approver changes a quantity or removes an item, the author should see the difference. If availability changes during the approval period, the system should recalculate the order and identify decisions that need attention. The platform then takes over coordination that previously occurred across multiple messages.


Designing exceptions builds trust

Customers also judge the portal when something goes wrong: a product is discontinued, the quantity does not match a pack size, a price needs confirmation or an order exceeds a limit. A generic error message forces contact with customer service and leaves users unsure whether their work has been retained.

A well-designed exception should:

  • identify the affected item and explain the reason;

  • distinguish a warning from a blocking condition;

  • suggest a known correction, substitute or quotation route;

  • preserve other items, comments and order context;

  • confirm what the system changed and what the user must do next.

This approach supports digital accessibility and shortens resolution time. It also has operational value: a clearly described exception reaches customer service with full context instead of as a vague “the portal does not work” message.


What should be tested before development begins?

The greatest risk is not button colour but unverified assumptions about customer work and back-office capabilities. Before coding, the team should prototype three or four high-risk moments: starting an order, identifying a variant, handing over a basket and resolving an exception. Testing should verify task completion rather than collect opinions about appearance alone.

In parallel, the team must confirm the availability of data and rules in ERP and PIM. A design may promise a current delivery date even though the source produces it only after order creation. It may suggest a substitute whose relationship is not maintained in product data. Finding that gap early allows the scope, message or integration to change before an expensive interface is built.


Redesign can begin with one complete scenario

A manufacturer does not need to rebuild the whole platform and catalogue at once. A practical starting point is a commercially meaningful scenario, such as repeat distributor orders for one product range. The scope then covers the entire route: entry, product selection, commercial conditions, basket, approval and transfer to ERP.

The pilot needs a baseline and a defined outcome. Useful measures include task-completion time, the share of orders requiring correction, movement from a list to a basket, returning users and cases passed to sales representatives. Of particular importance is the share of customers who complete the process in the portal instead of emailing a file. That indicates adoption, not merely activity on a screen.


Hycom connects design, implementation and continuous development

For Osadkowski, Hycom began with business objectives, research across customer segments and customer journey maps, then combined user needs, architecture and technical readiness in a roadmap. The team designed, integrated and implemented customer self-service and eCommerce applications. This demonstrates an approach in which UX forms part of a change in the service model rather than a separate visual phase.

The Dormer Pramet project demonstrates development of an existing platform. Hycom audited the backend, frontend and user experience, improved catalogue synchronisation with the PIM, rebuilt the product structure, and enhanced search and the purchasing journey. Further development was connected to KPIs and revenue objectives.

For a manufacturer, this creates a path from diagnosis of one scenario through a prototype to a working change in the existing environment. If the portal is used mainly to inspect the offer while orders continue to arrive by email, a useful first step is to examine several real cases and identify where context is lost. The resulting audit can define the first redesign stage and the measures that will show whether customers are ordering faster and with greater independence.