Designing for Designers
"You do not rise to the level of your goals. You fall to the level of your systems."
- James Clear
Transforming Challenges into Operational Efficiency
​
Starting a new job is always challenging. It's even more complicated when the person training you leaves a few weeks after you start. That was my case when I started my new job as a product delivery manager at Spectrum. Charter / Spectrum is the 64th largest company in the United States, and I was tasked with guiding the end-to-end design process for their mobile applications and various TV and web products.
​
The design management system was messy. Designers often pointed tickets at more than 20 story points, and each designer had 2 - 5 tickets assigned to them at any given time. It was almost impossible to keep stakeholders informed of a design's status, and as a result, lots of lengthy meetings would continuously occur. A change had to happen if I was to survive in my new role. I needed to implement an Agile design process with repeatable sprints as the core structure.
​​
Initial Challenges and Solution Implementation
​
Convincing my manager and fellow designers was challenging. Most people sincerely believed that design could not function within a dev-centric agile methodology, and our stakeholders shared this sentiment. Having implemented design-centered agile processes at previous companies, I knew it would be the key to reducing many of the struggles we were currently facing. I narrowed my focus down to improving five core concepts: becoming more organized as a design team, being better cross-functional partners, delivering better work faster, increasing transparency on what we're working on, and drastically increasing the accuracy of our timelines. I would implement a 3-week sprint cadence, lead focused sprint planning sessions, prioritize our backlog with our product partners, implement an accurate story-pointing system, and constantly aim to improve the process through post-sprint retros. In turn, I promised the designers that the system would reduce context switching, allow them to plan their work ahead of time, make them feel more comfortable with our delivery dates, and showcase their work more often through regular design demos. The sprint system would also reduce the vast amount of unplanned work that constantly slowed down the design team. Switching our ticket tracking to JIRA would allow cross-team transparency with our development partners.​​
The First 3-week Sprint Cadence Implemented
Results and Impact
After receiving cross-team buy-in for the new design sprint structure, the team saw immediate success in finishing projects. By focusing a two-week increment around single deliverables instead of advancing on up to five different projects, designers could embody their user personas deeper, significantly reduce their context switching, and avoid working on unplanned work. Designers could close out large projects faster, and with the help of the prioritized backlog, they always knew what task had the highest priority. They also self-organized their time during the two-week increment to allow them to have as much heads-down time as possible. Autonomy of task and time became core values, and with the help of routine design demos, the need for frequent meetings declined over time. Previously unplanned work had to be submitted through an official intake and planned for an upcoming sprint. I would sort and solve minor issues discussed in sprint retros as the process improved.
​
I organized all our work into a simple system that took all our acceptance criteria from our intake form and added them to a project. Each project cascaded down into individual epics representing project milestones or features. Each epic would have its own set of tickets that, once completed, would complete the epic. Once the team finished each design epic, I could hand off the designs to our development partners. This organization made it simple to track our progress and speak to our delivery timelines.​
Ticket and Epic Organization Example
​Enhanced Project Planning and Execution
​
Now that projects had to follow strict intake rules, the team could scope new projects using unified story points and create roadmaps with much higher accuracy. At this point, the agency started incorporating project increment planning, also known as PI planning, once a quarter. PI planning aimed to align all the departments on quarterly deliverables and track any dependencies that teams needed to deliver. The design team was able to accurately scope, plan, and deliver all projects ahead of time during the first quarter using the new process. We now had the ability to accommodate all other delivery partners each quarter and further protect ourselves from unplanned work, as it could derail the greater plan committed to during PI planning. The lead scrum master would record every team's quarterly plan on a board known as the program board. We used the program board to track each team and ensure that each team could develop its products on time according to the overarching business goals. The program board became our most prominent artifact, protecting us from scope change and allowing us to plan our sprints more accurately.​
Example of a PI Program Board
​Team Specialization and Continuous Improvement
​
The process had come far but could have been better. To work as fast as we did, each designer specialized in either design strategy or design delivery. We called this work discovery or execution. Splitting the team into their preferred strength had given us incredible velocity, but we needed more individual improvement. The split also introduced a division within the team that encouraged designers to only work on projects aligned with their working style. Designers specializing in discovery work would not grow their visual design or development handoff skills. Designers working solely within execution work needed to hone their design strategy or user research skills. To bridge the gaps, we paired designers from each skill set on end-to-end projects where they would learn from each other. We called these pairings design pods. Each pod had a lead designer and a supporting designer and would write the plan for the project together based on the timeline given to accomplish it. I would turn each deliverable into a ticket, and every ticket could be at most five story points before being broken down further to mitigate risk. Repeating this exercise gave us precise project plans that would fall within our given timeline with minimal risk to the projects.
​​
Data-Driven Insights and Transparency
​
The final artifact I built was the ability to collect essential metrics on demand for every project we were involved in. The data would tell the story of how our team was progressing on projects, whether we had the capacity for additional projects, how often unplanned requests derailed us, and how each team member performed individually. We could also see how much time was going towards each project and how much time we spent on design strategy versus visual design. This data populated JIRA dashboards that we shared with our stakeholders.
​
Our real-time dashboards' real advantage was seeing how each designer was doing at the moment. I would make sure that no one was taking on more work than they had the capacity for, and I would limit the number of projects they were working on during a sprint to reduce context switching. As a rule, no designer could lead more than one project at a time but could support up to two additional projects. If new work came in, I knew instantly if we had the capacity to take it on and who would be available. With all these changes, I fought to keep each designer engaged, growing, and as far away from burnout as possible. I acted as the shield that defended their workload, with full support from my leadership.​
Example of JIRA Dashboard Data
​Conclusion
​
It's now apparent that how we work and plan has changed a lot since I started. We have become a disciplined team that follows a structured, protected sprint system based on autonomy. Every project comes to us through a detailed intake form that allows us to estimate the work accurately and assign the appropriate pair of designers. We can forecast our capacity for the team and each designer, play to their strengths, and prevent burnout. Our involvement in PI planning lets us plan quarterly and enable our development partners to have designs when needed. Our backlog lets us fill capacity gaps with the highest priority tasks, and we continually strive to improve the process through regular retros. The design team can function at full velocity while growing in primary and secondary roles, all without being overworked. Regular asynchronous updates let us work transparently with our partners, and designers spend more time than ever heads down without context switching.
​
All of this equates to being more organized as a design team, being better cross-functional partners, delivering better work faster, increasing transparency on what we're working on, drastically increasing the accuracy of our timelines, and so much more.
It sounds familiar.