Overview
Intel’s knowledge base had 50,000+ support articles written by hundreds of authors across different product lines over 15+ years. The content was solid, genuinely helpful technical information. The problem was that every team had customized the article template to fit their needs, creating a visual and structural mess.
I led the redesign to create a single, unified article template. But the real challenge wasn’t designing a better layout, it was convincing dozens of content teams to give up their customizations and adopt a standard.
My Role
Lead Product Designer on DX Team
I owned the template design and system architecture. But I spent more time building consensus than pushing pixels.
The Problem
The knowledge base looked like it had been designed by committee. Because it had been.
Different product teams had tweaked the article template over the years:
Some added custom alert boxes in different colors
Others created their own heading styles because they didn’t like the default
Desktop CPU support used different formatting than server documentation
Graphics card articles had different layouts than chipset articles
Some teams embedded videos, others just linked to them
Every customization made sense in isolation. The GPU team needed space for large technical diagrams. The driver team needed prominent download buttons. The troubleshooting team needed collapsible sections for long step-by-step procedures.
But for users trying to find answers across different Intel products, it was chaos. Each article looked and behaved differently. The cognitive load of reorienting yourself to a new layout every time you clicked a link was exhausting.
Meanwhile, content authors were frustrated too. Creating a new article meant either copying an existing one (perpetuating inconsistency) or building from scratch (wasting time). New writers had no guidance on formatting. Localization teams were translating dozens of different layouts into 12 languages.
The data that convinced leadership: users spent an average of 4.2 minutes reading articles that should have taken 90 seconds. Not because the content was bad, because they couldn’t scan it efficiently.
What actually happened
Everyone wanted exceptions
Each team had unique needs, charts, downloads, long guides. I pushed back on endless variations and created a single, modular template that worked for 80% of cases. When requirements were legitimate, I solved them through scalable components instead of custom layouts.
Designed for constraints, not perfection
Balancing engineering’s need for simplicity with content teams’ desire for freedom, I made the system more opinionated: clear hierarchy, consistent spacing, standardized modules. The result was flexible where it mattered, consistent where it counted.
Hidden Salesforce dependency
Midway through, I discovered 40% of articles were auto-generated from Salesforce data. I created two visually consistent templates, one modular for authored content, one structured for automated content so the experience stayed seamless across both systems.
Readability and accessibility raised the bar
Readability testing proved Intel’s default typography struggled for long technical content. I negotiated spacing and line-height exceptions, then addressed 40+ accessibility issues that ultimately improved clarity, hierarchy and authoring consistency for everyone.
Adoption proved the system worked
We launched with 200 pilot articles, users found answers faster, bounce rates dropped and localization teams became champions. Six months later, 85% of new articles used the new template, with migration of 50,000 legacy articles.
Results
50K+ articles in the system (though full migration is still in progress)
Time-on-page decreased 35% (users finding answers faster)
99 Lighthouse accessibility score
100 Best Practices score, 92 SEO score
Content authoring time reduced by ~20% according to content ops surveys
Unified template became the standard for all Intel technical documentation, not just support articles
Localization costs decreased (fewer template variations to translate)
Some legacy articles still haven’t been migrated. Content teams prioritize new content over updating old articles. This creates inconsistency that bothers me, but I’ve had to accept it’s a resource constraint, not a design problem.
What I learned
Designing at scale means designing for adoption, not just usability.
The template could have been perfect, but if content authors refused to use it, it would fail. Half my job was change management, understanding why teams customized their articles, respecting their needs and showing them how the new system could work better for them.
I also learned that constraints aren’t the enemy of good design, they’re the foundation. By being opinionated about structure, typography and components, we created consistency that paradoxically gave authors more freedom. They could focus on content instead of formatting decisions.
The biggest lesson: users don’t care about your design system. They care about finding answers. The template succeeded not because it was beautiful (it was though), but because it made 50,000 articles feel like one coherent knowledge base instead of 50,000 individual documents.
Design systems are only valuable if they serve the people who use them, both the end users reading articles and the authors creating them. This project worked because we optimized for both.
Have a design challenge? I'd love to help solve it.
Overview
Intel’s knowledge base had 50,000+ support articles written by hundreds of authors across different product lines over 15+ years. The content was solid, genuinely helpful technical information. The problem was that every team had customized the article template to fit their needs, creating a visual and structural mess.
I led the redesign to create a single, unified article template. But the real challenge wasn’t designing a better layout, it was convincing dozens of content teams to give up their customizations and adopt a standard.
My Role
Lead Product Designer on DX Team
I owned the template design and system architecture. But I spent more time building consensus than pushing pixels.
The Problem
The knowledge base looked like it had been designed by committee. Because it had been.
Different product teams had tweaked the article template over the years:
Some added custom alert boxes in different colors
Others created their own heading styles because they didn’t like the default
Desktop CPU support used different formatting than server documentation
Graphics card articles had different layouts than chipset articles
Some teams embedded videos, others just linked to them
Every customization made sense in isolation. The GPU team needed space for large technical diagrams. The driver team needed prominent download buttons. The troubleshooting team needed collapsible sections for long step-by-step procedures.
But for users trying to find answers across different Intel products, it was chaos. Each article looked and behaved differently. The cognitive load of reorienting yourself to a new layout every time you clicked a link was exhausting.
Meanwhile, content authors were frustrated too. Creating a new article meant either copying an existing one (perpetuating inconsistency) or building from scratch (wasting time). New writers had no guidance on formatting. Localization teams were translating dozens of different layouts into 12 languages.
The data that convinced leadership: users spent an average of 4.2 minutes reading articles that should have taken 90 seconds. Not because the content was bad, because they couldn’t scan it efficiently.
What actually happened
Everyone wanted exceptions
Each team had unique needs, charts, downloads, long guides. I pushed back on endless variations and created a single, modular template that worked for 80% of cases. When requirements were legitimate, I solved them through scalable components instead of custom layouts.
Designed for constraints, not perfection
Balancing engineering’s need for simplicity with content teams’ desire for freedom, I made the system more opinionated: clear hierarchy, consistent spacing, standardized modules. The result was flexible where it mattered, consistent where it counted.
Hidden Salesforce dependency
Midway through, I discovered 40% of articles were auto-generated from Salesforce data. I created two visually consistent templates, one modular for authored content, one structured for automated content so the experience stayed seamless across both systems.
Readability and accessibility raised the bar
Readability testing proved Intel’s default typography struggled for long technical content. I negotiated spacing and line-height exceptions, then addressed 40+ accessibility issues that ultimately improved clarity, hierarchy and authoring consistency for everyone.
Adoption proved the system worked
We launched with 200 pilot articles, users found answers faster, bounce rates dropped and localization teams became champions. Six months later, 85% of new articles used the new template, with migration of 50,000 legacy articles.
Results
50K+ articles in the system (though full migration is still in progress)
Time-on-page decreased 35% (users finding answers faster)
99 Lighthouse accessibility score
100 Best Practices score, 92 SEO score
Content authoring time reduced by ~20% according to content ops surveys
Unified template became the standard for all Intel technical documentation, not just support articles
Localization costs decreased (fewer template variations to translate)
Some legacy articles still haven’t been migrated. Content teams prioritize new content over updating old articles. This creates inconsistency that bothers me, but I’ve had to accept it’s a resource constraint, not a design problem.
What I learned
Designing at scale means designing for adoption, not just usability.
The template could have been perfect, but if content authors refused to use it, it would fail. Half my job was change management, understanding why teams customized their articles, respecting their needs and showing them how the new system could work better for them.
I also learned that constraints aren’t the enemy of good design, they’re the foundation. By being opinionated about structure, typography and components, we created consistency that paradoxically gave authors more freedom. They could focus on content instead of formatting decisions.
The biggest lesson: users don’t care about your design system. They care about finding answers. The template succeeded not because it was beautiful (it was though), but because it made 50,000 articles feel like one coherent knowledge base instead of 50,000 individual documents.
Design systems are only valuable if they serve the people who use them, both the end users reading articles and the authors creating them. This project worked because we optimized for both.
Overview
Intel’s knowledge base had 50,000+ support articles written by hundreds of authors across different product lines over 15+ years. The content was solid, genuinely helpful technical information. The problem was that every team had customized the article template to fit their needs, creating a visual and structural mess.
I led the redesign to create a single, unified article template. But the real challenge wasn’t designing a better layout, it was convincing dozens of content teams to give up their customizations and adopt a standard.
My Role
Lead Product Designer on DX Team
I owned the template design and system architecture. But I spent more time building consensus than pushing pixels.
The Problem
The knowledge base looked like it had been designed by committee. Because it had been.
Different product teams had tweaked the article template over the years:
Some added custom alert boxes in different colors
Others created their own heading styles because they didn’t like the default
Desktop CPU support used different formatting than server documentation
Graphics card articles had different layouts than chipset articles
Some teams embedded videos, others just linked to them
Every customization made sense in isolation. The GPU team needed space for large technical diagrams. The driver team needed prominent download buttons. The troubleshooting team needed collapsible sections for long step-by-step procedures.
But for users trying to find answers across different Intel products, it was chaos. Each article looked and behaved differently. The cognitive load of reorienting yourself to a new layout every time you clicked a link was exhausting.
Meanwhile, content authors were frustrated too. Creating a new article meant either copying an existing one (perpetuating inconsistency) or building from scratch (wasting time). New writers had no guidance on formatting. Localization teams were translating dozens of different layouts into 12 languages.
The data that convinced leadership: users spent an average of 4.2 minutes reading articles that should have taken 90 seconds. Not because the content was bad, because they couldn’t scan it efficiently.
What actually happened
Everyone wanted exceptions
Each team had unique needs, charts, downloads, long guides. I pushed back on endless variations and created a single, modular template that worked for 80% of cases. When requirements were legitimate, I solved them through scalable components instead of custom layouts.
Designed for constraints, not perfection
Balancing engineering’s need for simplicity with content teams’ desire for freedom, I made the system more opinionated: clear hierarchy, consistent spacing, standardized modules. The result was flexible where it mattered, consistent where it counted.
Hidden Salesforce dependency
Midway through, I discovered 40% of articles were auto-generated from Salesforce data. I created two visually consistent templates, one modular for authored content, one structured for automated content so the experience stayed seamless across both systems.
Readability and accessibility raised the bar
Readability testing proved Intel’s default typography struggled for long technical content. I negotiated spacing and line-height exceptions, then addressed 40+ accessibility issues that ultimately improved clarity, hierarchy and authoring consistency for everyone.
Adoption proved the system worked
We launched with 200 pilot articles, users found answers faster, bounce rates dropped and localization teams became champions. Six months later, 85% of new articles used the new template, with migration of 50,000 legacy articles.
Results
50K+ articles in the system (though full migration is still in progress)
Time-on-page decreased 35% (users finding answers faster)
99 Lighthouse accessibility score
100 Best Practices score, 92 SEO score
Content authoring time reduced by ~20% according to content ops surveys
Unified template became the standard for all Intel technical documentation, not just support articles
Localization costs decreased (fewer template variations to translate)
Some legacy articles still haven’t been migrated. Content teams prioritize new content over updating old articles. This creates inconsistency that bothers me, but I’ve had to accept it’s a resource constraint, not a design problem.
What I learned
Designing at scale means designing for adoption, not just usability.
The template could have been perfect, but if content authors refused to use it, it would fail. Half my job was change management, understanding why teams customized their articles, respecting their needs and showing them how the new system could work better for them.
I also learned that constraints aren’t the enemy of good design, they’re the foundation. By being opinionated about structure, typography and components, we created consistency that paradoxically gave authors more freedom. They could focus on content instead of formatting decisions.
The biggest lesson: users don’t care about your design system. They care about finding answers. The template succeeded not because it was beautiful (it was though), but because it made 50,000 articles feel like one coherent knowledge base instead of 50,000 individual documents.
Design systems are only valuable if they serve the people who use them, both the end users reading articles and the authors creating them. This project worked because we optimized for both.
Overview
Intel’s knowledge base had 50,000+ support articles written by hundreds of authors across different product lines over 15+ years. The content was solid, genuinely helpful technical information. The problem was that every team had customized the article template to fit their needs, creating a visual and structural mess.
I led the redesign to create a single, unified article template. But the real challenge wasn’t designing a better layout, it was convincing dozens of content teams to give up their customizations and adopt a standard.
My Role
Lead Product Designer on DX Team
I owned the template design and system architecture. But I spent more time building consensus than pushing pixels.
The Problem
The knowledge base looked like it had been designed by committee. Because it had been.
Different product teams had tweaked the article template over the years:
Some added custom alert boxes in different colors
Others created their own heading styles because they didn’t like the default
Desktop CPU support used different formatting than server documentation
Graphics card articles had different layouts than chipset articles
Some teams embedded videos, others just linked to them
Every customization made sense in isolation. The GPU team needed space for large technical diagrams. The driver team needed prominent download buttons. The troubleshooting team needed collapsible sections for long step-by-step procedures.
But for users trying to find answers across different Intel products, it was chaos. Each article looked and behaved differently. The cognitive load of reorienting yourself to a new layout every time you clicked a link was exhausting.
Meanwhile, content authors were frustrated too. Creating a new article meant either copying an existing one (perpetuating inconsistency) or building from scratch (wasting time). New writers had no guidance on formatting. Localization teams were translating dozens of different layouts into 12 languages.
The data that convinced leadership: users spent an average of 4.2 minutes reading articles that should have taken 90 seconds. Not because the content was bad, because they couldn’t scan it efficiently.
What actually happened
Everyone wanted exceptions
Each team had unique needs, charts, downloads, long guides. I pushed back on endless variations and created a single, modular template that worked for 80% of cases. When requirements were legitimate, I solved them through scalable components instead of custom layouts.
Designed for constraints, not perfection
Balancing engineering’s need for simplicity with content teams’ desire for freedom, I made the system more opinionated: clear hierarchy, consistent spacing, standardized modules. The result was flexible where it mattered, consistent where it counted.
Hidden Salesforce dependency
Midway through, I discovered 40% of articles were auto-generated from Salesforce data. I created two visually consistent templates, one modular for authored content, one structured for automated content so the experience stayed seamless across both systems.
Readability and accessibility raised the bar
Readability testing proved Intel’s default typography struggled for long technical content. I negotiated spacing and line-height exceptions, then addressed 40+ accessibility issues that ultimately improved clarity, hierarchy and authoring consistency for everyone.
Adoption proved the system worked
We launched with 200 pilot articles, users found answers faster, bounce rates dropped and localization teams became champions. Six months later, 85% of new articles used the new template, with migration of 50,000 legacy articles.
Results
50K+ articles in the system (though full migration is still in progress)
Time-on-page decreased 35% (users finding answers faster)
99 Lighthouse accessibility score
100 Best Practices score, 92 SEO score
Content authoring time reduced by ~20% according to content ops surveys
Unified template became the standard for all Intel technical documentation, not just support articles
Localization costs decreased (fewer template variations to translate)
Some legacy articles still haven’t been migrated. Content teams prioritize new content over updating old articles. This creates inconsistency that bothers me, but I’ve had to accept it’s a resource constraint, not a design problem.
What I learned
Designing at scale means designing for adoption, not just usability.
The template could have been perfect, but if content authors refused to use it, it would fail. Half my job was change management, understanding why teams customized their articles, respecting their needs and showing them how the new system could work better for them.
I also learned that constraints aren’t the enemy of good design, they’re the foundation. By being opinionated about structure, typography and components, we created consistency that paradoxically gave authors more freedom. They could focus on content instead of formatting decisions.
The biggest lesson: users don’t care about your design system. They care about finding answers. The template succeeded not because it was beautiful (it was though), but because it made 50,000 articles feel like one coherent knowledge base instead of 50,000 individual documents.
Design systems are only valuable if they serve the people who use them, both the end users reading articles and the authors creating them. This project worked because we optimized for both.
Overview
Intel’s knowledge base had 50,000+ support articles written by hundreds of authors across different product lines over 15+ years. The content was solid, genuinely helpful technical information. The problem was that every team had customized the article template to fit their needs, creating a visual and structural mess.
I led the redesign to create a single, unified article template. But the real challenge wasn’t designing a better layout, it was convincing dozens of content teams to give up their customizations and adopt a standard.
My Role
Lead Product Designer on DX Team
I owned the template design and system architecture. But I spent more time building consensus than pushing pixels.
The Problem
The knowledge base looked like it had been designed by committee. Because it had been.
Different product teams had tweaked the article template over the years:
Some added custom alert boxes in different colors
Others created their own heading styles because they didn’t like the default
Desktop CPU support used different formatting than server documentation
Graphics card articles had different layouts than chipset articles
Some teams embedded videos, others just linked to them
Every customization made sense in isolation. The GPU team needed space for large technical diagrams. The driver team needed prominent download buttons. The troubleshooting team needed collapsible sections for long step-by-step procedures.
But for users trying to find answers across different Intel products, it was chaos. Each article looked and behaved differently. The cognitive load of reorienting yourself to a new layout every time you clicked a link was exhausting.
Meanwhile, content authors were frustrated too. Creating a new article meant either copying an existing one (perpetuating inconsistency) or building from scratch (wasting time). New writers had no guidance on formatting. Localization teams were translating dozens of different layouts into 12 languages.
The data that convinced leadership: users spent an average of 4.2 minutes reading articles that should have taken 90 seconds. Not because the content was bad, because they couldn’t scan it efficiently.
What actually happened
Everyone wanted exceptions
Each team had unique needs, charts, downloads, long guides. I pushed back on endless variations and created a single, modular template that worked for 80% of cases. When requirements were legitimate, I solved them through scalable components instead of custom layouts.
Designed for constraints, not perfection
Balancing engineering’s need for simplicity with content teams’ desire for freedom, I made the system more opinionated: clear hierarchy, consistent spacing, standardized modules. The result was flexible where it mattered, consistent where it counted.
Hidden Salesforce dependency
Midway through, I discovered 40% of articles were auto-generated from Salesforce data. I created two visually consistent templates, one modular for authored content, one structured for automated content so the experience stayed seamless across both systems.
Readability and accessibility raised the bar
Readability testing proved Intel’s default typography struggled for long technical content. I negotiated spacing and line-height exceptions, then addressed 40+ accessibility issues that ultimately improved clarity, hierarchy and authoring consistency for everyone.
Adoption proved the system worked
We launched with 200 pilot articles, users found answers faster, bounce rates dropped and localization teams became champions. Six months later, 85% of new articles used the new template, with migration of 50,000 legacy articles.
Results
50K+ articles in the system (though full migration is still in progress)
Time-on-page decreased 35% (users finding answers faster)
99 Lighthouse accessibility score
100 Best Practices score, 92 SEO score
Content authoring time reduced by ~20% according to content ops surveys
Unified template became the standard for all Intel technical documentation, not just support articles
Localization costs decreased (fewer template variations to translate)
Some legacy articles still haven’t been migrated. Content teams prioritize new content over updating old articles. This creates inconsistency that bothers me, but I’ve had to accept it’s a resource constraint, not a design problem.
What I learned
Designing at scale means designing for adoption, not just usability.
The template could have been perfect, but if content authors refused to use it, it would fail. Half my job was change management, understanding why teams customized their articles, respecting their needs and showing them how the new system could work better for them.
I also learned that constraints aren’t the enemy of good design, they’re the foundation. By being opinionated about structure, typography and components, we created consistency that paradoxically gave authors more freedom. They could focus on content instead of formatting decisions.
The biggest lesson: users don’t care about your design system. They care about finding answers. The template succeeded not because it was beautiful (it was though), but because it made 50,000 articles feel like one coherent knowledge base instead of 50,000 individual documents.
Design systems are only valuable if they serve the people who use them, both the end users reading articles and the authors creating them. This project worked because we optimized for both.