Design Workflow Evolution

Background: The Challenge

This case study outlines how I transformed our design team’s workflow management from fragmented individual systems to a cohesive Jira-based process that scaled with our growing workload.

When I started this initiative, our team consisted of five designers, each managing 1-2 projects simultaneously. Each designer tracked their work independently using whatever method they preferred, ranging from digital tools like Trello and Asana to analog systems of handwritten notes, lists, and desk post-its. While individual tracking systems weren’t inherently problematic, they created significant blind spots in our collective workflow.

The situation became critical when our project load dramatically increased, with each designer suddenly responsible for 3-5 concurrent projects. Without a standardised system, visibility decreased as complexity increased. Deadlines began to slip, handoffs became inconsistent, and designers struggled to prioritise effectively among competing demands.

We faced three key challenges that were only getting worse:

  1. Tracking Scattered Work 
    With designers juggling multiple projects using different tracking methods, we struggled to maintain consistent timelines and quality—it was like trying to read several books simultaneously while keeping all the storylines straight.
  2. Poor Resource Planning 
    Without a clear picture of upcoming work and team capacity, we were constantly reacting to the loudest requests rather than strategically planning our resources – making it impossible to get ahead of potential burnout.
  3. Disconnected Stakeholder Updates
    I couldn’t easily provide the big picture to stakeholders or confidently align our work with business priorities, as I was piecing together status updates from multiple sources rather than having a single source of truth.

Finding Our Perfect Tool

After looking at what our team needed and what was already working elsewhere in the organization, Jira emerged as our clear winner. Here’s why it made sense for us:

  • Leveraging existing resources 
    Our dev and IT teams were already using Jira, so we could piggyback on existing licenses and finally get our design work visible alongside technical projects.
  • Flexible for everyone
    Unlike rigid design-specific tools, Jira could allow us to create workflows that worked for both designers and other teams, with room to evolve as our team grew.
  • Integrations
    The seamless connection with our Confluence documentation meant our briefs, plans, research, and other documentation all lived in the same ecosystem – no more hunting across platforms.
  • Made sharing progress easy
    Jira’s visibility features meant we could use it as single source of truth rather than relying on memory.

While Jira is typically seen as a dev tool, I saw this as a perfect chance to bring design processes into the same world as our technical colleagues, creating a shared language for collaboration.

Starting Small: Testing the Waters

Rather than diving into a complete workflow overhaul, I took a more measured approach. Big changes rarely stick, so I chose a single project as our testing ground—one with the perfect conditions for success:

  1. A collaborative mix
    The project brought together two designers, a researcher, and stakeholders from Research and Lived Experience teams, giving us a diverse group to learn together and test how well Jira supported our collaborative needs.
  2. A ticking clock
    With tight deadlines looming, we had real motivation to make the tool work. Nothing proves value faster than helping a team meet an urgent timeline!
  3. A fresh start
    Being a brand new project meant no messy migration of existing tasks or history – we could build our process from scratch without any legacy baggage.
CETA Sprint board

I kept things deliberately simple, setting up a basic Kanban board that mirrored our design flow: “To Do,” “In Design,” “Ready for Review,” “In Review,” and “Done.” After a quick training session where I emphasised how Jira would replace (not add to) their current tracking methods, we were off and running. Throughout the pilot, our weekly team meetings included time for Jira feedback, allowing us to fine-tune the system based on real-world use.

Pilot Results: It Actually Worked!

Our little Jira experiment took off faster than we expected! All our success metrics were pointing in the right direction from the get-go:

 The Team Loved It

  • Everyone on the project team jumped on board within two weeks – no arm-twisting required!
  • The team couldn’t stop talking about how helpful the new workflow was – it came up naturally in every project retrospective.

We Crushed Our Project Goals

  • We tackled a pretty complex project and delivered within tight 3-month deadline.
  • Juggled three rounds of research without dropping any balls (discovery, concept testing, and user testing).
  • Working with our Lived Experience advisors became so much smoother – everyone knew exactly what was happening and when.

The Rest of the Company Took Notice

  • Stakeholders who popped into our standups kept giving positive feedback and coming back.
  • People from other teams started reaching out to me asking how they can have a similar set up for their work.
  • Lived Experience team manager said that unintentionally, this ended up being the most co-designed project to date.

This successful test run gave us real proof that our Jira approach wasn’t just solving our original problems – it was creating all sorts of unexpected benefits in how we worked with other teams.

Scaling Up

After our successful pilot, the natural progression was to implement Jira across all our design projects. However, this expansion quickly revealed a new challenge: designers were now navigating multiple boards for different projects, creating a fragmented experience that sometimes led to overlooked tasks.

To solve this, we developed a more elegant solution: a centralised DESIGN space that wasn’t tied to any specific project, but served as a unified hub for our team. The key innovation was implementing a “DesignTask” label that acted as a virtual filter – any ticket tagged with this label would automatically appear in our DESIGN space, regardless of its project origin.

This simple but effective approach meant designers only needed to check one location to see their complete workload. The approach has dramatically improved visibility while reducing the cognitive load of switching between multiple boards.

In addition, having a separate DESIGN space resulted in additional benefits:

  • It provided a home for smaller tasks that didn’t warrant a separate project space (such as creating quick competitor analyses or graphics for a research paper)
  • It accommodated internal design initiatives that weren’t tied to specific projects, like our contributions to the Innovation Day
  • It enabled much clearer visibility of each designer’s total workload across all projects, improving resource management

To ensure smooth adoption and sustainability, I created comprehensive documentation in Confluence that served as our team’s reference guide. This documentation covered everything from the basics of raising a ticket to troubleshooting common issues (like tickets not appearing in the sprint or DESIGN space), and even included guidance on engaging with IT support when technical challenges arose.

This documentation proved invaluable as we expanded usage, providing team members with self-service answers to their questions and establishing clear, consistent processes that everyone could follow independently.

The combination of our centralised DESIGN space and thorough documentation transformed how our team managed work. 

Learnings after first 6 months

Our “start small” approach really paid off throughout the scaling process. Beginning with just one project and a straightforward workflow gave everyone breathing room to learn the tool and embrace the process at their own pace.

As we expanded to more projects and our Jira ecosystem grew more sophisticated, the documentation I created became our team’s north star, helping to foster self-sufficiency on the team.

The transformation was remarkable when compared to our starting point. Where we once had information scattered across personal notebooks, post-its, and various digital tools, we now had a single source of truth that everyone could access and understand. Design work became more visible, and planning considerably more accurate.

Adding Metrics: From Process to Performance

By late 2023, Jira had become our team’s go-to platform for almost all projects. With the foundation solid, it was time to tackle our next set of challenges. In early 2024, I identified two key issues we needed to address:

  • Reactivity vs. Planning: Our team was constantly juggling unexpected requests alongside planned work. This reactive approach made it nearly impossible to provide stakeholders with reliable timelines and often delayed our larger strategic projects.
  • Estimation Accuracy: Without clear metrics on how long different tasks typically took, we consistently underestimated project timelines – creating frustration for both designers and stakeholders.

After analysis in January, we planned and prepared to roll out an enhanced approach starting February with two key improvements:

  1. Story Points
    We introduced story points to quantify work complexity rather than just time. This wasn’t an instant success – for the first two months, the team needed regular reminders about our point scale. But by the 8-week mark, this new language of estimation had become second nature, dramatically improving our forecasting ability.
  2. Weekly Sprint Cycles: Bringing Focus to Chaos We shifted from monthly to weekly sprints, accompanied by two new team rituals:
    • Sprint Reviews: These replaced our formal “show and tell” sessions with more casual weekly check-ins where designers shared work, gathered feedback, and stayed up to date on each other’s projects. The more casual format led to more consistent participation and better cross-project awareness.
    • Sprint Planning: These sessions helped designers prioritise their upcoming week and gave us a buffer to schedule new requests in future sprints. This simple change allowed us to start preparing for work before it officially began and provide stakeholders with realistic expectations.

These adjustments created a beautiful balance. We maintained the flexibility to handle incoming requests while gaining the structure needed for meaningful planning. For larger projects with existing standups, we maintained those ceremonies rather than adding new meetings.

Measuring Success

After introducing story points, we began gathering meaningful data that illuminated our team’s true capacity and velocity. At the end of Q1, I compiled our first metrics dashboard and shared it with the team – a revealing snapshot of our evolving workflow.

The initial investment was significant—about three hours weekly for our sprint planning and review sessions. But the return on that investment became clear remarkably quickly. Within just eight weeks, as the team internalized the process and became fluent in estimation, our time commitment dropped to just 45 minutes per week.

This efficiency gain wasn’t just about saving time – it represented something more valuable: a shared language around workload and capacity that was finally backed by real data rather than gut feeling.

From reactive to strategic planning

As our data matured, two critical insights emerged:

  • Our affectionately named “side quests” (unplanned work) continued to disrupt weekly plans despite our best efforts at scheduling.
  • Design quality and efficiency notably decreased with each additional concurrent project assigned to a designer – a classic context-switching effect that was now supported by data.

These insights highlighted a clear opportunity: I needed to elevate my role from tracking work to strategically planning and buffering it, while also educating other teams about our new workflow.

The solution? A simple but powerful design roadmap. Rather than implementing something complex, I created a straightforward spreadsheet that everyone on the team could access and understand. The beauty was in its simplicity and how we integrated it into our existing process.

We made this roadmap the starting point of every Tuesday sprint planning session. Together, we’d first review and adjust the roadmap to reflect current realities, and then transition to Jira to create and estimate tickets for the week ahead. This sequence created a natural flow from strategic overview to tactical execution.

Once our planning sessions concluded, I personally handled the administrative side (such as closing completed sprints and opening new ones) to keep the system clean and the team focused on their design work.

This approach finally gave us the proactive stance we’d been working toward: a clear view of the horizon paired with the detailed navigation needed for the week ahead. The roadmap became our shared reference point not just for what we were doing, but importantly, for what we were choosing not to do right now.

What we learned from the roadmap

The roadmap in combination with Jira has transformed our workflow in ways that exceeded our expectations:

  • Precision in Planning: Q2 2024 saw a remarkable shift in our ability to forecast work. We could provide stakeholders with reliable estimates and accurate project quotes, building trust and reducing last-minute surprises for everyone involved.
  • Quality Through Focus: By deliberately limiting concurrent projects per designer each week, we witnessed the benefit of faster completion times and higher quality deliverables. Projects that previously dragged on for months were now completed with greater efficiency and better design solutions.
  • Empowered Boundaries: Perhaps most importantly, the roadmap gave designers the structure and confidence to manage incoming requests appropriately. They could now respond to urgent asks with “I’m focused on priority work this week, but I can add you to our roadmap” – a professional boundary that actually improved our service to stakeholders through better planning.

This final phase completed our journey from scattered individual systems to a cohesive, data-informed workflow that balanced flexibility with focus.

Summary

This case study shows how I guided our design team from scattered sticky notes and personal tracking systems to a unified, insight-driven workflow that grew alongside our expanding responsibilities.

Our journey unfolded across four key chapters:

  1. Identifying the Problem
    I noticed how our designers were drowning in their own tracking systems while juggling more and more projects – leading to confusion, missed deadlines, and a growing sense of overwhelm.
  2. Finding the Right Solution
    Rather than forcing a brand new tool on everyone, I leveraged Jira (already used by our tech teams) and tested it on a single project, giving the team space to experience its benefits firsthand.
  3. Making It Work for Everyone
    We created a central design hub in Jira that pulled all design tasks into one view, making it impossible for work to fall through the cracks, and backed it all up with clear documentation anyone could follow.
  4. Taking It to the Next Level
    By introducing story points, weekly planning sessions, and a simple roadmap, we transformed how we planned and communicated our work. We have moved from  “we’ll try our best” to “here’s when we can deliver this and how much it will cost.”

The before-and-after contrast is remarkable: we shifted from a team constantly reacting to incoming requests to one that confidently plans its capacity, delivers more predictably, and produces higher quality work with less stress. What makes me proudest is how we built this system together: each improvement came from real team needs and feedback rather than being imposed from above.

This approach reflects how I believe teams work best: understand the real challenges people face, introduce improvements they can actually see value in, and use concrete data to keep making things better.