How to Keep Your Software Projects on Track Using Design Systems and Program Management
Program Manager
projekt202
Design systems are an essential foundation for diverse application landscapes.
Your app catalog may have grown due to acquisition, disparate teams developing software tailored to their own needs or the needs of their specific customers, or any other of the many reasons that seemed correct at the time. Ultimately, it left your organization with a suite of applications that you need to market to your customers, and then support.
I will leave the full explanation of the merits of design systems to the experts. You can get more information here on the many ways design systems can greatly improve the user experience in your applications, and make them easier to maintain and enhance.
Design systems are great, but how do we, as program managers, guide our teams through the design, development and implementation processes?
Expectations
Design systems are fantastic at generating much-needed excitement within organizations. They mean a new face and improved functionality for your products, often bringing dated applications into the modern age of user-centric form and function. However, excitement tends to breed assumptions and, as a Program Manager well knows, assumptions are dangerous.
Communicate early and often on the intent of the first version of the design system: the target application(s), the key processes or workflows it will address, the overall timeline, the limitations of the system, and the level of effort it involves.
There are a few key points to emphasize.
First, design systems are intended to grow and evolve; the first version will not include everything your product owners and customers think they want.
Second, while the design system should include a documentation site with code examples and snippets, your developers will not be able to simply copy and paste the example code for full functionality.
Lastly, design systems take a significant level of effort and time to accomplish.
Again, design systems are never fully complete. There are always more items to account for as you introduce new functionality to an application or a new use case is considered.
Impact Assessment
Integrating a design system into an application’s code base can be tricky. It is a good idea to take a simple planned component for the design system — a basic button, for example — and work through the process of integrating it into your primary selected application. This will give you a baseline level of effort and, ideally, expose any previously unknown blockers to account for during implementation. You should expect implementation of the system to be more complex than your team anticipates, but this should help you get ahead of the game and increase the accuracy of your estimates.
Building the Backlog
At projekt202, we take a user experience-centric approach to building out the initial stories within the backlog. You can find more information on our research-backed design process here.
Regardless of the process you choose to follow, start small and maintain focus. If this is your first foray into building a backlog for a design system, it can be daunting. You are defining the early steps in a never-ending process and it is hard to know where to start. The easiest approach is often the simplest: start with the basics. There are essential elements to every design system that must be defined first. Color palette, button styles, REM and font may be good design starting points.
When planning your sprint backlogs, design should always lead development by at least one sprint. That way, any changes to designs can be accommodated prior to a developer using the designs.
If you wish, your team can get a head-start on development stories by going through each page of your applications and defining all of the components, intended functionality, field restrictions, triggers and server side calls. This will allow any developer — even those unfamiliar with your applications — to pick up the story and understand what is needed, and subsequently provide a level-of-effort estimate.
If you already have this defined in an application reference manual or run book of sorts, that’s great. Simply pull from that resource as needed. If you do not, then you can leverage this activity to build one, and continue to use it as an application reference to onboard new developers and reduce ramp-up time. It’s a win-win.
Remember, despite the desire to include all of your organization’s applications in the initial release of the design system, start small. Include other applications for consideration during design phases, but stay focused on your key applications.
Team Structure
There is not a perfect team structure when it comes to designing and implementing design systems. We have a few design team structure variants that we have recommended, but the best fit for your organization may be vastly different from another.
The best structure for your development and management teams can vary based on your existing process requirements, responsibilities within the teams, and even the software you use to manage your teams, infrastructure and code.
One example:
We have found that the best way to determine your team structure is to go for what you think will work and adjust when necessary. Can it be messy? Absolutely. From our experience, once you develop a feel for your various teams, only minor adjustments are necessary to keep things on track and increase velocity over time. The needs of your team will surface during Retrospectives and Reviews, and no two teams will be exactly alike.
The takeaway is that there is no silver bullet for the team structure werewolf. Pivot based on your team’s preferences and needs, and you will arrive at the best solution.
Sprints
You have worked tirelessly to get everything prepped and organized, and your teams are chomping at the bit to get started. So, let’s go.
As we discussed above, you want your design teams to stay ahead of your development teams. To ensure that happens, you need to give your design teams enough lead time to do what they do best: design. If it works best to start both teams at the same time, do so. Your design teams can get started defining the elements in the system and a few notable components. So, what should the developers work on while they wait?
Depending on the choices your development teams have made over time — specifically with regard to application architecture and new feature implementations — your applications may not be ready to accept the elements and components of a design system. What was the right choice at the time may now rear its ugly head as a need to rework several piece, or all of the pieces.
This is where your prior efforts of working through the integration of a planned component pay dividends by clarifying what needs to be completed for integration of the successful design system. The foundational work needed for the design system and potentially the applications will provide enough for your developers to execute prior to the design system being ready to consume. Then, you get to be ahead of the game when it is time to begin utilizing the system, since all of your pre-work will be finished.
Dive into your scrum process, plan your sprint and start delivering results.
Progress Upkeep
This is your road trip down a two-lane highway through small towns with speed traps. There will be slowdowns, but you will reach your destination.
Work closely with the application product owners to ensure evolving priorities, exceptions and extraneous use cases are accounted for as you move forward. You should expect changes to designs and component customizations as the application teams work through integrating the design system. Continue to monitor design and development team progress to ensure you are sticking to your release schedule and budget. Identify overlap between the teams, especially as multiple application teams work through integrating the system. There will likely be efficiencies that the teams can gain by working together to tackle potential issues. Most importantly, ensure your teams have everything they need to get the work done.
Field the stakeholder questions, manage the design and development team needs, over-communicate, and be the champion for the end-users.
Staying On Target
As your team works through integration and the design system continues to grow, there will be ideas for improvements to the applications, the current version of the design system, and future iterations of both.
That’s great, because your team is invested in the system and they are beginning to see potential improvements that can be made. However, they may not be a priority for the current project. Write a story for the idea and log it in the idea backlog. A separate backlog for future enhancements eliminates the risk of clutter in your project backlog, and allows the stakeholder and product owners to groom and prioritize enhancements without the influence of in-scope items.
Your backlog should only include items that are feasible during your project timeframe. That may span several releases and many product versions, but do your best to keep it relevant to what is reasonable and accomplishable in the current-state applications. It is not an easy balance, and you will need to find the ideal fulcrum point for your teams.
Governance
A design system will fail to provide value for your organization if it is not properly maintained. A team of people will be needed to maintain the design system, and ensure it is utilized and enhanced properly.
There are two major facets to the design system: design and development. You will need a person to manage each side of the equation to ensure alignment is maintained.
When an application team approaches the design system team with a need for a new component, it needs to be thoughtfully considered. There may be potential to leverage something that already exists with minor adjustments or the designers need to have a focused discussion around the requirements. You would then follow the normal cadence of component creation and application integration.
Ensuring that duplicate — or near-duplicate — designs and components don’t end up in the design system is essential for future adoption and clarity of purpose. If you have five or even 10 different minor variances of a component within the design system, how will application teams be able to determine which to use?
Now come the difficult discussions around design system governance. It is expected that application teams will want to add their component versions to the design system. Their reasoning is sound: it should be there for them to reference in the future, right? Not exactly.
This is another one of those “do what is best for your team” scenarios, but we have a solid rule of thumb to guide you. If the modified component will be used by other applications in the same manner, then it may be a good fit to be added back into the system.
However, if the modified component is only used in that manner within the single application, then it is likely not fit for inclusion in the design system, even if it is used heavily throughout that application.
The design system should be application-agnostic. If a component has to be modified in a different way for each application into which it is integrated, that is acceptable, as long as the base component is generalized enough to make sense for each of the various applications. This is a tough concept to master and one that is likely going to take some time for your teams to get used to.
Ideally, in the long run, your applications can make adjustments to more readily accept the design system components, or, conversely, the component needs to be updated to better fit your expanding application landscape.
Conclusion
Design systems are the best ways to bring your varied application suite together for a harmonious user experience. They are not easy or quick to build, but the gains around application design and maintenance over time more than pay back the required investment. They also provide abundant cross-application efficiencies that your customers will appreciate.
Managing the creation and implementation of a design system is a challenge, but certainly a rewarding one. There are few projects that will provide the satisfaction of a clear and immediately noticeable improvement to an entire application suite.
Set and maintain expectations, find out what your users need, baseline your implementation efforts, maintain your backlog, stay focused, and help enforce governance.
