Product design projects involve many moving parts. Between design requirements, roadmaps, research findings, and documentation, information can become scattered. Without a central source of truth, teams can waste valuable time tracking down the latest updates.
Enter the design wiki—a shared, structured knowledge base that consolidates key information in one place. Instead of information being buried in Figma comments, Miro boards, Slack threads, or Jira tickets, a design wiki provides a centralized, navigable resource for teams to collaborate efficiently.
What is a Design Wiki?
A wiki is defined as “a website that allows collaborative editing of its content and structure by its users.” Let’s break that down. For a design team, the website could be a shared workspace in a tool like Notion, Confluence, Dovetail, or even Google Drive. Collaborative editing means various people can contribute to and edit the content in this workspace, which can get messy fast.
That’s why it’s crucial to keep content well-organized. A good rule of thumb is to structure your design wiki around the four P’s:
- Product
- Project
- People
- Process
A Key Rule: No Information Is Too Basic
Your design wiki is effective when a new hire can get up to speed by browsing it. Include even the most fundamental details—what may seem obvious to a seasoned team member might be invaluable to a newcomer.
Product
The Product section should answer all foundational questions about the product your team is designing. This ensures everyone—from designers to stakeholders—shares a common understanding.
Key Questions:
- What is the product?
- What is it called?
- What kind of product is it? (App, website, platform, etc.)
- What is its purpose?
- Who are the users?
- How does it function?
- What are the key performance indicators (KPIs)?
- How does this product align with business goals?
- What is the long-term vision for this product?
Project
The Project section should detail the specific design effort underway. While it’s tempting to mix project details with product information, keeping them distinct ensures clarity and organization, which is a key component of Pragmatic Design.
Key Questions:
- What is this project’s scope and objectives?
- How will it impact the product?
- What constraints or limitations exist?
- When did the project start, and when is it expected to conclude?
- What does the roadmap look like?
- How is progress tracked and reported?
People
Your People section should outline roles and responsibilities so team members can easily identify who to contact.
Key Questions:
- Who is working on this project? (Include names, pronouns, time zones, titles, and contact details.)
- Who are the decision-makers?
- What does the team structure look like? (Include an org chart if possible.)
- What are preferred communication methods?
- What tools and methods are used for async communication?
- Where are meeting notes and agendas stored?
Pro Tip: Reduce Information Redundancy
Instead of duplicating content that exists elsewhere, link out to relevant sources. For example, if mood boards are stored in Figma, include a link to the file rather than uploading static screenshots. Think of your wiki as a directory rather than a content warehouse.
Process
Documenting Processes minimizes onboarding time and streamlines workflows.
Key Questions:
- Where can new team members find onboarding materials?
- What tools are being used? (E.g., Slack, Jira, Confluence, Zoom, Miro, Figma, Zeplin, Storybook.)
- What are the guidelines for setting up and maintaining these tools?
- How does the team handle work? (Sprint-based? Kanban?)
Documenting Design Processes
The Process section should include design-specific documentation, such as:
- Research repositories and interview guides
- Whiteboards and brainstorming sessions
- Design requirements and user stories
- Branding guidelines, mood boards, and style guides
- Pattern libraries and design systems
- Documentation best practices
- Definitions of “design-done”
- Records of past design decisions
- Functional prototypes and usability test results
Conclusion
Your design wiki should serve as a single source of truth for your product design team. Organizing it around product, project, people, and process ensures everyone—from a new hire to a seasoned designer—has quick access to essential information.
Do you have thoughts about Design Wikis?
We’d love to hear them! Join our Community Discord to discuss design, UX, and tech. 🥚
Never miss an update!
Subscribe to the blog 📬
product design
