B2B · Internal tool · Health · 2025-today

In-Store Consultation Tool

In every consultation, there’s a moment when a possible product becomes
a recommendation. I designed the decision logic behind that transition.

Context

A consultation tool for desktop and iPad, designed to help consultants work with customer needs, product configurations, and recommendations.

The team

8 people

My role

UX Design and descision logic as the only UX designer on the project. I led the UX part of reviews and designed the UX final wireframes.

Timeline

2025 to today. The development is ongoing, so there is no usage data yet.

The developers had drawn a technical process but stakeolders lacked a shared  consultation understanding of how it would work during consultations, particularly when a configuration becomes a recommendation.

The existing consulting-flows, the decision tree that the entire team worked on, and the final UX wirefrmaes for desktop and iPad.

This project is under a non-disclosure agreement.
The client, product and internal system names have been generalised. Screens have been anonymised, and all names, figures and data shown in them are fictitious.

How a consultation reaches a recommendation

A consultation can begin from different points, with an existing questionnaire from the customer, a new one, or a previous configuration. Consultants can also configure products directly, without a questionnaire.

These different starting point needed to work within one consistent decision flow.

Four uses cases and one goal

The client provided four use cases and one overarching goal, that of consistent consultations across stores.

I examined each use case from two perspectives:

1

How does it support the client's goal?

2

How does it support the client's goal?

Two interviews with consultants, prepared with a UX colleague, indicated that finding the right product can take several appointments.  
Customers need time to reflect, and consultants cannot rely on remembering previous conversations. At many points consultants could only note down customer requirements.

Further research was not possible in this project.

Reframing a technical process around real consultations

The developers had documented the tool from a technical perspective, but stakeholders struggled to connect it to what happens in stores.

On my own initiative, I reframed the process around the consultant's workflow mapping each step and highlighting, unanswered questions. I then combined the consultation flows, interview findings, and technical process into one shared decision diagram.

One diagram to work from

The decision diagram became the shared reference for discussing scenarios, identifying unresolved parameters, and determining what belonged in the first release.

Development Foundation

The developers adopted the diagram as the foundation for teir work.

Open Decisions

Stakeholders could see which parameters still required clarification.

Release Prioritization

The diagram helped distinguish first-release needs from later possibilities.

Making unresolved decisions explicit

The decision diagram gave stakeholders a shared reference during regular reviews. Yet three fundamental questions kept resurfacing:

1

Are configurations and recommendations the same thing?

2

When does a configuration become final?

3

Why must recommendations remain unchanged?

I revisited these questions deliberately, even after apparent agreement. Each decision needed to be clear enough for stakeholders to explain it to their teams and for developers to implement it consistently.

Configuration vs. recommendation

The key challenge was defining when an evolving configuration becomes a final recommendation. Turning the "maybe" to a "yes". The client had established one rule: a configuration remains open until the customer agrees to take home a PDF recommendation.

But what did that mean for drafts, corrections, or returning customers? I translated these ambiguities into clear system states and decision rules, using the flow diagram and stakeholder reviews to define how each scenario should work.

What the first version leaves out

Automatic saving of configurations

I proposed autosave after reviewing patterns in comparable systems. Since only completed questionnaires were saved, interrupted consultations could result in lost input. Whether this happened in stores remained unclear.

Developers supported the idea, but implementing it required new functionality. More importantly, autosave would introduce intermediate states and complicate the distinction between configurations and recommendations. I supported deferring it to a later release to keep the initial scope manageable.

This left a specific question for later validation, as how often are consultations interrupted, and does that result in lost work.

Design Decision 1

Making changes safe without limiting flexibility

The client required configurations to remain editable until the customer accepted a recommendation. My challenge was making that flexibility safe.

I introduced progressive steps and dependency rules to prevent invalid product combinations. For questionnaire corrections, an explicit edit mode and save reminder reduced the risk of losing input.

Stakeholder reviews revealed two additional scenarios: changing customer needs and rejected results. I incorporated both into the flow, allowing consultants to reconfigure while keeping questionnaires locked once they formed the basis of a recommendation.

Edit mode: a questionnaire no recommendation is based on yet. The notice asks to save before moving on.

Design Decision 2

Every recommendation remains traceable

The client required recommendations to remain unchanged once accepted. But customers often reconsider their choices across multiple consultations, sometimes in different stores.

I designed the flow for creating new recommendations from existing configurations, preserving earlier versions while making changes visible. Consultants can adjust or duplicate configurations, see which sections changed, and document the reason for a new recommendation.

Together with the UI designer, I defined how those changes would be highlighted. The result is a consistent history that helps consultants understand previous decisions without altering what the customer originally received.

Terms: Konfiguration (configuration) & Produktempfehlung (recommendation).

At least one reason, chosen.

GEÄNDERT: changed.

Design Decision 3

Encouraging the preferred path without restricting choice

The client wanted consultants to start with a needs profile but still allow direct product configuration.

I wrote the dialog copy to encourage the needs profile without blocking the alternative. Both paths remain accessible, while recommendations created without a questionnaire are clearly identified in the customer record.

This preserves consultant flexibility while making the origin of each recommendation transparent.

What I owned and shaped

I led the UX work from initial analysis to final wireframes, with a focus on making complex business rules understandable and actionable.

• Reframed the project around real consultation workflows rather than technical processes

• Analysed use cases, mapped existing flows and identified critical gaps

• Created the decision diagram that became the shared reference for stakeholders

• Led UX reviews and delivered the final desktop and iPad wireframes

• Proposed autosave for a future release and wrote the free-configuration dialog copy

Co-defined with a second UX designer

• Research questions and two consultant interviews with a UX colleague

• Reconfiguration scenarios and decision logic through stakeholder reviews

• Visual marking of configuration changes with the UI designer

Defined by the client & delivered by others

• Client: Core business rules governing configurations, recommendations, questionnaires, and change tracking

• Developers: Technical process, constraints, and questionnaire renewal rules

• UI designer: Visual design based on my UX wireframes, with input from the design lead

Outcome

Designed, and not yet measured

Delivered

A shared decision model adopted by developers, along with final UX wireframes for desktop and iPad covering the consultation flow, configuration changes, recommendation history, and customer records.

Intended outcome

Consultants should be able to understand what was recommended, why, and what changed, even across appointments and stores. Recommendations remain unchanged and traceable, supporting the client's goal of consistent consultations across stores.

Whether the design achieves this has not yet been validated.

How I would evaluate it

• Validate the decision rule:
  Track how often a new recommendation follows shortly after an accepted one, and why. Frequent changes could indicate that customer agreement is not the right moment to finalize a configuration

• Test the interaction model:

  Can consultants distinguish configurations from recommendations, understand what remains editable, and navigate changes without assistance? This can be evaluated through usability testing before launch.

• Revisit the autosave decision:
  Observe how frequently consultations are interrupted and questionnaires abandoned. This would help determine whether automatic saving should be prioritized for a future release.

Slider showing the reference design system from Six Day and our developed design system

How about levelling up together?

© Carla Eckhard 2026