ZEISS Research Microscopy · Digital sales transformation, US market
From a business-card website to a platform that sells microscopes
Ten months from first interview to a working site, and three years on I am still engaged to help build it out.
The challenge
ZEISS Research Microscopy sells imaging systems that run from a few thousand dollars to several hundred thousand. A single purchase can involve multiple people at once — the research scientist who will use the instrument, the laboratory manager whose budget it comes out of, and a procurement team with a process of its own — each arriving with different questions and different authority, and none of them buying often enough to become practised at it.
The information those people needed was on the global ZEISS site: an index of application content, with separate product pages behind it. The US site, where an American customer landed, was closer to a business card — a number to call. Nobody could configure an instrument, price it or begin a purchase from either one, so the path of least resistance ran through a dealer, and ZEISS lost the margin, the direct relationship, and any view of what the customer had been trying to do.
The ambition behind the programme was explicit: double revenue in five years, with digital carrying a material share. That required the organisation to accept something it was not sure of — that a research scientist would configure and buy a major instrument online rather than picking up the phone. It also meant a significant change for the teams running ZEISS’s digital channels, centrally and in the US, who would be operating a sales platform rather than publishing brochure pages.
My role
Service design lead in discovery. Product and requirements owner — and a tester — in delivery.
Duration
Four weeks of discovery, three months of design sprints, six months of build — a working site in around ten months. Six further months of optimisation, then a major second release. Three years on, the engagement continues.
Outcomes
5× US site traffic, $1m of direct online sales within six months, and ten times the volume of customer quote requests.
Strategy
Service design
Product ownership
Ecommerce
Agile delivery
The rest of this case study is protected
The detail below covers client context, method and results. It is available on request — drop me a line and I will send the password, or enter it if you already have one.
That password is not right. Try again, or request access.
Context
Three sites, one customer, and no journey between them
There was no existing journey to improve. There was a global site holding an index of application content, a set of product pages sitting separately behind it, and a US site that amounted to a business card. A customer moving between those three was doing the joining-up themselves, and the last step was always a phone call.
That had a compounding effect internally. Because so little was captured, the business had no reliable picture of demand — which products drew interest, which applications customers were trying to serve, where people gave up. Decisions about where to invest were being made on the sales team's impressions rather than on evidence.
Underneath the commercial question sat an organisational one of similar size. A direct digital channel changes the relationship with the dealer network and what the sales team does with its time. It also changes the day-to-day work of the digital operations teams — content production and publishing centrally, campaign management and lead handling in the US — who would have to run a commerce platform rather than a set of brochure pages. Any answer that ignored those things would have been rejected however good the customer experience.
Approach
Discovery, then a design sprint per stage of the journey
Discovery
Interviews with ZEISS stakeholders and with customers, each following the same shape: the person's role, how it relates to the process, the pain points they live with, and the opportunities that would solve them. Every session closed on the magic wand question — if you could fix one thing with a single spell, what would it be — which reliably surfaces the thing people have stopped bothering to raise.
I collated the outputs and grouped them into themes, then built the as-is Service Blueprint. It runs across seven journey stages — Awareness & Discovery, Research & Consideration, Experience, Test & Demo, Decision & Purchase, Installation & Onboarding, Usage, and Loyalty — with swimlanes for customer steps, ZEISS steps, touchpoints, metrics and KPIs, pain points, opportunities and feature cards.
The blueprints did a second job beyond mapping the customer journey. The ZEISS swimlanes set out what the organisation would have to do at each step, which made the operational consequences of selling direct legible for the first time — what the central content and publishing teams would produce, what the US team would run, where leads would land and who would answer them. That became the basis for working with those teams through the change rather than handing it to them at the end.
The feature cards were then grouped by journey stage to form epics, producing the North Star Backlog: a single artefact tying every proposed feature back to the stage it serves and the evidence behind it. I presented the blueprint and the backlog to the board.
As-is service blueprint, Experience & Research journey (blurred)North Star epic backlog (blurred)
Design sprints
A design sprint for each stage of the customer lifecycle, structured as a high-level sprint handing off to a detailed design sprint, which in turn handed off to a build sprint. I managed the sprints and led the design stages, working with a team of service designers, business analysts and UI/UX designers.
Each high-level sprint ran the same way: identify the stakeholders on both the ZEISS and customer side, identify best-practice companies worth researching, run the interviews, do the outside-in analysis, and produce a current-state blueprint for that slice of the journey. From there we defined the future direction, ideated against it, built a future-state blueprint and a high-level design, then reviewed it with internal stakeholders and customers and iterated. Each sprint closed with a playback.
The detailed design sprint took the high-level output and turned it into a high-fidelity prototype, tested and presented back at the end of the sprint. Alongside the design work I managed the creation of the requirements — epics, features, user stories and acceptance criteria — on the DevOps board.
Low-fidelity wireframes from a high-level sprintHigh-fidelity clickable prototype from the detailed sprint
Build for Release 1
Designs and requirements passed to the build team, who built against the backlog and presented back at the end of each cycle.
The first release carried the core commercial journey: persona-led navigation, application and use-case pages, microscope and camera customisation, online purchase, quotes and trials for both B2B and B2C customers, a discounting mechanism for promotions, a rebuilt contact experience, post-purchase and cart-abandonment communications, and the first version of the My ZEISS customer area covering orders, trials and learning resources.
The project had dedicated testers, and I tested alongside them, working through each build against the acceptance criteria I had written. Testing your own criteria is the quickest way to catch the ones that read well on the board but do not hold up once the page is in front of you. Running the configurator and checkout myself before sign-off also meant I could answer for the release in front of the client rather than relaying someone else’s view of it.
The live product page
DevOps backlog management
With the site live, delivery moved to a continuous model — regular backlog grooming and prioritisation, with features dropping between the major releases rather than waiting for them.
The board carried the structure discovery had produced. Epics came from the North Star Backlog, features sat beneath them, and user stories beneath those, with each story linked back to the service blueprint and the journey stage it served — so any ticket on the board could be traced to the evidence that justified it.
Stories were written in the standard form — as a [persona], I want [capability], so that [outcome] — with acceptance criteria set out as GIVEN, WHEN, THEN. That is what makes a story testable rather than merely agreed, and it is the difference between a backlog a build team can work from and a list of intentions.
Each drop went through the same loop: testers ran the formal pass, I tested against the acceptance criteria and the journey the story came from, and anything that failed went back before release rather than into a defect list to be triaged later.
The cadence produced the things that only become obvious once real customers are using the platform: product comparison, bundle filtering by feature, service contracts added to a hardware purchase, and a guided wizard that recommends a product from a few simple questions for customers who do not yet know what they need. By this point the US digital operations team were running campaigns and leads off the platform themselves, which is what the continuous model was there to support.
Epics on the delivery board (blurred)Features beneath each epic (blurred)User stories in flight (blurred)A user story with its acceptance criteria (blurred)
Release 2
The second major release extended the platform to the highest-value segments and to new commercial models: enhanced application and use-case content for spatial biology and biopharma, leasing for premium systems, and software available to purchase, quote or trial online.
It also deepened the platform underneath — an expanded My ZEISS area covering lab setup, software management, orders, trials and quotes, registration and login folded into the buying journeys rather than placed in front of them, tariff handling across quotes and purchases, and richer integration into the CRM and customer data platform.
The testing load grew with it, since leasing and tariff handling touch pricing on journeys that were already live. I wrote the criteria and tested the built output with the test team across both the new journeys and the existing ones they cut across.
A Release 2 application page for the biopharma segment
Outcome
Customers started the conversation themselves
5×US site trafficAgainst the pre-programme baseline
$1mDirect online salesWithin six months of first release
10×Quote requestsCustomer-initiated rather than via a dealer
The traffic and revenue figures matter, but the quote requests are the ones that answer the doubt the programme started with. A tenfold rise in customer-initiated quotes means buyers were willing to begin a six-figure purchase on ZEISS's own platform rather than routing around it to a dealer — which is exactly what the organisation had not believed they would do.
The other result is organisational. The digital operations teams centrally and in the US came out the far side running a commerce platform: producing and publishing the content it needs, managing campaigns against it, and handling the leads and quotes it generates. That change was mapped in the blueprints at discovery and worked through with those teams as the releases landed, which is why it held.
Internally the programme did what discovery is supposed to do and rarely does: it left the business with a shared, evidenced picture of its own sales journey, and a delivery model that could keep extending it. Having proved the approach in US Research Microscopy, ZEISS moved to roll the key capabilities out to other divisions and geographies — which is how the Electronics and Software engagements came about.
