A core goal of our design team at Canonical is to create a space where people can easily access valuable insights on design in the open source industry, along with best practices for designing complex systems that serve a diverse range of users. Over the years, we created and shared a wealth of great design resources. 

However, after years of contributing across multiple sites and platforms, our online presence had become fragmented and in need of some much-needed TLC, or “Tender Loving Care” as the expression goes. 

This series explores the methods and tools we used to organize a sprint that helped us streamline and redefine our digital footprint. Part one focuses on how we organized the sprint, while part two recounts the execution and results of the sprint. 

In part one, we cover the following:

• Auditing our online presence – How the team assessed our platforms, content, and user experience to find gaps and inconsistencies
• Defining our mission and values – A deep dive into the purpose of the Canonical design team’s online presence and the guiding principles shaping its direction
• Structuring a new information architecture – How we organized content to improve navigation and relevance
• Planning the design sprint – Details on gathering participants, setting time constraints, defining deliverables, and preparing resources

Part two covers:

• Executing the sprint – Day-by-day insights into the methods and tools we used, including how the team collaborated to implement changes
• Post-sprint actions and delivery – A reflection on what was achieved, how the team communicated updates, and the next steps for maintaining a cohesive online presence

For each phase, you will find reflections on how our team experienced each exercise, the biggest obstacles, and lessons learned for next time. I hope you will find valuable insights and can learn from our experience to organize your own online presence sprint.

Auditing our online presence

The goals

• Understand the scope of the sprint
• Assess the key requirements for a potential website redesign
• Assess potential priorities and objectives

The journey

Over time, the content and resources the design team shared online got increasingly scattered across various platforms. We had resources on company websites, community platforms, internal documents, and public forums. This made it hard to maintain over time.

To assess what we were working with, my first step was to audit the content. The team gathered and linked all the places where we shared design work, discussed insights, or contributed to design conversations. This was very manual and time-consuming. It involved a mix of tapping into institutional knowledge, archive diving, and old-fashioned googling.

I recruited a few teammates to maximize our chances to cover as much ground as possible. We used a shared Miro board to document every piece of content we found, where it was linked to, what platform it lived on, and what the goals of the content were. We also added comments about “freshness” and quality to help us contextualize what needed to be kept, modified, replaced, or deleted.

By the end, we had a list of content to evaluate based on its purpose, relevance, and efficiency. 

Extract of our online presence audit

Next, I brought the whole team together to review our findings. We addressed key questions and areas of uncertainty, like how we wanted to represent our design system and the relationship between the Vanilla framework and our design libraries. This helped us understand our options and clarify the actions needed for each item as we move forward.

Audit Workshop: How to run it

Duration

2 to 3 days to gather content / 50 min to discuss findings

Preparation

Prepare your board

• The goal here is to list all artifacts found and provide the right level of information to get as close as possible to make a keep/update/delete decision for each item by the end of the group discussion.
• Asynchronously, the moderator needs to ask the team to add links to every place where information is shared or hosted following this pattern: 
  • Header post-it
    • Where the content was found and the link to the content
    • What topic it covers
  • Purpose post-it
    • What does the content try to do
    • Additional context like freshness, maintenance status, or quality levels
  • Thoughts/Questions post-it
    • Main points to discuss with the teams when reviewing the content
  • Suggested actions post-it
    • Suggested options to address challenges identified by the team
• If the audit exposes a lot of content, the moderator should organize the different artifacts by topic or purpose to facilitate splitting the workshop audience into groups. Examples of categories can be related to the type of content, like “web pages”, “tutorials”, or their audience, like “internal material”, “designer/developer-oriented content”, etc.

Prepare you attendees

• Once the board preparation is done, the moderator needs to ask attendees to familiarize themselves with the board to help reduce the time spent reading the information on the board.
• Always make sure attendees are familiar with the tools you use. If people are not familiar with Miro, make sure to dedicate some time at the beginning of the workshop to get people up to speed. Do check authorization and whether attendees have all the required permissions to participate ahead of time.

Guidelines

Step 1: Present the context (10 min)

• Introduce the goal. By the end of the session, there should be a clear set of actions for each artifact—whether to keep, update, modify, archive, or delete it.   
• Explain the criteria chosen to assess the content. In our example, we used purpose, relevance, accuracy, and efficiency.
• If you had to group people to cover the entire artifact list, separate people into their groups.
• Allow 5 minutes for people to get a refresher on what they will be looking at during the session.

Step 2: Discuss each piece (30 to 40 min, or as needed based on the number of items to review)

• Assign a 3 to 5 minutes timer depending on how complex the discussions are expected to be for each item, and prompt the discussion using the following questions:
  • Does this content serve a clear purpose?
  • Is it still relevant to our audience and goals?
  • Does it need updates, restructuring, or consolidation?
  • Should it be archived or deleted? Why?
• At the end of the timer, label each piece as Keep, Update, Modify, Archive, or Delete, and note the rationale for each decision in the Action post-its. 
• If a consensus cannot be reached, the moderator should mark the item as To Be Resolved, document the reasons for the disagreement, and note the key individuals needed to address the issue.

Step 3: Wrap-up and next steps (10 min)

• The moderator should quickly review the categorized content and decisions made. Make sure to highlight any contentious items to allow more people to come forward if they have a valuable perspective they can bring to the follow-up discussion.

Follow-up

• If there are any unresolved items, schedule a follow-up with the people able to make decisions regarding the items. Do try to do this as soon as possible to keep the momentum going. 
• For each item with a clear resolution, reach out to the owners or maintainers to communicate the outcomes of the workshop if they were not among the attendees.

The takeaways

As mentioned earlier, this was the most manual and time-consuming step. Tracking down every piece of content proved challenging, and we had to rely heavily on team knowledge to find the bulk of it. While input from those who created the content was really helpful, it wasn’t always possible to get firsthand insights. This was an interesting lesson in documenting processes and keeping records. It highlighted places where we needed to be more systematic in our work to avoid losing too much knowledge with time. 

Looking back, one key aspect I overlooked was clearly identifying the target audience for each piece. While the team addressed this gap during the sprint, discussing it earlier would have saved time and streamlined the process. This is an important reminder to keep a user-centric mindset—even designers can fall into the trap of making assumptions and taking shortcuts!

Defining our mission and values

The goals 

• Define a clear direction for the team
• Establish the type and tone of content needed
• Ensure alignment with the team’s mission and values
• Lay the foundation for consistent and impactful messaging

The journey

Now that I understood where we were, I needed to figure out where we wanted to go. We had many discussions and ideas about the mission and values of the Canonical design team, but we needed to define them in a way that everyone could contribute to and align with.

To achieve this, I gathered members of the management team and representatives from our design working groups, ensuring a diverse range of perspectives while keeping the workshop focused and productive. For this exercise, I chose a template that highlights personal stories and experiences, as I believe these help show the deeper motivations that should fuel our broader vision. To guide the discussion, my co-moderator and I included prompting questions to spark ideas and encourage reflection.

At the end of the workshop, I was left with multiple statements and ideas that I needed to combine into a clear vision/mission statement. I wrote a couple of variations and asked people on the team to do the same so we could all look at these examples and pick the ones that felt the most representative. 

In the end, this is what we decided on:

“Our purpose is to demonstrate how design can be both a leading and creative force in highly technical and engineering-led environments.

We want to share our journey of designing innovative and user-centric solutions for complex technical systems. This way, we hope to set high standards for excellence in design and engineering, as well as champion collaboration, curiosity, and resourcefulness.”

Extract of our mission workshop

Mission workshop: How to run it

Duration

1 hour 30 min

Preparation

Prepare your board

• Create a board following this template:
  • A large circle labeled “Story” to gather stories people can share about their experiences.
  • Inside this circle, three overlapping circles labeled:
    • “Recognition”
    • “Contribution”
    • “Passion”
  • The intersection of these circles should be labeled as follows:
    • “Recognition” + “Contribution” = “Vision”
    • “Contribution” + “Passion = “Mission”
    • “Recognition” + “Passion = “Vocation”
  • The center of the three overlapping circles should be labeled “Purpose”
  • The definition of each label is covered in the guidelines section. 
  • See the picture in this section for a visual example.
• Write down guiding questions to help people get in the right state of mind.
  • Examples:
    • Where do you see our design web presence in 5 years?
    • What impact are you hoping to achieve with it?
    • What is the major goal for you with our updated design presence?
    • What is your goal as a designer in this team?
    • Who do you hope will visit our website(s) and for what reason? What are they looking for?
    • What do you want our website visitors’ main takeaway to be?
    • Why are we doing all of this? Why are you willing to invest significant resources into it?
    • What change are we trying to make in the world?
    • What do you think our company is good at now? Or in the future?

Prepare your attendees

• Once the board preparation is done, the moderator needs to ask attendees to think of stories in advance so they don’t blank out on the day. In our case, the prompt given ahead of time was “Think of times when you were happy/grateful to be a designer in Open Source/at Canonical”.
• Always make sure attendees are familiar with the tools you use. If people are not familiar with Miro, make sure to dedicate some time at the beginning of the workshop to get people up to speed. Do check authorization and whether attendees have all the required permissions to participate ahead of time.

Guidelines

Step 1: Present the context (10 min)

• Introduce the goal. By the end of the session, the moderator should have enough material to craft a mission statement from the information shared and upvoted by the attendees.
• Explain the three main exercises:
  • Share stories, to get people in the right frame of mind
  • Define purpose, to write down more focused ideas and concepts from the stories shared and questions asked
  • Vote, to prioritize the input we want to inform the mission and values statement

Step 2: Share stories (15 min)

• Participants list 4 inspirational memories and stories about their relationship with the company and the design community. Moments when they learn something important. Landmark moments that make it all worthwhile. Then, each participant picks one and shares it with the group.

Step 3: Define purpose (35 min)

• Based on these stories and inspirations, participants keep drilling down and add post-its with ideas for the following categories:
  • Recognition: What are the talents, competencies, and abilities we are/want to be recognized and admired for?
  • Contribution: With what causes and problems do we want to contribute?
  • Passion: What do we love to do?
• Then, each participant picks one idea in each category and shares it with the group.

Step 4: Vote (20 min)

• Participants vote on the items they feel are the most important to help formulate our mission statement.
• The group discusses the outcome of the voting.

Step 5: Wrapping up and next steps (10 min)

• The moderator should review the highlighted concepts to wrap up the workshop.
• The moderator also needs to clarify the next steps:
  • Combine findings from the workshop to write a couple of mission statements.
  • Share options with the team to tweak them or vote on the most representative one.

Follow up

• The next steps do not need to happen in a meeting or in person, they can be worked on asynchronously.
  • The moderator needs to explore the intersection between the highlighted elements and synthesize the key takeaways to create purpose statement drafts in the first diagram’s center. 
  • The moderator should then share the options with the rest of the team to vote on the most representative one.

The takeaways

This exercise was a huge success with the attendees. An unexpected but valuable outcome of the workshop was how it motivated the team and helped us articulate what unites us. It’s easy to lose sight of the feel-good stories that brought us to where we are today, but taking the time to reconnect with what we love to do and what we want to contribute to the world proved to be a powerful motivator. In our case, it is a love for complex issues and a desire to help others learn about Open Source by sharing our journey.

With more abstract workshops like this one, including leading questions is especially useful in getting participants in the proper mindset. It was also a reference point that kept our eye on the overall goal as we moved through the process.

Structuring a new information architecture 

The goals

• Define the scope of the sprint and establish clear objectives
• Identify the minimum viable product (MVP) for a successful sprint
• Discuss prioritization, available resources, and expected outcomes
• Align teams on key focus areas to maximize efficiency

The journey

With a clear understanding of our existing content, the necessary changes, and what we wanted to share with the world, it was time to put an action plan in place.

Using insights from our content audit and keeping our mission statement in mind, I began mapping out the content we wanted without considering resource constraints just yet. The team and I focused on refining the ideal information architecture, deciding which content should remain on the website and what should be housed elsewhere, such as Discourse, GitHub, or Canonical’s other platforms. We made sure to discuss the type of audience we thought would be interested or benefit from the content, and highlighted what would be non-negotiable to provide each audience with valuable, up-to-date information. 

This process gave us a solid grasp of both the content we needed and the overall scope of work. It highlighted the areas where we had the most material, what we would need to build from scratch, and what we could leave to later as we consolidate our online presence. 

We decided to focus on the design website for this sprint, as it was the area we had the most control over and with the biggest challenge to solve. We defined a couple of pages as “priority” based on how fundamental they were to showcasing our work and adding value to the audiences we decided to address. 

Given the number of pages we wanted to deliver and the initial estimation of how many people would be able to participate, I set the sprint to last a week.

Extract of our board representing a draft of the information architecture

The takeaways

The information architecture helped the team see which areas needed attention, identify what we could control, and figure out how to distribute the workload. Even without fully defining every page, it allowed us to prioritize effectively. It also helped us address the earlier oversight of not explicitly considering our target audience.

Beyond internal planning, creating a map of content played a key role in our discussions with management. At this stage, I had implicit buy-in that redesigning our online presence was important, but I hadn’t yet received a formal green light. The information architecture helped me move the conversation forward by outlining what was feasible and highlighting potential limitations in concrete terms. This made it easier to begin advocating for the time and resources needed to move ahead.

Planning the design sprint

The goals

• Define clear expectations and responsibilities for all participants
• Secure final approval from management and partner teams
• Establish guidelines and resources to support attendees
• Ensure alignment with objectives and project goals

The journey

Building the sprint agenda 

Considering the amount of work effort involved in building the website’s pages, it was essential to clearly define how the work would be divided. Using the information architecture, I focused on determining who would be responsible for each section and assessing the resources available for each area. This process allowed me to outline an “ideal scenario” to start creating an agenda for the sprint.

The team had decided that our MVP would include one page per established section, excluding pages already in good condition, such as those covering brand or accessibility. From there, I outlined the criteria for a high-fidelity wireframe, identified the resources required to achieve it, and worked backward to set daily goals to guide our progress.

The initial ideas for our agenda

Managing stakeholders

With these requirements in mind, I was ready to discuss the final details regarding time and participation from the team with management. Since this effort would temporarily divert designers from their usual tasks, I needed to present a clear case and emphasize the cost-benefit tradeoff. 

To help convince them, I designed two types of agendas: 

• The “ideal” one assumed full participation from everyone throughout the sprint.
• The “minimal” one focused more on delivery and accounted for the possibility that some participants might not be able to join as much as planned or might only be available on certain days. 

The goal was to showcase the outcome of a full commitment versus a partial one, what would be at risk if we didn’t get commitment from a minimum amount of people, and give sufficient information to managers so they could evaluate how this would impact their reports.

Full agenda vs partial agenda: workshop and presentations vs modular pair work time

Another key group of stakeholders was our web team. We needed to make sure that our work would be published and not remain on Figma files indefinitely. After consulting their project managers, we aligned with their processes so that development could begin immediately after the sprint concluded. We used a spreadsheet to keep track of all the material that needed to be developed,  links to relevant assets, and a point of contact to follow up with in case something was missing.

A spreadsheet to follow our progress and keep track of helpful assets for the web team to build the pages

Gathering participants

Once the agenda options were ready, we communicated the dates and objectives of the sprint to the rest of the team. I confirmed with our subject matter experts (SMEs) their presence and gave them an outline of what would be great to see from them. I also checked with our “section leads” to confirm their availability. I had planned to get goals from any leads who couldn’t join and have someone cover for them, but luckily, everyone we needed participated.

I shared a board with the details of the sessions and a call sheet for attendance to get an idea of how many people would be joining aside from our SMEs and section leads. Some exercises, like the Round Robin, need a certain amount of people to be doable or enjoyable, so knowing who could join was important.

Building resources

Once the agenda was more or less defined, I had a clear list of the resources needed.

The list looked like this:

• A centralized place to host resources and guidelines
  Ensures all team members can easily access key information and stay aligned throughout the sprint.
• A centralized place to save materials (drive folder)
  Keeps files organized and accessible, avoiding confusion and duplication of work
• Guidelines for overall sprint for how to find help or who to ask for questions
  Provides clarity on support channels, minimizing delays and keeping the sprint running smoothly
• Presentation of our goals and mission
  Establishes a shared understanding of the sprint’s purpose and desired outcomes to keep everyone focused
• Examples of what a deliverable should look like at the end of each day
  Sets clear expectations for daily progress, helping teams track and measure success
• Guidelines for all exercises
  Ensures participants understand the structure and objectives of each activity
• Links to existing material for review
  Saves time and provides context by offering references to prior work or research
• Presentation on UX copy and how to write good content
  Provides guidance on our copy guidelines to the team 
• Library of components to build a page
  Speeds up the design process and make sure the outcome is development-ready
• Presentation on visual design for web pages
  Provides guidance on our visual guidelines and inspiration for creating great layout designs
• Visual resources
  Offers tools like icons, images, or templates to streamline the design process
• Next steps for implementation
  Helps the team transition from design to development, ensuring the sprint’s outputs are actionable and ready to execute

To make the sprint structure easier to manage, I created a centralized board with a skeleton of what the agenda for each day should look like and include.

The skeleton: day overview, morning and afternoon agenda with guidelines and working groups, link to further resources for the session, and an end-of-day demo round-up

Once the overall framework for each day was established, I divided the daily responsibilities among the organization team to streamline the creation of resources. This approach also aimed at making moderation easier, as it assigned different team members to answer questions about specific exercises and guide discussions during moderated sessions, rather than relying on a single person for the entire week.

Finalizing logistics

After organizing the resources and defining our daily objectives, it became easier to identify who we needed, for what purpose, and when. The sprint organisation team created tentative groups and sent requests to key individuals to make sure they were available or to ask them to delegate someone in their place if they couldn’t attend. To help with coordination, we set up a shared Google Calendar, added all the sessions with detailed descriptions, and invited the people who initially confirmed. This approach also allowed anyone who initially declined but wanted to participate later to see the schedule and join sessions as needed.

After one last rehearsal with the Open Design working group, we were ready for the start of the sprint! 

The takeaways

This phase was the most work-intensive for the moderation team. Estimating how much time and resources were needed to get to where we wanted to be was tricky. However, what I found the hardest was finding a way to deliver on our intense requirements while providing an enjoyable experience for the attendees.

Planning the sprint came with 3 main constraints: delivery, modularity, and overall experience.

Delivery

Creating content is an involved process, and Canonical employees work with strict copy and visual guidelines to ensure everything we share is up to the company’s standards. To maintain consistency and quality, I integrated quality checks directly into the agenda, ensuring that projects were ready for production rather than left unused due to insufficient quality.

To get everyone on the same page, I asked our resident content experts to share guidelines and best practices with the attendees.

And finally, to promote consistency across teams, I scheduled a round-robin style session at the end of each day. This was especially helpful in getting multiple perspectives on the work done and giving everyone an idea of how the other teams structured their pages.  

Modularity

One of the most challenging constraints was modularity. Designers are embedded in product teams and are asked to deliver on tight roadmaps, so any time away from product work can be tricky to justify. The design management team asked me to build an agenda that accounted for people coming in and out of the exercise. This constraint required us to develop detailed, easy-to-follow guidelines and resources. It also encouraged us to document our progress and the decisions made along the way. This approach proved invaluable, especially since most attendees ended up not being able to attend the entire sprint. 

Experience

On a more personal note, my goal was to make the sprint as engaging and enjoyable as possible by focusing on a few key aspects:

• Creating learning opportunities
  I wanted to ensure that participants could take something valuable away from the experience—whether it was understanding grid systems in visual design, improving copywriting skills, or gaining insight into the roles and challenges of the team members who work on our websites daily. The design team has people with great skills in-house, and I wanted to create an opportunity for them to share their knowledge with the rest of the team. This ended up aligning perfectly with our quality requirements, which was a nice bonus. 
• Building team relationships
  To strengthen connections within the team, I wanted to include sessions for smaller group interactions. Since we rarely have the chance to work together as a full team, this was an ideal opportunity for colleagues who don’t usually collaborate to spend meaningful time together. Between the “work together” times and the Round Robin group reviews, every attendee had the opportunity to work with everyone else. As highlighted in the feedback session, being able to work with other designers was one of the best takeaways for attendees.
• Prioritizing breaks
  I wanted to incorporate enough breaks to allow participants time to relax and reset, giving them space to recharge or reflect. In hindsight, we could have scheduled even more!

What’s next?

Figuring out expectations and pulling together the right resources to build solid guidelines took effort, but it helped build strong foundations for our sprint. Overall, focusing on clear deliverables and keeping attendees’ experience in mind helped guiding our process.

All of the advice I shared so far can be used in any type of sprints, and I hope you found useful takeaways! And if you’re eager to see how all this preparation paid off during the sprint and what came next, be sure to check out part 2 of the series!