Solution Finder
A two-question router that sat directly beneath the hero on the Lumen homepage. A visitor says who they are and what they came to do; the second question reshapes itself around the first answer, and the pair produces a starting set of solutions instead of a navigation menu.
The platform could not do it
Solution Finder was scoped to be built in ION Interactive, the platform I owned for the team. ION delivered its experiences to the page through an iframe, and that broke the one thing this component existed to do: when a visitor clicked a result, the destination page opened inside the iframe rather than in the parent window, a full Lumen page rendered in a box a few hundred pixels tall. ION had no remedy for it at the time.
This was going directly below the homepage hero, the first thing a visitor would see after the banner. An embed that trapped people in a frame was not shippable there.
Designed first, and built outside the CMS
I offered to build the component from scratch instead, outside ION and directly into the page. The turnaround was short and the ask was to go straight to development.
I pushed back. Something with this much branching, a persona list, a second question that changes shape based on the first, and a result set driven by both, needed to be mocked up before any of it got written. That argument is the reason the rest of this case study exists: I worked with stakeholders to define the inputs and the outputs first, wireframed the flow against them, and only then moved to high fidelity.
Three directions, one question each
Round one put up three ways to ask the same two questions. Each one trades a different thing away.
Every persona visible at once as a persistent list, the second question as a dropdown beside it, results re-rendering as you change either. Nothing is hidden and any answer can be compared against another. Costs the most vertical space on a homepage that has none to spare.
View full size ↗
The same live behavior with both inputs collapsed into two stacked dropdowns in one card. Smallest footprint of the three, and the fastest to scan. The trade is that the persona options are hidden until opened, so a visitor cannot see the range of what the tool covers.
View full size ↗
A stepped wizard: start, question one, question two, result, with a two-dot progress indicator. Labeled the safe option in my own file, it was the most guided, hardest to get lost in, and the most screens and states to build and maintain.
View full size ↗Direction A was carried to 360px in the same round. The persona list stacks above the dropdown and the results run full width. The layout question was settled at both ends before anyone picked a direction or any confusion arose.
View full size ↗
Direction B, reduced further
Stakeholders chose Direction B and asked to simplify it further to match a pattern another company was already using: the two dropdowns and the heading, with the result panel held in an empty state until both questions are answered rather than sitting open underneath. That is the version that shipped.
Before build I tested that hand-written code could be embedded
into AEM at all, and set CSS naming conventions so my styles could
not collide with what was already on the page. Every class in the
component carries an sd- prefix, still visible in the
archived markup. The integration risk was worth retiring before
the logic got written, not after. The finished component follows
the Lumen Design System, drives question two off the answer to
question one, and carries analytics tagging that captures who is
arriving and what they are trying to do, seeding each group with
the solutions typically advertised to them.
Wayback Machine snapshot, 7 January 2026. The component still runs: choose a role and the second question rebuilds itself around it.
