Does Your Design Wiki Answer These Key Questions?

Product design projects involve many moving parts. Between design requirements, roadmaps, research findings, and design documentation, there’s a lot of information floating around.

Design wikis can help your team stay up-to-date and on the same page. Rather than having information spread across different platforms (in Figma comments, Miro boards, Slack threads, and Jira tickets), you can use your design wiki as a single source of truth where all information is stored.

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 so important to keep the content and structure organized. I like to use the four P’s: product, project, people, and process.

Tip: No informaltion is too obvious or too basic for your wiki. You know your wiki is working if a new hire can get up to speed after perusing the single source of truth.

Product

The Product section of your design wiki should answer all potential questions that a new hire might have about the product you’re working on.

Design Wiki Questions: Product

What is the product?
What is it called?
What kind of product is it? An app? A website?
What does it do?
Who does it serve (who are the users)?
How does it function?
What are the key performance indicators (KPIs) for this product?
How will it steer the business toward its goals?
What is the vision for the future of this product?

Project

The Project section of your design wiki focuses on the project at hand. It might be tempting to lump these questions in with the Product section, but having documented procedures for each design project (not just the overarching product) is a key part of Pragmatic Design.

Design Wiki Questions: Project

What is the project?
How will the project change or enhance the product?
What are the main goals of this initiative?
What is the scope of the project? What will it not include?
Are there any constraints or limitations your team should be aware of?
When did this effort begin, and when is it expected to end?
What does the roadmap look like?
How will the work be broken down?
How is progress reported?

People

The People section of your design team wiki will be an invaluable tool for newbies and veterans alike. Communication is easier when the information needed to do so is readily accessible.

Design Wiki Questions: People

Who is working on this project?
- Include names, pronouns, time zones, photos, titles, organizations, and contact information.
- Create an org chart so people can see how teams are structured
- Who are the decision-makers on the project?
How does your design team relate to the rest of the organization?
How do people prefer to communicate?
What tools and methods are being used for asynchronous communication?
What does the cadence of meetings look like?
Where and how are meeting agenda, minutes, and notes being stored?

Tip: avoid duplicating content that exists elsewhere because that can lead to rot. For example, if all your mood boards already exist in Figma, just pop a link to your Figma file into the wiki, rather than pasting a screenshot there. Utilize links as much as possible. Think of your wiki as a directory: a single place that points people toward the information they need.

Process

Documenting team Processes helps cut down on administrative toil when new people join the team. Instead of spending a day on training, point your new colleagues to a single source of truth.

Design Wiki Questions: Process

When new people join this project, where can they find onboarding and orientation material?
What tools are being used for this project?
- Include as much information as possible regarding tooling. For example, your team might be using Slack, Jira, Confluence, Zoom, Miro, Figma, Maze, Zeplin, and Storybook. If your team has setup or maintenance guidelines for any of these tools, include those, too.
How is your team handling work?
Is the design team following a sprint schedule along with developers? Or perhaps they’re using more of a Kanban method.

Documenting Design Processes

Within the “process” section of your wiki, you will need to have some content specific to your design team. This could include links to interview guides, research repositories, whiteboards, design requirements, branding materials, mood boards, style guides, pattern libraries, design systems, documentation best practices, definitions of “design-done,” records of previous design decisions, and functional prototypes.

Conclusion

Your design wiki should be a single source of truth for your product design team. Focusing on product, project, people, and process ensures new team members can quickly get up to speed.

Do you have thoughts about Design Wikis?

We’d love to hear them! Join our Community Discord to talk all things design, UX, and tech. 🥚

Never miss an update!

Subscribe to the blog 📬