Canonical’s Design Brief Shows Open Source Needs Contributor UX

Canonical’s new design contribution brief is small on its face: a template that helps maintainers explain what kind of design help an open source project needs. The bigger lesson is more important. Open source has spent years optimizing the path for code contributions, but many projects still make design work feel ambiguous, invisible, or unsafe to start.

In the Ubuntu Blog post “Template: Streamlining open source design contributions”, Nina Rojc writes that Canonical designers presented research at FOSSBackstage 2025 on why designers do not get involved in open source projects. The post describes a gap on both sides: designers struggle to find projects with clear design needs, while maintainers struggle to articulate those needs or may not know when to ask for design support.

That is a contributor-experience problem, not just a design-team problem. If a project cannot describe the user, the workflow, the decision owner, the deadline, or the communication path, then “please help with UX” is not a usable issue. It is a vague invitation to do unpaid discovery work in public.

The template treats design work like a real contribution path

Canonical’s proposed brief has five sections: the project context, the design contribution needed, logistics, team information, and communications. The structure is practical because it asks maintainers to do the work that usually remains implicit. What problem is the project solving? Which users matter? Is the request about UX, UI, graphic design, accessibility, research, or something else? Who reviews the work? How does the team communicate?

Those questions sound ordinary, but they change the shape of participation. A maintainer who files a code issue normally knows that a contributor needs a reproducible bug, expected behavior, actual behavior, and a review path. Design requests need the same level of operational clarity. Without it, designers are asked to infer scope from screenshots, chat history, and maintainer taste.

Design ambiguity becomes maintainer debt

The Canonical post frames the brief as useful for both maintainers and designers. Maintainers get clearer expectations, a centralized reference, and a better chance of attracting people with the right skills. Designers get enough project context to judge whether they can help, what outcome is expected, and where to ask questions.

That exchange is the key. The brief does not magically create design capacity. It reduces translation cost. In mature projects, that cost is often hidden inside the heads of long-time maintainers. New contributors see only the surface: a label, a short issue, a stale discussion, or a request that assumes deep local knowledge.

Open source already knows this lesson for code

GitHub’s documentation on setting guidelines for repository contributors makes the same point for general contributions. A CONTRIBUTING file communicates how people should contribute; GitHub surfaces that file when someone opens an issue or pull request and on the repository’s contribute page. The docs say guidelines can include steps for useful issues or pull requests, links to external documentation or a code of conduct, and community expectations.

Design briefs are the design-specific version of that idea. They belong next to CONTRIBUTING files, issue templates, and “good first issue” labels. The difference is that design work often needs context that code issues can sometimes avoid: target audience, product vision, brand constraints, accessibility goals, research assumptions, and the decision process for subjective tradeoffs.

Contributor UX should be part of project governance

The Open Source Guides chapter on building welcoming communities recommends reducing friction at each stage of the contributor experience, starting with documentation, a clear CONTRIBUTING file, up-to-date issues, and beginner-friendly labels. That advice applies directly to designers. If a project wants design help, it should make the first step obvious enough that a qualified outsider does not have to reverse-engineer the organization before doing useful work.

Governance also matters because design contributions can touch identity, accessibility, user trust, and product direction. A drive-by pull request can patch a typo without changing the project’s strategy. A UX redesign may require alignment on users, tradeoffs, and long-term maintenance. The contribution path has to say how those decisions are made.

The missing interface between maintainers and designers

The strongest part of Canonical’s brief is that it makes maintainers describe the interface between the project and a designer. That interface is usually weaker than the code interface. Repositories have tests, linters, release branches, issue trackers, and review rules. Design often has “talk to us on Matrix” or “mockups welcome.”

That mismatch discourages the exact people projects say they want. A designer evaluating a volunteer contribution needs to know whether the project is looking for a production-ready interface, a heuristic review, an accessibility audit, icons, user flows, onboarding copy, or research synthesis. Those are different skills and different commitments.

Scope is a safety feature

Clear scope also protects contributors. A designer should not spend hours producing polished mockups only to learn that the project wanted a quick critique, that no maintainer can implement the change, or that the team has an unstated product direction. A brief gives contributors a way to say yes, no, or “not yet” before investing serious time.

Mozilla’s Community Participation Guidelines are a useful reminder that participation depends on more than a task list. The guidelines emphasize respectful, direct, inclusive collaboration and explicitly call for alternative ways to contribute or participate when possible. Design briefs should carry that same posture: they should invite useful work without forcing every contributor into the communication style of the core team.

What maintainers should add before asking for design help

A useful design contribution brief does not need to be bureaucratic. It needs to answer the questions that a maintainer would answer in a good onboarding call. If the answers are unknown, that is itself useful information: the project may need discovery, research, or product framing before it needs visual design.

A practical brief should include five operational checks

• Problem and audience: name the user, workflow, pain point, and why the project needs design input now.
• Contribution type: distinguish UX review, UI mockup, accessibility audit, research, content design, branding, or illustration.
• Constraints: list design system rules, implementation limits, accessibility requirements, release timing, and what is out of scope.
• Decision path: identify who reviews the work, how feedback will be given, and what counts as accepted.
• Communication norms: document synchronous and asynchronous channels, expected response times, language expectations, and onboarding support.

This is not extra process for its own sake. It is the difference between an invitation and a handoff. Good maintainers already do this for complex code changes. The brief simply makes the same discipline available to design contributors.

The real signal is contributor experience maturity

Canonical’s template is valuable because it treats design as part of the open source production system rather than a late-stage polish layer. Projects that want better UX, clearer documentation, accessible interfaces, and more coherent product decisions need to expose that work in the same way they expose engineering work: with context, scope, review, and respect for contributor time.

The broader takeaway for maintainers is straightforward. If a contribution path only works for people who already understand the project, it is not really open. It is merely public. A design brief is one way to make the path legible enough that more people can contribute without guessing where they fit.

Sources worth keeping open

• Ubuntu Blog: “Template: Streamlining open source design contributions”
• GitHub Docs: “Setting guidelines for repository contributors”
• Open Source Guides: “Building Welcoming Communities”
• Mozilla Community Participation Guidelines
• Featured image source: “TechnicalWishlist Workshop Search 16-18 Munich StickyNote1” by Jan Dittrich (WMDE), CC BY 4.0