Managing Parallel Design System and App Development

At Bitovi, we embrace the concept of a design system. Global patterns and components provide standard look, feel, and reusability across a suite of applications. We have our own, and we often build them for our clients. Ideally, a design system is fully developed and available before building applications that will use it.

For many reasons, circumstances are often not ideal. Ocaissionally, teams must build design systems in parallel with the application work. What happens, then?

How to Write Tickets for a Design System

A design system is created and managed in a tool like Figma, which means design systems live separately from platforms software development teams use to track the backlog of work, like Jira.

In order to streamline the development work, you need Jira tickets representing each design system component to be built. You can create a custom work item type or use the standard User Story item with tagging or naming conventions to keep the work separate from application tickets in the backlog.

Managing Parallel Design System and App Development

You can place hyperlinks in each Jira ticket back to the specific Figma component (and vice versa, if desired).

Each ticket is written with a story-like description and acceptance criteria to guide the frontend developer in flexible implementation per the visual requirements. Using the Alert component as an example:

Description

The design system needs an alert component with status, title, and description inputs so that we have one flexible alert message indicating success, failure, or system information.

Acceptance Criteria

I can pass a status value of “success”, “failure,” or “system” to the Alert component.
- If status = “success”, the checkmark icon in dark green is shown, and the background color is light green, with no border around the alert box
- If status = “failure”, the exclamation point icon in dark red is shown, and the background color is light red, with no border around the alert box.
- If status = “system”, there is no icon, the background color is white, and there is a thin black border around the alert box.
I can pass a title value with text up-to-15 characters to be displayed in bold black text.
I can pass a description value with text up-to-50 characters to be displayed in standard black text.

In Jira, keeping these tickets as children of a Design System epic for common tracking and management is a good practice.

Connecting Components to Application Stories

Let’s say you’re on an application team, and a story you’re considering in planning the next sprint is:

Description

As a user, I want to be able to enter a new data record so that the record can be used by other workflows in our system.

Acceptance Criteria

Each field is populated from sets of pre-defined input possibilities.
The record is not completed until the user clicks the Save button.
The user is shown a success or failure confirmation.

A related goal is to add a “back out” function:

Description

As a user, I want to be able to “back out” the last record I added so that no other workflows are affected by data that should not be there.

Acceptance Criteria

There is a Back Out button.
A confirmation dialog is required before the last record added is deleted.

How do you know the design system components needed for your stories are ready before you commit to adding them to the next sprint?

One of the most powerful tools in Jira (or Microsoft ADO or other similar platforms) is link types showing which tickets block other tickets. It is also common to create a “dependant”/”depends on” link pairing to specify that the relationship is different from a typical issue which blocks other work from being done.

Managing Parallel Design System and App Development

In this case, the links from the “Create a new record” story indicate the item depends on three design system components, the “Back out” story two. In the other direction, the “Create a Button component” item would show it has two dependents, the other three Design System items one each.

The power of this approach comes on larger-scale projects with multiple Scrum teams working at scale on an application. Centralized tracking of the component work allows each team to take the feature designs they have using the system, determine which component tickets are needed for their stories and their status, and know they can safely start their own implementation if the component is not yet committed to work.

Planning the Sprint

In a scaled Agile process, you’d likely have one team developing the design system components and others developing the application features that use them.

On a smaller project, you would have to blend the two sets of work together in sprint planning and stack ranked to get the components done before each user story and create a new record before you try to back it out.

It may be challenging to have a common story-sizing approach when mixing component and user story development on the same team. Still, it’s essential to try to think of the work relative to the rest of the scrum team's work rather than having one relative scale for components and one for user stories.

Conclusion

Anyone who has been on a project or used an application where three developers made three different “Are You Sure?” dialog boxes is very aware of the value of a design system. Suppose you’re the Scrum Master or in another role on a team where the design components are being shared simultaneously with the actual application development, fear not. Keep everything distinct in a single source of project truth, such as Jira, with meaningful links to track dependencies, and you’ll keep delivery prioritized and velocity high!

Do you have a better way?

We’d love to hear about it! Join our Community Discord to chat about tech, seek assistance, and network.

Never miss an update!

Subscribe to the blog 📬