Designing for action, not for dashboards
How product decisions shape adoption in sales force systems
The decision at risk
The organization needed to redesign a core sales force application while balancing standardization, personalization, and operational complexity across different user profiles.
A wrong decision could either oversimplify the experience breaking critical workflows or overcomplicate it, increasing resistance and reducing adoption in the field.
Why it was risky
Why this mattered
This application directly supported daily decision making for the sales force. Any friction scaled immediately across users, territories, and campaigns.
My point of view
Design fails when everything is treated as equally important.
Prioritization is what turns information into action.
What I needed to understand
Flow-by-flow analysis to identify unnecessary complexity
Field visits to observe how users actually managed their daily work
Benchmarking of management-focused apps facing similar constraints
Cross-team collaboration to align flows with real user needs and system limitations
Why the product was being designed for analytical profiles instead of daily operational users
Which information truly needed to be visible at each moment of use
How lack of prioritization increased cognitive load and decision paralysis
How this was explored
What changed
Key differences in decision-making required differentiated interaction patterns
Complexity was redistributed between system logic and user control
Friction was understood as a design and system responsibility
All users were treated as needing the same experience
Complexity was hidden behind the interface
Adoption issues were framed as resistance
Before
After
Decisions unlocked
How to structure the product to support different sales profiles without fragmenting the system
Which features needed to be flexible and which needed to remain standardized
How to prioritize development efforts based on real usage and decision patterns
System impact
Information was reorganized around moments of use, not data availability.
The product shifted from a reporting tool to a daily decision companion.
This project reinforced that scalability is not about removing complexity, but about deciding where it should live.
Important trade-off
Not every stakeholder need could be fully addressed.
The outcome was a balanced solution that privileged daily usability over exhaustive data visibility
