Invisible Success


The kind of work that I am often drawn to results in what Eric Bailey here calls “invisible success”, and I agree that it is difficult to make that visible. How do you prove that the work you did prevented a bunch of problems from ever happening? It is easier to get recognized as the hero who steps in and puts out a raging fire than it is to be the person who prevented the fire from ever starting in the first place.

Big, flashy things get noticed. Quiet, boring things don’t. A lot of design system work is the exact opposite of glamorous, and this effort is no exception.

In a business context, design system work means numbers go down. Less bug reports, faster design iteration, shorter development cycles, fewer visual inconsistencies, smaller staffing requirements that enable folks to work on more interesting challenges, etc. All good things.

Unfortunately, contemporary business practices only reward numbers going up. There isn’t much infrastructure in place to quantify the constant, silent, boring, predictable, round-the-clock passive successes of this aspect of design systems after the initial effort is complete.

A lack of bug reports, accessibility issues, design tweaks, etc. are all objectively great, but there are no easy datapoints you can measure here. By this, I mean it is difficult to quantify a void.

Eric recommends spending effort on storytelling to help here, which I think is spot on.

Identifying and collecting various ways to weave compelling narratives about the invisible, successful work you’ve done, and then putting those stories in front of the people who need to know them.

Leave a Reply

Your email address will not be published. Required fields are marked *