Creating an internal product knowledge base
About the importance of looking inward when designing within constraints
Role
In a nutshell
Background
Previous research revealed that users struggled to explore, compare, and find the right products within the company's online shop. The most critical gap in the pre-purchase experience was the absence of intermediary information between the user's initial product search and the product detail page (PDP).
Approach #1
We audited the existing web shop experience, benchmarking it against Baymard's B2B eCommerce guidelines and key competitors. Based on this analysis, we proposed several design concepts, such as product family pages to better support comparison.
Iteration and approach #2
When presenting our designs, stakeholder reactions were reserved. Through follow-up discussions, we learned that most of our proposed ideas were not feasible. The bottleneck was the existing product data structure. For example, many base products were stored as standalone entries, making it impossible to dynamically link accessories, consumables, or related products.
We therefore paused our plans for concept testing and shifted our focus inward.
Results
We developed a product knowledge template to systematically capture and structure product information. The template functioned as an internal knowledge base – mapping a product line within workflows and broader product ecosystems, illustrating product relationships, and documenting relevant use cases.
In close collaboration with stakeholders, we iteratively refined the template and piloted it across two selected product areas.
Meta
This project demonstrated that best practices and established UX patterns should never serve as the sole reference point when designing new solutions. Yes, external benchmarks provide valuable orientation – but they should not be treated as the universal solution. Instead, external knowledge must be evaluated against internal structures, constraints, and product realities.
As UX designers, I believe it's our responsibility to develop that internal perspective. Understanding the systems, products, and services we design for allows us to better gauge feasibility and anticipate implementation challenges. It also enables us to lead stakeholder conversations with greater clarity and confidence.
And this process can be rewarding, too! When I approached our internal stakeholders, I openly acknowledged that the UX team lacked sufficient product understanding to make informed design decisions. This transparency fostered collaboration: Scientists and product managers were eager to share their expertise, open up on frustrations, and proactively contributed ideas. And all along, the template became more than a documentation tool – it structured the dialogue and created a shared understanding.
Although I did not see the initiative through to completion, the project reaffirmed the value of participatory design for me. While this philosophy and its core principles played a central role during my studies, I was reminded how easily such principles fade in the fast-pacedness of the industry and day-to-day delivery. With some distance, I now ask myself: how much further could this initiative have evolved if we had facilitated co-creation workshops with internal stakeholders and end users?