Denis Kharchenko — Lead Product Designer
I started making the Maintenance Library because I kept running into the same problem in different design teams: Figma files became difficult to understand once someone other than their author had to work with them.
Every designer developed their own way of organising projects. One file might have a clear structure, another might mix exploration, current work and old versions together, and another might organise everything around the designer's own mental model.
That wasn't a problem while the file stayed with its author. It became a problem as soon as the work crossed a boundary. A PM needed to review something. An engineer needed to find the latest design. Another designer needed to continue the work. Instead of understanding the project, they first had to understand how that particular Figma file had been organised.
I kept seeing this happen, so I started turning the recurring parts of that structure into a Figma library. The first version contained fairly simple things: headers, sections, task structures and other building blocks for organising design work. Rather than recreating the same structure at the beginning of every project, I could pull it from the library and start working.
That made the system deliberately lightweight. It wasn't another process designers had to remember or another document they had to follow. The structure was already there in the tool they were using.
Over the next five years, I kept rebuilding it. I've used versions of the Maintenance Library in three different companies and adapted it to different teams, projects and ways of working. Some things became unnecessary and were removed. Other parts became too rigid and were simplified. New patterns appeared as new problems showed up.
The library therefore became less like a fixed template and more like a running record of what I've learned about organising design work.
The specific components changed quite a lot. The underlying idea didn't.
"I want someone to be able to open a Figma file they didn't create and understand enough of its structure without having to ask the author for a guided tour."
That means making a few things predictable:
The goal isn't perfect consistency. A file can be perfectly consistent and still be difficult to navigate. What matters more is shared structure: enough of a common language that people don't have to learn a new organisational system every time they open another designer's file.
The library has changed because the way I work has changed. Early versions were mostly about keeping files organised. Later versions became more concerned with collaboration, handoff and making the state of work easier to understand.
The tools changed too. Figma introduced new capabilities, teams started working differently, and the boundary between design and implementation became less clear.
I don't want the library to preserve an old way of working just because it worked before. So I treat it as something that needs maintenance in the literal sense of the word.
I remove things that have stopped being useful. I simplify things that have become too complicated. I add structures when a new recurring problem appears.
That has made the library useful beyond the individual components it contains. It gives me a place to turn repeated observations about how design work happens into something reusable.
This is probably the reason I've kept using the idea for so long. The Maintenance Library started as a way to avoid doing the same organisational work over and over again. Over time, it became a way of encoding some of the working knowledge that normally stays in people's heads.
A designer doesn't need to remember every convention. The file already contains some of them. A new team member doesn't need to learn every designer's personal system. There is at least a common starting point. And when the way of working changes, the library can change with it.
"That's the pattern I keep coming back to in my work: when a problem appears repeatedly, I would rather turn it into a reusable system than keep solving the same problem manually."
The Maintenance Library is a small example of that idea.
I've just been maintaining it for five years.
More case studies and notes: denisxko.com · full text of everything: /llms-full.txt
© Denis Kharchenko. All rights reserved.