Product managers
Define and update compatibility rules without waiting on engineering.
CRD / Telecommunications
Compatibility rules, without the code.
CRD turns rule logic that once lived in code into an interface product managers and sales teams can use directly.
The brief
Every rule change meant a ticket.
Compatibility checks were manual and inconsistent, so the wrong bundles reached customers. Rule logic lived in JSON and in code, where only engineers could change it.
I owned the design on a cross-functional build with engineering, QA, product and stakeholders. I ran the research, mapped the rule-creation flow and made the core UX decisions.
Research
Three users. Different needs.
All three needed a clear interface that handled complex rule logic without exposing it to the person using it.
Developers
A clear schema and a UI that maps cleanly onto it.
Sales agents
Clear, trustworthy recommendations at the point of sale.
Design decisions
Map the logic before the UI.
I mapped the whole rule-creation flow before any UI: eight steps from starting a rule type to activation, branching where predicates get built and configured.
The flow became the shared reference for design, engineering and QA.
See the eight-step flow
- Start rule type creationKick off a new rule type and give it a name.
- Open predicate builderOpen the builder where the rule's conditions get defined.
- Build predicateCreate a predicate, starting from the default driver.
- Configure predicateSet its assertions, attributes and operations.
- Add predicate to rule typeAttach the finished predicate to the rule.
- Define rule type logicDecide how the predicates combine into the full rule.
- Review and validate rule typeCheck the whole rule for errors before it goes live.
- Save, apply or activateSave it, then apply or activate it for use.
Two layouts exposed the trade-off.
Supporting JSON-based rules while keeping the interface usable for non-technical users meant testing several layouts before one held up.
A step-by-step flow
Less overwhelm, but it slowed experienced users.
Everything on one screen
Faster, but too dense once rules got complex.
Put the rule builder at the centre.
I moved the rule builder to the centre and stripped out everything the task didn't need. Condition groupings, quantity controls and product associations made the full rule readable at a glance.
Internal testing drove changes: a configuration panel, rule templates and visual feedback so users knew their state.
See the earlier design work
Initial wireframe
A two-panel layout, with the rules list on the left and details on the right. Simple for daily use, but the rule builder revealed its complexity fast.
Design iterations
A configuration panel, templates and a JSON output view that stays out of the way.
Final design
Three clear zones.
A searchable rules list on the left, the rule builder in the centre and product configuration on the right. Status tags show the rule state, and validation runs in real time.
Rules list
Searchable, status-tagged, always in view.
Rule builder
The centre of the screen, focused on the task.
Product configuration
Live validation before activation.
Impact
Fewer errors. Faster rule creation.
About 70%Fewer compatibility errors
About 40%Fewer returns from incompatible bundles
About 60%Faster rule creation
Developers had clean structure to build on, and product managers could change rules without waiting on engineering.
What I learned
Deciding how much complexity to show.
Both earlier versions got that balance wrong. The final design worked because it showed people what the task in front of them needed.
Designing for three audiences meant finding one structure that could serve all of them.