RESEARCH
Reframing search as a discovery problem
Ran a competitive teardown, a qualitative study, and a heatmap audit to reframe the problem from "search" to "discovery."

Scroll to Top
Visit more pages:
Go to the Work page for brendankelly:
Go to the About page for brendankelly:
Read Brendan’s Cisco Case Study:
Read Brendan’s ExxonMobil Case Study:
Read Brendan’s Panasonic Case Study:
Read Brendan’s Verizon Case Study:
Read Brendan’s RWJF Case Study:
Client
+24%
Demo-request conversions
1.8x
demo conversion upon opening new Details tab
+24 pts
SUS score improvement
22%
decrease of ‘Search’ first-click
RESEARCH
Reframing search as a discovery problem
Ran a competitive teardown, a qualitative study, and a heatmap audit to reframe the problem from "search" to "discovery."
DESIGN SYSTEM
Scalable IA & component system
Rebuilt the navigation, filtering, and category model, plus a reusable component library used across eight-plus page templates.
AI-ENABLEMENT
AI-accelerated prototyping
Used AI as a thinking partner, not a generator — pressure-testing buyer psychology, then prototyping the reframe in minutes, with full judgment over what shipped.
OUTCOMES
Measurable demo-conversion growth
Shifted the team from a lead-gen funnel to a product-led-growth model benchmarked against Atlassian, then shipped it, lifting demo-request conversion 24% in six months.
The Cisco Networking App Marketplace — recently rebranded from the Meraki Marketplace — is where customers and partners find pre-built integrations across Cisco's networking platforms. It's a large ecosystem: hundreds of partners and listings, tied to a meaningful share of Cisco's networking bookings.
But the site wasn't converting that scale into action. Demo requests, its core conversion event, had been flat for two years despite steady traffic, and usability testing scored it in "D" territory.
The search bar dominated the homepage, and heatmaps showed people defaulting to it early — but there was no visibility into what they were actually searching for. The hero offered nothing to act on, and category filters reflected internal taxonomy instead of user intent. Browsing never stood a real chance against search.
Once someone landed on a listing, they had to wade through marketing copy to find the facts — compatibility, deployment effort, support — that would actually let them decide. The one clear next step, requesting a demo, asked for a live conversation before most visitors had done enough self-directed evaluation to want one.

2025 Q4 - 2026 Q2
Agency: MRM
Client: Cisco Networking & Marketplace Team
Product, marketing, and partner/ecosystem leads
Cross-functional collaborators
UX Research, web platform engineering

One page from the comprehensive UX audit of the marketplace product
I performed a heuristic audit across Discover, Evaluate, and Convert, benchmarked the site against eight competitors, then checked the read against heatmaps and session replays. All three pointed to the same failure: a hero with nothing to click, filters built for our taxonomy instead of theirs, and traffic defaulting to search.
Why this approach
Stakeholders assumed this was a marketing problem. Triangulating three independent evidence sources — heuristic, competitive, behavioral — made the diagnosis hard to wave away as one designer's opinion.

The data showed a usability problem with the marketplace
Working with our UX researcher, I ran structured interviews and a controlled usability comparison. The live site scored a 52 on the SUS — a "D." A prototype that surfaced integrations inside the product dashboard scored in the 76th percentile. The gap wasn't the page. It was that most visitors didn't know they needed us.
Why this approach
A usability score alone invites debate about methodology. Pairing it with a head-to-head prototype comparison gave leadership something concrete to react to, not just a complaint.

Building a model to show why the problem is worth solving
A discovery problem doesn't get fixed by redesigning a page — it needs a different model. I pushed the team toward a product-led-growth framework benchmarked against Atlassian, replacing the funnel with an Evaluate → Activate → Adopt → Expand → Advocate journey, where a demo request became one option instead of the only door.
Why this approach
Leadership had no shared vocabulary for "why are demo requests flat." Naming an externally-validated model gave them something real to align around and a roadmap to actually plan against.

I rebuilt the homepage around intent-based browsing instead of search, and gave every app-detail page a Details panel with all the information they actually needed to make decisions: compatibility, deployment effort, support — plus a standardized carousel and a related-apps module. Before touching layout, I used AI to pressure-test buyer psychology, then prototyped that reframe in minutes to critique against our research.
The app detail template we began with buried important information and put too much work on marketplace partners.
The redesigned experience provided a resuable template that prioritized user-centric information hierarchy.
The research revealed one behavior that I believed was holding the entire experience back: people were not exploring. They relied heavily on Search because the marketplace gave them too few useful reasons to browse and learn. I anchored my solutions around changing that behavior, expecting it to improve several other KPIs. Turns out that was the right call.
Demo-request conversion
2.5%
3.1%
SUS Score
52
76.4
Homepage bounce rate
58%
49%
First-click ‘Search’
46%
36%
Demo-request conversion increased 24%.
Usability jumped from a D (52) to a B (76.4)
Homepage bounce rate fell 9 points
Search dependency eased from 46% to 36%
Details-tab visitors converted 1.8x more often

There's one thing I'd still go back and change: our own research showed people barely touched badges like Featured or Sustainability on the old site, and I let the team add more of them anyway on the theory that new categories deserve their own shot. Maybe they do. But I never forced the quick test that would've told us for sure before launch instead of after — and "probably fine" is a much easier thing to say in a roadmap meeting than to defend later.
Let’s get connected
Contact Brendan
View more work
See another project
Visit more pages:
Go to the Work page for brendankelly:
Go to the About page for brendankelly:
Read Brendan’s Cisco Case Study:
Read Brendan’s ExxonMobil Case Study:
Read Brendan’s Panasonic Case Study:
Read Brendan’s Verizon Case Study:
Read Brendan’s RWJF Case Study:

Let’s Connect
Client
+24%
Demo-request conversions
+24 pts
SUS score improvement
22%
decrease of ‘Search’ first-click
1.8x
demo conversion upon opening new Details tab
RESEARCH
Reframing search as a discovery problem
Ran a competitive teardown, a qualitative study, and a heatmap audit to reframe the problem from "search" to "discovery."
DESIGN SYSTEM
Scalable IA & component system
Rebuilt the navigation, filtering, and category model, plus a reusable component library used across eight-plus page templates.
AI-ENABLEMENT
AI-accelerated prototyping
Used AI as a thinking partner, not a generator — pressure-testing buyer psychology, then prototyping the reframe in minutes, with full judgment over what shipped.
OUTCOMES
Measurable demo-conversion growth
Shifted the team from a lead-gen funnel to a product-led-growth model benchmarked against Atlassian, then shipped it, lifting demo-request conversion 24% in six months.
The Cisco Networking App Marketplace — recently rebranded from the Meraki Marketplace — is where customers and partners find pre-built integrations across Cisco's networking platforms. It's a large ecosystem: hundreds of partners and listings, tied to a meaningful share of Cisco's networking bookings.
But the site wasn't converting that scale into action. Demo requests, its core conversion event, had been flat for two years despite steady traffic, and usability testing scored it in "D" territory.
The search bar dominated the homepage, and heatmaps showed people defaulting to it early — but there was no visibility into what they were actually searching for. The hero offered nothing to act on, and category filters reflected internal taxonomy instead of user intent. Browsing never stood a real chance against search.
Once someone landed on a listing, they had to wade through marketing copy to find the facts — compatibility, deployment effort, support — that would actually let them decide. The one clear next step, requesting a demo, asked for a live conversation before most visitors had done enough self-directed evaluation to want one.

Agency: MRM
Client: Cisco Networking & Marketplace Team
Product, marketing, and partner/ecosystem leads
Cross-functional collaborators
UX Research, web platform engineering
2025 Q4 - 2026 Q2

One screen from the comprehensive UX audit of the marketplace product
I performed a heuristic audit across Discover, Evaluate, and Convert, benchmarked the site against eight competitors, then checked the read against heatmaps and session replays. All three pointed to the same failure: a hero with nothing to click, filters built for our taxonomy instead of theirs, and traffic defaulting to search.
Why this approach
Stakeholders assumed this was a marketing problem. Triangulating three independent evidence sources — heuristic, competitive, behavioral — made the diagnosis hard to wave away as one designer's opinion.
Working with our UX researcher, I ran structured interviews and a controlled usability comparison. The live site scored a 52 on the SUS — a "D." A prototype that surfaced integrations inside the product dashboard scored in the 76th percentile. The gap wasn't the page. It was that most visitors didn't know they needed us.
Why this approach
A usability score alone invites debate about methodology. Pairing it with a head-to-head prototype comparison gave leadership something concrete to react to, not just a complaint.

The data showed a usability problem with the marketplace

Building a model to show why the problem is worth solving
A discovery problem doesn't get fixed by redesigning a page — it needs a different model. I pushed the team toward a product-led-growth framework benchmarked against Atlassian, replacing the funnel with an Evaluate → Activate → Adopt → Expand → Advocate journey, where a demo request became one option instead of the only door.
Why this approach
Leadership had no shared vocabulary for "why are demo requests flat." Naming an externally-validated model gave them something real to align around and a roadmap to actually plan against.

I rebuilt the homepage around intent-based browsing instead of search, and gave every app-detail page a Details panel with all the information they actually needed to make decisions: compatibility, deployment effort, support — plus a standardized carousel and a related-apps module. Before touching layout, I used AI to pressure-test buyer psychology, then prototyped that reframe in minutes to critique against our research.
The app detail template we began with buried important information and put too much work on marketplace partners.
The redesigned experience provided a resuable template that prioritized user-centric information hierarchy.
The research revealed one behavior that I believed was holding the entire experience back: people were not exploring. They relied heavily on Search because the marketplace gave them too few useful reasons to browse and learn. I anchored my solutions around changing that behavior, expecting it to improve several other KPIs. Turns out that was the right call.
Demo-request conversion
2.5%
3.1%
SUS Score
52
76.4
Homepage bounce rate
58%
49%
First-click ‘Search’
46%
36%
Demo-request conversion increased 24%.
Usability jumped from a D (52) to a B (76.4)
Homepage bounce rate fell 9 points
Search dependency eased from 46% to 36%
Details-tab visitors converted 1.8x more often

There's one thing I'd still go back and change: our own research showed people barely touched badges like Featured or Sustainability on the old site, and I let the team add more of them anyway on the theory that new categories deserve their own shot. Maybe they do. But I never forced the quick test that would've told us for sure before launch instead of after — and "probably fine" is a much easier thing to say in a roadmap meeting than to defend later.
Let’s get connected
Contact Brendan
View more work
See another project
Visit more pages:
Go to the Work page for brendankelly:
Go to the About page for brendankelly:
Read Brendan’s Cisco Case Study:
Read Brendan’s ExxonMobil Case Study:
Read Brendan’s Panasonic Case Study:
Read Brendan’s Verizon Case Study:
Read Brendan’s RWJF Case Study:

Let’s Connect
Client
+24%
Demo-request conversions
+24 pts
SUS score improvement
22%
decrease of ‘Search’ first-click
1.8x
demo conversion upon opening new Details tab
RESEARCH
Reframing search as a discovery problem
Ran a competitive teardown, a qualitative study, and a heatmap audit to reframe the problem from "search" to "discovery."
DESIGN SYSTEM
Scalable IA & component system
Rebuilt the navigation, filtering, and category model, plus a reusable component library used across eight-plus page templates.
AI-ENABLEMENT
AI-accelerated prototyping
Used AI as a thinking partner, not a generator — pressure-testing buyer psychology, then prototyping the reframe in minutes, with full judgment over what shipped.
OUTCOMES
Measurable demo-conversion growth
Shifted the team from a lead-gen funnel to a product-led-growth model benchmarked against Atlassian, then shipped it, lifting demo-request conversion 24% in six months.
The Cisco Networking App Marketplace — recently rebranded from the Meraki Marketplace — is where customers and partners find pre-built integrations across Cisco's networking platforms. It's a large ecosystem: hundreds of partners and listings, tied to a meaningful share of Cisco's networking bookings.
But the site wasn't converting that scale into action. Demo requests, its core conversion event, had been flat for two years despite steady traffic, and usability testing scored it in "D" territory.
The search bar dominated the homepage, and heatmaps showed people defaulting to it early — but there was no visibility into what they were actually searching for. The hero offered nothing to act on, and category filters reflected internal taxonomy instead of user intent. Browsing never stood a real chance against search.
Once someone landed on a listing, they had to wade through marketing copy to find the facts — compatibility, deployment effort, support — that would actually let them decide. The one clear next step, requesting a demo, asked for a live conversation before most visitors had done enough self-directed evaluation to want one.

Agency: MRM
Client: Cisco Networking & Marketplace Team
Product, marketing, and partner/ecosystem leads
Cross-functional collaborators
UX Research, web platform engineering
2025 Q4 - 2026 Q2

One screen from the comprehensive UX audit of the marketplace product
I performed a heuristic audit across Discover, Evaluate, and Convert, benchmarked the site against eight competitors, then checked the read against heatmaps and session replays. All three pointed to the same failure: a hero with nothing to click, filters built for our taxonomy instead of theirs, and traffic defaulting to search.
Stakeholders assumed this was a marketing problem. Triangulating three independent evidence sources — heuristic, competitive, behavioral — made the diagnosis hard to wave away as one designer's opinion.
Working with our UX researcher, I ran structured interviews and a controlled usability comparison. The live site scored a 52 on the SUS — a "D." A prototype that surfaced integrations inside the product dashboard scored in the 76th percentile. The gap wasn't the page. It was that most visitors didn't know they needed us.
Why this approach
A usability score alone invites debate about methodology. Pairing it with a head-to-head prototype comparison gave leadership something concrete to react to, not just a complaint.

The data showed a usability problem with the marketplace

Building a model to show why the problem is worth solving
A discovery problem doesn't get fixed by redesigning a page — it needs a different model. I pushed the team toward a product-led-growth framework benchmarked against Atlassian, replacing the funnel with an Evaluate → Activate → Adopt → Expand → Advocate journey, where a demo request became one option instead of the only door.
Why this approach
Leadership had no shared vocabulary for "why are demo requests flat." Naming an externally-validated model gave them something real to align around and a roadmap to actually plan against.

I rebuilt the homepage around intent-based browsing instead of search, and gave every app-detail page a Details panel with all the information they actually needed to make decisions: compatibility, deployment effort, support — plus a standardized carousel and a related-apps module.
The app detail template we began with buried important information and put too much work on marketplace partners.
The redesigned experience provided a reusable template that prioritized user-centric information hierarchy.
The research revealed one behavior that I believed was holding the entire experience back: people were not exploring. They relied heavily on Search because the marketplace gave them too few useful reasons to browse and learn. I anchored my solutions around changing that behavior, expecting it to improve several other KPIs. Turns out that was the right call.
Demo-request conversion
2.5%
3.1%
SUS Score
52
76.4
Homepage bounce rate
58%
49%
First-click ‘Search’
46%
36%
Demo-request conversion increased 24%.
Usability jumped from a D (52) to a B (76.4)
Homepage bounce rate fell 9 points
Search dependency eased from 46% to 36%
Details-tab visitors converted 1.8x more often

There's one thing I'd still go back and change: our own research showed people barely touched badges like Featured or Sustainability on the old site, and I let the team add more of them anyway on the theory that new categories deserve their own shot. Maybe they do. But I never forced the quick test that would've told us for sure before launch instead of after — and "probably fine" is a much easier thing to say in a roadmap meeting than to defend later.
Let’s get connected
Contact Brendan
View more work
See another project