Delivering a partnership-winning product that became a blueprint for digital change

Hawe's product line offered endless combinations with millions of possible configurations. While competitors provided advanced configuration tools, we were still relying on offline interactions.

Together with Product and Engineering, we reimagined that experience. Based on my qualitative research and insights from the discovery phase, we mapped the process and sketched out a vision of a digital cartridge configurator.

• Positioning as a cartridge solutions provider

  Creating a digital presence that showcased our cartridge expertise and closing the gap with competitors.

• Making cartridge
  configuration effortless

  Reduce dependency on sales calls by helping customers find the right configuration themselves.

• Attract potential
  OEM collaborators

  A well-designed platform is a powerful tool for attracting new partners. We already had someone in mind.

• Streamlining manifold
  design process

  Reducing time spent on repetitive manual calculations. Making the process faster, more intuitive, and scalable.

The project was very challenging. What made it manageable for me was staying close to the work and experts. Rather than waiting for perfect information, this meant quick alignment calls, making small adjustments, and iterating quickly.

• Development team said no

  Two months into design, engineering confirmed the full manifold configurator wasn't feasible in the given timeframe. I had to scale down to reach the 3 month deadline.

• Architecture I
  didn't choose

  We ended up with limited budget. To cut costs, we agreed on a solution to embed the new tool inside the existing Product Finder. That meant inheriting its constraints: limited component flexibility, existing user flows, and design decisions I hadn't made.

• No access
  to external users

  In a B2B environment, reaching out to client-side engineers without clearance risks the business relationship. Internal engineers were my only research channel. Good reference point, but not the full picture.

• US market,
  German systems

  Releasing in the US first created friction with pricing logic, user permissions, and internal tooling that had been built around German market assumptions.

• No analytics
  baseline

  The Product Finder had no tracking in place. There was nothing to benchmark against, no behavioral data to validate decisions, and no way to measure adoption.

Working between the Customer Experience and the Digitalization teams, I owned the entire design process. From initial stakeholder interviews through post-launch iteration planning.

I was a researcher, designer, and increasingly the person maintaining the shared understanding of direction across teams, management, and development.

Designing for specialists is a discipline of its own. The engineers I was designing for had years of domain expertise I couldn't replicate. And didn't need to. What I needed was to understand their workflow well enough to map it accurately, identify where friction lived, and ask the right questions without wasting their time.

I started with archetypes defined in discovery, and refined them through internal interviews. I had to come prepared with specific hypotheses, concrete scenarios, and a clear sense of what I was trying to learn from each conversation. I was fortunate to work with engineers who were patient and willing to answer my questions. I didn't take that for granted.

I ran a prioritization workshop with the originating stakeholder and innovation manager to separate what the product had to do from what it could do later. The original brief was a four-step flow: cartridge selection, manifold specification, document upload with analysis, and a bill of materials with pricing. We kept step one and four. Everything else became phase two.

Webshop was a separate application being built in parallel by another team. We worked together on visual language and component patterns to make sure both products would feel like part of the same system. It was important to me that we maintain consistency across two simultaneously and independently designed tools.

Once development began, the real negotiation started. Translating design into the existing Product Finder architecture surfaced conflicts I hadn't anticipated: patterns that didn't map, constraints that ruled out certain interactions, and edge cases that required the original design to bend.

I worked in short cycles throughout this phase: a problem would emerge, I'd build a quick prototype to test a solution against both user needs and technical reality, then use that to drive the conversation with the development team.

The prototypes became decision tools. They made trade-offs visible and gave management a concrete basis for the calls we were making together.

Several moments in this project required me to make decisions under uncertainty. These had real consequences for what shipped and what didn’t.

• Split the
  product in two

  When it became clear that the full manifold configurator wasn't feasible, I proposed treating it as two separate products. Each with a clear purpose, both products could be combined later into a more complete service.

• Cutting manifold
  configurator from scope

  The hardest call. Recommending the split required confidence that the cartridge selection piece alone could carry the partnership conversation. I convinced the idea giver to accept this call while he carried out the final pitch.

• Designing within
  someone else’s architecture

  Embedding the tool in the Product Finder meant inheriting patterns and constraints I hadn't chosen. I renegotiated the UX within those constraints rather than pushing for a rebuild. Even though it meant letting go of some design decisions.

• Escalating the
  pricing problem

  Three different price calculations, visible to the user, in a trust-sensitive B2B tool. I raised it to the pricing team and pushed for a database fix, even knowing it would delay us. Launching with inconsistent pricing would have damaged credibility.

• Progressive disclosure for dense technical data

  Engineers needed to compare products based on various technical specifications. There was a lot of information to show. Rather than revealing everything at once, I designed a layered information architecture: key attributes visible by default, full specs and data sheets behind deliberate interactions.

• Canary launch
  over grand reveal

  Between the development and budget constraints and Germany's thoroughness in getting things right, we opted for a controlled rollout. First to US market users and selected internal testers. A soft launch that allowed for more testing and better understanding of user behavior.

We launched without a full analytics stack in place. As soon as the tool was live, I brought in a data analyst to set up proper tracking. The early signal came through usability testing and direct user behavior.

• The contract
  was signed

  The primary business goal: acquiring the cartridge manufacturer as a partner, was achieved. The tool was the proof of concept that started conversations.

• First digital
  orders placed

  Post-launch, orders were placed by users outside the controlled test group. That was the first signal that the tool was working in real world conditions.

• The tool
  became a benchmark

  Internal engineers, the most skeptical test group, were impressed by the filtering and search experience and began requesting it across the full Product Finder. That response triggered a full UX audit and redesign of the existing tool, which I took on as my next initiative.

• UX moved
  to strategy

  The project gave design a visible outcome: a signed contract, working software, and a shift in how teams thought about investing in UX. More teams started involving design earlier. That's harder to quantify, and more durable than any single metric.

• Usability
  improved

  Each test round showed measurable gains in satisfaction and completion scores. Missing steps that engineers considered essential were surfaced through testing and fed back into the iteration cycle.

The second half of the original scope is still in development. Picked up by a separate team with the engineering capacity and CAD tooling it requires. The groundwork is there: the architecture, the design patterns, the user research. What's left is the build.

This project reinforced how much product success depends on the process. Looking back, these are the areas I'd approach with even more intention in future projects.

• Bringing engineering in on day one

  The weeks lost to rework after the dev pushback were the most avoidable cost in the whole project. Earlier technical alignment on backend systems would have shaped the design in ways that allowed for immediate integration.

• Get analytics
  running before launch

  We had no baseline for the Product Finder and no way to measure behavioral impact post-launch. Starting that conversation in discovery, not after go-live, would have given us something to measure against.

• Designing the
  launch

  We shipped a solid product with no internal announcement, no stakeholder moment, no go-to-market strategy. For a tool that helped close a major contract, that was a missed opportunity to build even more visibility. Both for the product and for design.

Scoping a realistic MVP can be quite a challenge. However, together with my team, I cut a four-step flow and and overwhelming feature list down to two steps we could ship.

If you're building something in a space where the users are experts, the stakes are real, and the margin for error is low, that's the kind of problem I want to be part of.

Get in touch → I'd like to hear what you're working on.