You are a product manager supporting multiple sites for your organization. One Tuesday afternoon you start seeing a handful of tickets from your “Website Feedback” link in your site’s footer. They are all about the multi-select dropdown.

You investigate and find that the checkbox icon is missing. You can still make selections, but there’s a broken image link where the icon should be. You also observe that the up and down arrows are also displaying broken links.

It’s a visual defect and a poor customer experience.

In today’s world you would most likely open a support ticket with IT. While you classified it as Critical, you still need to plead your case to the Board. This takes a day. Once you win someone in IT has to isolate the problem. This is very common, even in small organizations.

You detailed the ticket correctly with Steps to Reproduce, Expected Result, Actual Result, but it still takes them two days to figure it out. They fix the issue, you test it in the staging environment, approve the fix, and wait until the next deployment on Monday.

Meanwhile, your analytics tell you that 10,347 customers had a broken experience, and you have received over 50 notifications about the issue.

A conservative estimate of the person-hours required to address this issue would be about $1,000. Additionally, your customers have been enduring a broken experience for a week. This does not reflect well on your brand. It could have been fixed in minutes, very few customers would have been impacted, and your brand would be relatively unblemished.

Upon confirming the issue you navigate to the Multi-Select Dropdown component in the functional design system. Knowing it’s a presentation layer issue, you click on the Presentation tab and find Annotations F and J, which describe the Deselected and Selected states, respectively, of the Checkbox element.

You see that both the Deselected and Selected states use the .dropdown-checkbox-wrapper and .dropdown-checkbox CSS classes. They also use an asset called dropdown-controls-sprite.png in the /icons/sprites/ folder of your digital asset manager (DAM).

The Expand/Collapse icons use the .arrow-container, .arrow, .arrow-container, .arrow-CTA-down, and .arrow-CTA-up CSS classes. However, these also use dropdown-controls-sprite.png.

In a matter of minutes you have isolated the issue.

The design system tool links to the form-controls.css file where the CSS classes live, and it links to the /icons/sprites folder of your DAM. You could explore the CSS but you’re highly certain the issue is with the sprite. In the icons/sprites folder you search for dropdown-controls-sprite.png and it’s not there. What now? Next you sort all assets by last updated and at the top of the list there’s a file called asjfdsds.png that was last saved 36 minutes ago. You open it and find the four images that represent your up/down arrows and your selected/deselected checkboxes.

You’ve solved the case. To resolve the issue you need to rename the file back to dropdown-controls-sprite.png. Immediately you return to the live page where you observed the issue and invoke the multi-select dropdown. Before clicking on it you notice the down arrow is appearing. This tells you that your fix worked. You invoke the dropdown and all the arrows and checkboxes are behaving as expected.

Meanwhile, there are two more inbox notifications about the broken assets. Using your generic “Web Support” email address, you respond everyone notifying them it has been resolved, asking them to re-test to confirm, and thanking them for reporting the issue. A few respond back saying it looks good, some thank you for following up..

With the help of the design system tool you managed to clear a costly issue within minutes of hearing about it. You didn’t need a ticket or a software deployment or a justification for marking it a critical defect. You owned it. This is what digital product managers do.