The Core Problem

Specialists had to compare devices, configure options, and generate quotes while speaking with customers in real time. Across markets, the same consultation moments were implemented with different structures, labels, and validation rules. That fragmentation increased training time, raised implementation defects, and made each rollout negotiation-heavy.

The product needed to support local legal and commercial differences without losing global speed, consistency, and delivery control. The core problem was to protect local relevance while avoiding permanent UX forks market by market.

Salesforce CRM Transition & Technical Feasibility

This redesign sat inside a wider CRM transition to Salesforce. That context changed how design decisions were made: every key interaction pattern had to be validated against Salesforce constraints and implementation effort with the specialized Salesforce development team.

We ran feasibility checks on concrete consultation moments, including:

• Consultation and product comparison structures

• Hearing test presentation and interpretation modules

• Booking and consultation flow modules connected to CRM entities

The design trade-off was explicit: preserve consultation clarity for specialists while staying within platform constraints, delivery windows, and configuration boundaries. Instead of over-designing unconstrained concepts, we prioritized patterns that could be implemented reliably within the Salesforce migration path.

Constraints

• User constraint: specialists needed fast reading and low cognitive load during customer-facing consultations.

• Business constraint: leadership needed faster rollout and lower variance across markets.

• Technical constraint: one architecture had to handle local catalog, pricing, and regulatory rules within Salesforce migration constraints.

• Organizational constraint: country teams needed autonomy without creating permanent UX forks.

• Governance constraint: change requests needed explicit ownership and approval boundaries.

Key Decisions and Trade-offs

I treated this as a product operating model decision, not a visual refresh.

1. I separated a global consultation core from local configuration layers, because free-form local branching was driving rework, resulting in faster rollout planning and fewer custom implementations.

2. I defined strict rules for what was configurable versus what required core change, because unclear boundaries caused repeated escalation loops, resulting in cleaner prioritization between market teams and central product.

3. I standardized high-risk comparison and quote states, because inconsistent states caused training errors and QA drift, resulting in more predictable specialist behavior and more reliable releases.

4. I used progressive disclosure in dense comparison moments, because full-detail layouts slowed live conversations, resulting in quicker scans and fewer interaction pauses in store.

5. I aligned consultation stages with rollout governance gates, because late technical decisions were blocking delivery, resulting in earlier feasibility checks and fewer handoff surprises.

6. I aligned core consultation vocabulary across markets, because label drift created hidden training cost, resulting in faster onboarding and more consistent specialist communication.

Alternatives rejected:

• Country-by-country interaction forks, because short-term local speed would continue increasing long-term maintenance debt

• Near-total centralization, because it would reduce local compliance fit and market adoption

Main trade-off: local teams gave up part of pattern freedom, but gained faster delivery, stronger implementation quality, and clearer decision accountability.