Back to Work
Enterprise Resource Portal Redesign
Qualcomm
Re-architecting a fragmented resource ecosystem for engineers and procurement teams
Executive Summary
Qualcomm's CreatePoint portal served engineers and purchasing managers across a dense, multi-role resource ecosystem: chip documentation, testing tools, security patches, software updates, support, and pre-purchase product information. Its architecture reflected internal content ownership rather than how users actually navigated it. Engineers lost product context when moving between sections, search lacked the filtering depth the documentation density required, and purchasing managers had no consolidated entry point for product evaluation.
I led the structural re-architecture over sixteen months, defining persistent product filtering, faceted search, and centralized Product Overview pages. Delivery was sequenced to prioritize global navigation and filtering before layered feature releases, establishing a stable structural foundation before introducing search improvements and the rebrand, so that shifting stakeholder priorities did not destabilize the architecture already in production.
Legacy Navigation vs Redesigned Experience
Legacy Navigation
Redesigned Experience
Measured Impact
Persistent product-level filtering deployed across the portalPreserved product context for engineers, eliminating the primary navigation failure mode.
Centralized Product Overview pages consolidating tools, docs, and supportSingle entry point per product replacing fragmented access across the portal.
Enhanced faceted search architectureEnabled scoped, role-specific discovery, closing the filtering depth gap for precision queries.
Phased rollout maintaining architectural continuity across 16 monthsEach phase built on the previous, allowing scope changes without re-architecture.
Overview
CreatePoint is Qualcomm's enterprise portal for suppliers and partners, serving engineers and purchasing managers across a dense multi-role resource ecosystem.
The site's information architecture grouped content by type, reflecting how internal teams owned and published content rather than how either user group actually navigated it.
These were not interface problems. They were structural problems. The architecture itself was misaligned with how the two primary user groups navigated the site.
- Supported Devices: Desktop and browser-based (responsive)
- Timeline: Jun 2017 – Oct 2018
- Primary Audience: Developers, engineers, product managers, purchasing managers, internal Qualcomm teams
Discovery
Portal Audit and Workflow Mapping
I conducted a full portal audit before working with the Creative Director in structured whiteboarding sessions to map product data structures against real engineering and procurement workflows. The audit established the content inventory and identified where the navigation taxonomy broke down relative to user navigation patterns. The whiteboard sessions translated that inventory into workflow maps, tracing how an engineer navigating a chip's documentation actually moved through the site versus how the architecture assumed they would.
This exposed the core misalignment: the portal was organized by content type, but both user groups navigated by product.
The joint analysis with the Creative Director also surfaced the two distinct mental models the architecture needed to support simultaneously: engineers needed focused access to a single product at a time with product context persistent across navigation; purchasing managers needed broad exploration, cross-product comparison, and the ability to evaluate a product end to end from a single starting point. The existing architecture could not support either model well, let alone both.
Workflow Misalignment Map
Whiteboard synthesis mapping documentation structure against engineering and procurement workflows, revealing structural gaps.
Key User Workflows
- Product owners (engineers): Quick access to relevant product resources without unrelated noise
- Prospective buyers (purchasing managers): Broad exploration, cross-product comparison, and deep dives
Design
Concept Exploration and Ideation
Working iteratively with the Creative Director, I explored structural solutions through sketches and whiteboard modeling before moving to high fidelity. The filtering model went through several iterations testing how product context should be represented persistently across different section types: whether filtering should live in the navigation, in a persistent panel, or as a page-level control. The persistent panel model was validated at low fidelity before engineering resources were committed, which was important given the broad scope of the architectural change.
Persistent Product Filtering
Explored a site-wide persistent filter that could carry product context across navigation, search, and documentation. This eliminated the noise engineers encountered when moving between sections.
Enhanced Faceted Search
Evaluated search architectures that could support scoped, role-specific discovery within dense documentation. Iterations tested filter hierarchy models, facet presentation, and the interaction cost of precision at varying documentation depths.
Product Overview Page
Consolidated fragmented tools, documentation, and support resources into a unified product-level entry point. This required balancing competing priorities between engineering quick access and buyer exploration.
Information Architecture & System Model
- Re-architected the global navigation taxonomy to reflect how engineers and purchasing managers actually move through the portal - grouping by product line rather than content type, and establishing persistent product context as a first-class element of the navigation model.
- Introduced persistent product filtering to reduce content noise across the entire portal.
- Designed enhanced faceted search to enable scoped, role-specific discovery.
- Created centralized Product Overview pages to consolidate tools, documentation, and support resources under a single product-aligned entry point.
Centralized Product Overview Page
Product-level entry point consolidating tools, documentation, and support resources under aligned taxonomy and persistent filtering.
Brand System
Applied updated Qualcomm brand guidelines across templates, header, navigation, and search. Established scalable components using shared Sketch libraries to ensure the component system could support both the structural redesign and the rebrand rollout within a single maintainable library.
Production
Delivery and Stakeholder Management
Sequenced launches to prioritize global layout and persistent filtering before layered feature releases, with the rebrand last so it could be applied to a stable system without disrupting functionality. Stakeholder feature requests that arrived out of sequence were not rejected - they were evaluated against the delivery dependency map and either sequenced appropriately or held with an explicit explanation of what inserting them early would cost.
Decisions & Trade-offs
- One Product Overview Page vs. Separate Pages per User Type: Separate entry points would have been cleaner to design individually. A single page was chosen because the portal had no role-detection mechanism that could reliably route users, and splitting the entry point would have required purchasing managers to know which section to navigate to: the original problem.
- Shared Sketch Libraries vs. Phase-Specific Files: Phase-specific files would have been faster to manage within each phase. A shared library required more coordination but prevented divergence. Without it, the rebrand would have required retrofitting every component produced in earlier phases rather than updating a single source.
- Accommodating vs. Sequencing Stakeholder Feature Requests: The architecture held across sixteen months because the sequencing rationale was transparent and shared with stakeholders, not because scope was fixed. Every request was evaluated against the dependency map. None were rejected outright - they were placed where they would not destabilize what was already in production.
Synthesis
The decisions that mattered most in this engagement were about sequencing: what had to be established before anything else could be built on it, and what could be deferred without creating rework. That discipline - not any individual design decision - is what kept sixteen months of shifting priorities from fragmenting the architecture.
Persistent filtering was load-bearing. It was not the most visible change, and it was not the one stakeholders were most interested in. But every other improvement (search precision, product evaluation, and the rebrand) depended on the product context model it established. Identifying that dependency early, defending the sequence, and building each phase on a stable foundation rather than in response to request order was what made a sixteen-month engagement deliver a coherent system rather than a collection of incremental changes.
Back to Work
Back to Work
Enterprise Resource Portal Redesign
Qualcomm
Re-architecting a fragmented resource ecosystem for engineers and procurement teams
Executive Summary
Qualcomm's CreatePoint portal served engineers and purchasing managers across a dense, multi-role resource ecosystem: chip documentation, testing tools, security patches, software updates, support, and pre-purchase product information. Its architecture reflected internal content ownership rather than how users actually navigated it. Engineers lost product context when moving between sections, search lacked the filtering depth the documentation density required, and purchasing managers had no consolidated entry point for product evaluation.
I led the structural re-architecture over sixteen months, defining persistent product filtering, faceted search, and centralized Product Overview pages. Delivery was sequenced to prioritize global navigation and filtering before layered feature releases, establishing a stable structural foundation before introducing search improvements and the rebrand, so that shifting stakeholder priorities did not destabilize the architecture already in production.
Legacy Navigation vs Redesigned Experience
Legacy Navigation
Redesigned Experience
Overview
CreatePoint is Qualcomm's enterprise portal for suppliers and partners, serving engineers and purchasing managers across a dense multi-role resource ecosystem.
The site's information architecture grouped content by type, reflecting how internal teams owned and published content rather than how either user group actually navigated it.
These were not interface problems. They were structural problems. The architecture itself was misaligned with how the two primary user groups navigated the site.
- Supported Devices: Desktop and browser-based (responsive)
- Timeline: Jun 2017 – Oct 2018
- Primary Audience: Developers, engineers, product managers, purchasing managers, internal Qualcomm teams
Discovery
Portal Audit and Workflow Mapping
I conducted a full portal audit before working with the Creative Director in structured whiteboarding sessions to map product data structures against real engineering and procurement workflows. The audit established the content inventory and identified where the navigation taxonomy broke down relative to user navigation patterns. The whiteboard sessions translated that inventory into workflow maps, tracing how an engineer navigating a chip's documentation actually moved through the site versus how the architecture assumed they would.
This exposed the core misalignment: the portal was organized by content type, but both user groups navigated by product.
The joint analysis with the Creative Director also surfaced the two distinct mental models the architecture needed to support simultaneously: engineers needed focused access to a single product at a time with product context persistent across navigation; purchasing managers needed broad exploration, cross-product comparison, and the ability to evaluate a product end to end from a single starting point. The existing architecture could not support either model well, let alone both.
Workflow Misalignment Map
Whiteboard synthesis mapping documentation structure against engineering and procurement workflows, revealing structural gaps.
Key User Workflows
- Product owners (engineers): Quick access to relevant product resources without unrelated noise
- Prospective buyers (purchasing managers): Broad exploration, cross-product comparison, and deep dives
Design
Concept Exploration and Ideation
Working iteratively with the Creative Director, I explored structural solutions through sketches and whiteboard modeling before moving to high fidelity. The filtering model went through several iterations testing how product context should be represented persistently across different section types: whether filtering should live in the navigation, in a persistent panel, or as a page-level control. The persistent panel model was validated at low fidelity before engineering resources were committed, which was important given the broad scope of the architectural change.
Persistent Product Filtering
Explored a site-wide persistent filter that could carry product context across navigation, search, and documentation. This eliminated the noise engineers encountered when moving between sections.
Enhanced Faceted Search
Evaluated search architectures that could support scoped, role-specific discovery within dense documentation. Iterations tested filter hierarchy models, facet presentation, and the interaction cost of precision at varying documentation depths.
Product Overview Page
Consolidated fragmented tools, documentation, and support resources into a unified product-level entry point. This required balancing competing priorities between engineering quick access and buyer exploration.
Information Architecture & System Model
- Re-architected the global navigation taxonomy to reflect how engineers and purchasing managers actually move through the portal - grouping by product line rather than content type, and establishing persistent product context as a first-class element of the navigation model.
- Introduced persistent product filtering to reduce content noise across the entire portal.
- Designed enhanced faceted search to enable scoped, role-specific discovery.
- Created centralized Product Overview pages to consolidate tools, documentation, and support resources under a single product-aligned entry point.
Centralized Product Overview Page
Product-level entry point consolidating tools, documentation, and support resources under aligned taxonomy and persistent filtering.
Brand System
Applied updated Qualcomm brand guidelines across templates, header, navigation, and search. Established scalable components using shared Sketch libraries to ensure the component system could support both the structural redesign and the rebrand rollout within a single maintainable library.
Production
Delivery and Stakeholder Management
Sequenced launches to prioritize global layout and persistent filtering before layered feature releases, with the rebrand last so it could be applied to a stable system without disrupting functionality. Stakeholder feature requests that arrived out of sequence were not rejected - they were evaluated against the delivery dependency map and either sequenced appropriately or held with an explicit explanation of what inserting them early would cost.
Decisions & Trade-offs
- One Product Overview Page vs. Separate Pages per User Type: Separate entry points would have been cleaner to design individually. A single page was chosen because the portal had no role-detection mechanism that could reliably route users, and splitting the entry point would have required purchasing managers to know which section to navigate to: the original problem.
- Shared Sketch Libraries vs. Phase-Specific Files: Phase-specific files would have been faster to manage within each phase. A shared library required more coordination but prevented divergence. Without it, the rebrand would have required retrofitting every component produced in earlier phases rather than updating a single source.
- Accommodating vs. Sequencing Stakeholder Feature Requests: The architecture held across sixteen months because the sequencing rationale was transparent and shared with stakeholders, not because scope was fixed. Every request was evaluated against the dependency map. None were rejected outright - they were placed where they would not destabilize what was already in production.
Synthesis
The decisions that mattered most in this engagement were about sequencing: what had to be established before anything else could be built on it, and what could be deferred without creating rework. That discipline - not any individual design decision - is what kept sixteen months of shifting priorities from fragmenting the architecture.
Persistent filtering was load-bearing. It was not the most visible change, and it was not the one stakeholders were most interested in. But every other improvement (search precision, product evaluation, and the rebrand) depended on the product context model it established. Identifying that dependency early, defending the sequence, and building each phase on a stable foundation rather than in response to request order was what made a sixteen-month engagement deliver a coherent system rather than a collection of incremental changes.
Back to Work
Measured Impact
Persistent product-level filtering deployed across the portalPreserved product context for engineers, eliminating the primary navigation failure mode.
Centralized Product Overview pages consolidating tools, docs, and supportSingle entry point per product replacing fragmented access across the portal.
Enhanced faceted search architectureEnabled scoped, role-specific discovery, closing the filtering depth gap for precision queries.
Phased rollout maintaining architectural continuity across 16 monthsEach phase built on the previous, allowing scope changes without re-architecture.