Case study 03 · Protected
This case study is password protected.
Incorrect password. Please try again.
Turning a vague post-merger synergy charter into a user-driven product — while influencing system-level decisions that shaped how future work at iLEVEL could be built.
Peer Comparables originated as part of the S&P Global × IHS Markit merger, where leadership funded a set of "synergy" ideas to integrate CapIQ Pro with iLEVEL. On paper the opportunity was clear. In reality it was anything but.
The charter was speculative — written without deep iLEVEL knowledge. Product ownership was fragmented, with multiple PMs rotating in and out. Expectations were to show meaningful progress within 6 months. Internal constraints like avoiding overlap with Qval limited the solution space.
Do we execute against a loosely defined charter, or step back and define what would actually be valuable to users?
From execution to direction-setting
Rather than treating this as a delivery exercise, I positioned design to define the problem space. My role became: establishing a clear product direction grounded in user needs, acting as an SME and stabilizing force across rotating PMs and external designers, and ensuring what we shipped would hold up beyond the initial 6-month window.
This meant pushing the team to slow down just enough to ask: what are users actually trying to accomplish across these two systems?
Through client interviews and discovery, a clear pattern emerged. Users weren't looking for generic integrations — they were trying to evaluate companies against peers, monitor relative performance across their portfolio, and move fluidly between market data (CapIQ) and portfolio data (iLEVEL). This consistently pointed to one high-value space: Peer Comparables.
At the same time, a sister product — Qval — already supported valuation workflows, and we were explicitly told not to cannibalize it.
How do we design a Peer Comparables experience that is powerful and flexible, without crossing into valuation territory?
Peer Comparables wasn't a typical CRUD interface — it introduced two distinct layers of interaction with very different update frequencies: a peer set (relatively stable) and a metrics view (highly dynamic, frequently changing).
Diagram · Peer Set vs Metrics mental model
Two-layer model showing stable peer set vs dynamic metrics view, and why each is saved differently
Users needed to save both, but for entirely different reasons. Traditional IA patterns didn't map cleanly to this mental model. We explored ways to clearly separate these concepts without overcomplicating the UI — ensuring users always understood what they were saving and why.
Screen · Dual save behavior
Annotated UI showing how peer set and metrics view are saved independently
Two major system-level constraints influenced the outcome — and pushing through both had impact well beyond this feature.
Historically, extending the Widget Editor — iLEVEL's configurable UI framework — was avoided. Considered too complex, consistently deprioritized despite clear user value.
Research showed Peer Comparables needed to live there to be truly useful. I pushed for this — not just for this feature, but as a broader shift. Proved it was feasible, demonstrated it was worth the investment.
Screen · Widget Editor integration
Before/after showing Peer Comparables within the Widget Editor
iLEVEL was lagging behind sister products in adopting Solutions UI, a newer shared design system. This project became an opportunity to introduce Solutions UI patterns into iLEVEL and move toward cross-product consistency and scalability.
Both decisions extended beyond the feature itself — they shaped how future work could be built.
Execution wasn't straightforward. We relied on an external agency for the initial 6 months. Much of that time was spent navigating product ambiguity and team dynamics. By the time designs were strong, the engagement was ending — without validation.
To maintain momentum, I brought in a new internal designer and used usability testing as her onboarding path, accelerating both her learning and the validation the project needed. This ensured continuity without resetting.
Delivered a validated design foundation grounded in real user workflows
Became the first major iLEVEL project delivered on time
Broke long-standing resistance to extending the Widget Editor, influencing future product direction
Paved the way for Solutions UI adoption within iLEVEL, aligning with sister products
Established a foundation that has since expanded into Valuations
Ambiguity is an opportunity to lead
When direction is unclear, design can define it — but only if it's willing to slow down long enough to ask the right questions.
Systems decisions matter as much as UI decisions
Pushing on the Widget Editor and Solutions UI had lasting impact — the right systems bets compound over time.
Continuity is critical in complex projects
Without it, even strong ideas stall. The transition from agency to internal designer needed deliberate management to preserve momentum.
User-centred reframing beats top-down mandates
Grounding in real workflows made the product durable — and made it easier to align stakeholders around decisions that mattered.