Turning variable supplier content into a flexible B2B PDP system
Flowtech sells technically complex products, but the amount and type of information available can vary significantly. Some products have little more than an image and core specification. Others include variants, detailed technical data, drawings, CAD files, documents and application guidance.
I explored how the Product Detail Page could help customers assess those products with greater confidence without making every page equally long or creating separate templates for individual suppliers.
I combined published UX guidance, a benchmark of 16 e-commerce and manufacturer sites, early session observations and an audit of supplier content. I then designed a modular PDP framework and tested it against products from Parker, Bosch Rexroth and Danfoss. The same system thinking was later extended to products whose price must be requested rather than added directly to the Basket.
This is an ongoing design proposal. The research, framework and initial supplier examples have been reviewed with an e-commerce stakeholder, but the latest refinements are still in progress. The work has not been implemented, tested with customers or measured after release.
At a glance
Role: UX Designer
Product: Flowtech B2B e-commerce Product Detail Pages
Scope: research, information architecture, modular content, supplier stress tests and POA purchasing states
Timeline: June 2026 – ongoing
My contribution: published research, competitor and manufacturer benchmarking, behavioural review, supplier-content audit, information architecture, interaction design, annotated PDP concepts and stakeholder iteration
Collaboration: e-commerce stakeholder; wider business and technical review pending
Status: researched design proposal in refinement; not implemented or validated
The problem
The existing PDP supported product selection and purchasing, but technical buyers could need much more information before deciding whether a product was suitable. They might need to inspect a larger image, compare variants, check specifications, open a drawing or technical sheet, or find a viable alternative.
The challenge was not simply adding more content. Supplier data was inconsistent, and displaying every possible section on every page would create empty modules, duplication and excessive page length. The design needed to support both quick purchasing and deeper technical evaluation while remaining recognisably part of the same Flowtech experience.
Building the evidence
I reviewed published product-page and B2B e-commerce guidance from Nielsen Norman Group, Baymard, Algolia, Sana Commerce and SparkLayer. I also benchmarked industrial, fluid-power and technical e-commerce sites, including both manufacturers and distributors.
The review highlighted four recurring needs:
An early review of Flowtech sessions suggested that customers reaching a PDP were often evaluating suitability: inspecting images and technical information, reviewing variations, and sometimes returning to search. I treated these as qualitative signals rather than representative findings because the recordings, sample sizes and tagging evidence have not yet been recovered.
This led me to prioritise improvements that could increase confidence without creating significant operational overhead. Technical information, image inspection, supplier documentation, accessories and long-page purchase support were stronger initial candidates than features such as reviews, customer Q&A or AI-assisted questions.
Designing one modular framework
Rather than create enhanced pages for selected suppliers, I designed one brand-neutral framework with a consistent core and optional modules.
The product title, code, price or price status, availability, quantity and purchasing actions would remain stable. Richer media, specifications, drawings, CAD, documents and application guidance would appear only when the relevant content existed. Variants, alternatives, accessories and recommendations would be shown when the product relationship was meaningful.
The guiding principle was simple:
Enhanced should mean presenting the useful content that exists—not making every PDP equally long.
I used progressive disclosure to manage detailed content. Longer technical sections could show a useful preview with an explicit action to reveal the remainder, while short sections stayed fully visible. Important information was not repeated in multiple places, and controls disappeared when they added no value: a single-image product did not need an empty thumbnail system, and a product with one option did not need a variants table.
I also separated product visualisation from engineering assets. Images, videos and future interactive views belonged in the media gallery; drawings, CAD files and downloadable technical documents remained with the technical information.
Stress-testing different supplier products
I tested the framework against products with very different content profiles.
The Parker example had one image and no meaningful variant selection, but richer written and application content. The Bosch Rexroth example also had one image, with a concise specification and individual CAD and document files. The Danfoss example contained more imagery, variants, technical data and documents, making it a useful test of longer expandable sections.
These examples helped turn the template into a set of content rules. Modules could expand, simplify or disappear without changing the overall hierarchy. The full template therefore represented everything the system could support, not a requirement for every product page.
Refining the hierarchy after review
Stakeholder review raised three important questions for the next iteration: whether the Technical Data Sheet should remain near the top, how Alternative Products could be easier to discover, and how the Additional Variants table could occupy less of the page.
The current direction is to test a preview treatment for large variant tables, retain a clear route to technical evidence, and add a more obvious link from the main product area to suitable alternatives. New Festo and SMC examples will provide further stress tests once the revised hierarchy is ready.
What would be measured
There are no design outcomes yet because the proposal has not been implemented or tested. If the work progresses, I would establish a baseline and measure whether customers can reach and use the information they need without harming purchasing performance.
The measurement plan would include:
- Engagement with technical specifications, documents, media and drawings.
- Use of variants, Alternative Products and supporting-product routes.
- Returns to search after viewing a PDP.
- Add-to-Basket progression and completed purchase, segmented by product type and device.
- Qualitative feedback and task-based usability testing with technical buyers.
Data availability, page performance and standard-product conversion would provide important guardrails. Engagement alone would not prove that a module was useful; the behavioural data would need to be interpreted alongside customer feedback and purchase outcomes.
What I learned
The most important design problem was not deciding how one PDP should look. It was creating rules that could accommodate products with radically different content without leaving gaps, repeating information or overwhelming customers.
The supplier stress tests made the framework stronger because they exposed where sections needed to simplify or disappear. They also reinforced the value of treating content availability and product relationships as design constraints rather than filling a template with idealised content.
The work also reminded me to keep evidence and status visible. Published guidance, benchmarking and early session review helped frame the opportunity, but they do not replace customer validation or post-release measurement. The next meaningful step is to complete the revised examples, confirm the product-data and technical constraints, and test whether the hierarchy helps customers make technical decisions more confidently.