Francesco Improta

The design system nobody uses

Wed, 01 Apr 2026 00:00:00 +0000

After years working on design systems, I learned that adoption doesn’t fail at launch. It fails six months later, quietly, when people find faster ways to work around what you built.

And yet it keeps happening. Teams spend months building solid foundations — semantic tokens, accessible components, polished documentation — only to watch designers still using hardcoded colors in Figma and developers copying styles from some old file. The system exists, but nothing changes.

The problem is almost never technical.

The numbers back this up. According to the zeroheight’s Design Systems Report 2026, only 7% of teams report full adoption across all teams. For the fifth consecutive year, driving adoption tops the list of the biggest challenges in the field. Five years in a row. It’s not a new problem waiting for a new solution. It’s a structural one that the industry keeps not solving.

Adoption is a trust problem

Here’s the counterintuitive part: 91% of teams report moderate to high trust in their design system. People trust the system. They just don’t use it consistently. The report itself puts it bluntly: trust isn’t the bottleneck. Something else is.

When a designer skips the design system, the real reason is rarely “I don’t know how it works.” It’s usually: I don’t trust it to be flexible enough for what I need or last time I used it, I lost more time than I saved.

These are perceptions, not facts. But perceptions drive behavior.

A design system earns adoption when the people who should use it feel it’s on their side. That it helps them work better, rather than forcing them into compromises.

The gap between builders and users

The team building the system and the people using it daily rarely share the same perspective. The system team thinks in terms of consistency, scalability, and maintainability. The product designer thinks about delivering the screen by Thursday.

These priorities don’t have to conflict, but they often feel like they do.

Governance isn’t control

One mistake I’ve seen repeatedly: treating governance as a permissions problem. Who can add components, who can modify tokens, who approves PRs. All valid, but nowhere near enough.

Real governance is an ongoing conversation. Who flags when a component doesn’t cover a real use case? How are those requests tracked? How quickly are they resolved?

The 2026 report reveals a telling gap here: 44% of teams don’t focus on community building at all, and across all 147 teams surveyed, only one had a dedicated full-time person for it. Yet communication and community rank among the top drivers of adoption. Teams know it matters. They just don’t invest in it.

When the feedback channel is slow or opaque, people stop using it. They start solving problems on their own, outside the system. Which is exactly what you don’t want.

A healthy design system has clear contribution paths, predictable response times, and — most importantly — shows that feedback actually leads somewhere. Even when the answer is “we can’t do this right now, and here’s why.”

Adoption as a metric, not a hope

Measure adoption. Go beyond the number of published components or documentation coverage. Look at how many product screens actually use system components. How many tokens get overridden. How often the system gets updated versus worked around.

Only 41% of teams currently measure adoption in any meaningful way. That’s the same industry that wonders why leadership buy-in is dropping — down from 42% to 32% satisfied in just one year. You can’t make the case for resources if you can’t show the data.

These numbers are uncomfortable at first. But they’re the only ones that tell you where you really stand.

The best-adopted design system isn’t the most complete one. It’s the one that figured out how to be genuinely useful to the people it’s supposed to serve, in the work they do every day.

—
Data from the Design Systems Report 2026 by zeroheight.

Shipping features is not product success

Mon, 09 Mar 2026 00:00:00 +0000

Most product teams are measured by what they ship. Roadmaps are full of features. Sprints end with releases. Stakeholders celebrate launches. And yet, months later, nobody uses what was built.

This is the most common — and most quietly destructive — mistake in product design: confusing output with outcome. The two are not the same, and pretending they are is costing teams time, money, and trust.

The Shipping Fallacy

The idea that more features equals more product success is intuitive. You add value, users get more, everyone wins. But this mental model collapses as soon as you look at the data.

The research firm Standish Group estimated that 64% of features shipped in software products are rarely or never used. Pendo’s 2019 Product Benchmark report found similar numbers: nearly 80% of features go unused. These aren’t outliers or anecdotes. They are the baseline.

The reason this keeps happening is structural. Teams are incentivized to ship, not to deliver outcomes. Velocity is measured in story points and release notes, not in user behavior change or business impact. Product managers who kill features or slow down to do proper discovery are seen as blockers. Those who ship are seen as high performers — even when what they shipped doesn’t move any meaningful metric.

Why Features Fail to Create Value

Shipping a feature doesn’t create value. It creates potential value that only materializes if users:

Discover the feature exists
Understand what it’s for and why it matters to them
Try it at least once in a relevant context
Succeed in using it to accomplish their goal
Repeat the behavior until it becomes part of their workflow

Most features break down at step one or two. Changelog posts and release emails are not discovery mechanisms. In-product discoverability is almost always an afterthought. And even when users find the feature, they’re rarely given enough context to understand its value before they bounce.

A feature isn’t done when it ships but when users adopt it, delivering the outcome it was designed for.

The Real Cost of Feature Accumulation

Every feature you ship and nobody uses isn’t just a wasted sprint. It’s compounding debt paid in four currencies:

Cognitive load: Every feature adds to the surface area of your product. Users have to mentally navigate and filter more UI, more options, more decisions. This is the reason why simple, focused tools often beat feature-rich ones in user satisfaction.
Maintenance cost: Code doesn’t sit still. Features need to be tested, updated, and kept working as the system evolves. Dead features still consume engineering time.
Onboarding friction: The more features a product has, the harder it is to onboard new users. Every unused capability is a distraction on the path to first value.
Strategic clarity: A bloated product is harder to position, harder to explain, and harder to rally a team around. Feature creep is often a symptom of unclear strategy masquerading as responsiveness.

Redefining What “Done” Means

The fix isn’t to ship less but changing what you optimize for:

Set adoption targets before you build

For every feature, define a specific, measurable adoption goal before scoping begins. Not “we hope users find it useful” but: “Within 60 days of launch, 30% of eligible users will use this feature at least twice.” If you can’t define what success looks like, you’re not ready to build.

Make activation part of the design brief

The UX of a feature should include the full path from zero to first value, including how users discover it, what triggers them to try it, and what happens if they get stuck. Design the activation arc, not just the feature screen.

Audit your feature surface regularly

Quarterly, pull usage data on every significant feature. For anything below a meaningful usage threshold, make an explicit decision: invest in activation, redesign, or deprecate. Don’t let low-adoption features become furniture, always present, never questioned.

Kill things with the same rigor you build them

Deprecating a feature should be as celebrated as launching one. It means your team had the discipline to follow the data, reduce complexity, and refocus. Build a culture where removing things is a sign of product maturity, not failure.

Measure outcomes, not outputs

Change your team’s performance vocabulary. Replace “we shipped 12 features this quarter” with “feature X drove a 15% increase in weekly active users” or “we deprecated 4 underused flows and reduced onboarding time by 20%.” What gets measured gets optimized.

The Uncomfortable Truth

The shipping fallacy persists because it’s comfortable. Shipping feels like progress. It’s visible, it’s concrete, and it’s easy to celebrate. Outcome-driven product work is slower, more uncertain, and harder to report up to leadership.

But the teams that break this habit — that measure themselves by user behavior change rather than release frequency — build products people actually use. And that, in the end, is the only metric that matters.

Looking back to 2025

Wed, 31 Dec 2025 00:00:00 +0000

2025 has been a year of building. Slowly, deliberately, and often behind the scenes. It’s been less about chasing trends and more about turning ideas I’ve had for a long time into something concrete, usable, and shared with others.

Teaching Design Systems, one workshop at a time

This year I officially launched my workshops dedicated to Design Systems, with a strong focus on Interface Inventory and Design Tokens. They’re the kind of work that usually gets postponed, underestimated, or rushed and then comes back as technical debt.

The goal of these workshops was simple: help designers and developers step back, observe what already exists, and turn chaos into structure.

Interface Inventory Workshop as a way to see the product for what it really is
Design Tokens Workshop as a shared language between design and code

The Interface Inventory workshop reached over 5 classes this year, and the Design Tokens workshop is quickly catching up. The feedback has been overwhelmingly positive, with many attendees reporting immediate improvements in their design systems and workflows.

What I enjoyed most was watching people recognize the same problems I’ve faced for years, and realizing they’re not alone in that struggle.

Back to public speaking: Accessibility Days, Milan

2025 also marked my return to public speaking.

I had the chance to speak at Accessibility Days in Milan, an event that has become a key reference point in Italy for accessibility and inclusive design. Getting back on stage after some time away was both exciting and grounding.

My talk focused on accessibility and Design Systems in the Italian context.

It felt good to bring together topics I deeply care about: accessibility, design systems, and real-world constraints, discussing them with a community that’s actively trying to improve things.

See the full talk on → YouTube.

Building an app I’ve wanted for years

Alongside teaching and speaking, I’ve been working on Token Lens an app dedicated to design tokens and production code.

Preview of the Token Lens app's analysis report interface

It’s a project that has been in my head for a long time.

As a designer who’s comfortable writing code, I’ve always felt a strong friction:we define solid design system foundations, but verifying their correct application is still painfully manual.

Design Tokens exist. Documentation exists. But control, validation, and real-world usage? That’s where things break.

This app is my attempt to solve common problems around design tokens by:

focusing on values, not naming conventions
helping teams understand what’s actually being used in production
making design system governance less fragile and less subjective

It’s still work in progress but I’m excited about the potential impact it could have on how teams manage design systems.

Beta release is planned for january 2026. Stay tuned!

Growing newsletters into something real

Another milestone of 2025: I passed 1,000+ subscribers across my two newsletters, Designabile and Design Tokens Pills.

Even more meaningful: I received my first paying subscribers.

That changed my perspective. It’s one thing when people read what you write. It’s another when they decide it’s worth supporting financially.

These newsletters have become a space where I can think out loud and share lessons from real projects, not theoretical frameworks

No growth hacks. No aggressive funnels. Just keep writing each month.

Read Designabile →

Read Design Tokens Pills →

Closing thoughts

Managing different projects simultaneously is not easy.

There are days when I feel lost, when even the simplest tasks seem impossible.

This year I tried to apply a simple principle: adapt my productivity to my mental state, without forcing it. I hope to continue in the same way in the new year.

Thanks to everyone who followed along, joined a workshop, subscribed, attended a talk, or simply sent a thoughtful message.

More to come.

Token Lens

Mon, 17 Nov 2025 00:00:00 +0000

I didn’t want to build just another checking tool. I wanted something simple like a flashlight. Point it at your CSS and get clear answers: which design tokens are actually being used, where they appear, and where things have changed without anyone noticing.

That’s how Token Lens was born.

It’s a tool that looks through your CSS (and token files) to show you what’s really happening, what’s missing, and the small inconsistencies that creep in when designs become code.

Design systems are supposed to keep things consistent. But then real work happens. Someone adds a quick 12px value. The brand gets updated. A token gets a new name. Another token gets copied with “-1” added to it. This isn’t anyone’s fault, it just happens over time.

I needed a simple way to find tokens that aren’t being used, spot places where the code uses actual values instead of tokens, and see which token categories (colors, spacing, fonts) are actually being used.

I wanted insights, not another tool in the build process. Something I could run whenever I needed to check. You upload token JSON and CSS, map token types to appropriate CSS properties, and get a simple report. It tells you what’s used and what’s missing, points to places with hardcoded values, and hints at which components (via classes) seem to use which tokens.

Nothing fancy. Just honest readouts.

First prototype

I built the first protoype in Balsamiq to sketch out the user flow and interface. I always find it the easiest tool to quickly mock up ideas without getting bogged down in design details.

I then built a simple React prototype using Cursor. It’s basic but functional, doing three things well:

Extracts values from CSS files, resolving custom properties as values;
Compares extracted values with design tokens definitions (JSON)
Highlights issues and improvements on design tokens coverage and adoption

Then I added a few more features:

Token usage by category: see which token categories (colors, spacing, fonts) are actually being used in the CSS.
Hardcoded values detection: spots places where actual values are used instead of tokens, helping identify potential inconsistencies.
Exportable reports: allows users to export the analysis results for sharing or further review.
Multi-file support: enables users to upload multiple CSS and token files for comprehensive analysis across larger projects.
User-friendly interface: designed to be intuitive and easy to navigate, ensuring users can quickly access the insights they need.
Performance optimization: ensures the tool runs efficiently, even with larger codebases and token sets.
Security and privacy: processes files locally in the browser to ensure user data remains private and secure.

As a designer, I was tempted to wrap-up it in Figma or a design tool. But I preferred to work directly on the real product to keep the focus on functionality and user experience.

Things I’m exploring next

I’m looking at churn, how often a token changes across releases. Stable tokens tend to signal trust, while volatile ones suggest uncertainty.

I’m also exploring fragmentation, near‑duplicate tokens with tiny value differences or name variants that quietly add entropy over time.

Finally, I’m experimenting with CI hooks and exports to make it trivial to run Lens on a pull request and attach a human‑readable diff.

What I deliberately didn’t build (yet)

I skipped real‑time IDE linting, design tool plugins, and heavy collaboration features. Those are great later.

Right now, the goal is to help one person run a check, see the truth, and start the right conversation.

Follow my progress

I’m sharing my journey in public on X, follow me there for updates and insights!

I'm working on a design tokens tracker named Token Lens.

It scans and compares design tokens definitions in JSON files with CSS properties.

Hope to publish a beta version later this month pic.twitter.com/UygKsvJkyb
— Francesco Improta (@zetareticoli) September 12, 2025

The Great Lock-In

Wed, 01 Oct 2025 00:00:00 +0000

Every year, as September rolls in, I notice the same energy online: people talking about the “Great Lock-In.”

The idea that between September and December you’re supposed to shut out the world, pick one project, and build something big, something meaningful, maybe even life-changing.

I get the appeal. After the chaos of summer, there’s a sense of focus, of fresh starts. But I can’t help feeling there’s also a darker side to this story. Because the way it’s framed, if you don’t come out of the year with a shiny new product, a successful side project, or some personal breakthrough, you’re left with the quiet sting of inadequacy. Like you’ve wasted the “magical window” that everyone else was smart enough to seize.

We’ve built this collective obsession with productivity, where every season, every moment has to be optimized. The September-December stretch becomes almost mythological: the time when unicorns are built, when focus supposedly comes easier, when discipline should flow naturally. But in reality? Most of us are just juggling work, family, and everyday chaos and no amount of “ambient productivity” will change that.

Another part of the narrative that bothers me is the idea that, with the right discipline, anyone can just lock in and achieve extraordinary results. It glosses over so many invisible factors: privilege, resources, luck. Success stories are rarely solitary, yet the “Great Lock-In” gets packaged like a formula: isolate, focus, produce. If only it were that simple.

Even our creative moments are being turned into something to optimize. “Post-summer clarity,” “lock-in partners” — the language itself feels like productivity-speak trying to capture something that’s supposed to be fluid and messy. Creativity doesn’t always fit into quarterly goals or calendar slots. When we try to package it that way, we risk squeezing the life out of it.

I’ve definitely felt it: that pressure to “choose one thing,” build walls around my time, and prove (mostly to myself) that I can achieve something big before the year ends. But often, the result isn’t motivation, it’s guilt. Because life doesn’t always bend to my productivity plans. Sometimes I’m tired. Sometimes the project doesn’t take off. Sometimes nothing happens, and that has to be okay.

The truth is, I don’t think creativity can be scheduled like this. Real breakthroughs often come sideways after failures, during downtime, or in moments that look unproductive from the outside. The obsession with “locking in” risks making us forget that. Maybe the most radical act right now isn’t producing more, faster, or better during the “Great Lock-In.” Maybe it’s allowing ourselves to follow the natural rhythms of our work and our lives.

Success doesn’t need to be squeezed into someone else’s timeline.

Accessibility Days

Tue, 20 May 2025 00:00:00 +0000

I had the privilege of presenting at Accessibility Days 2025 in Milan on 15th may, where I shared our journey with Design System .italia and the exciting developments we’ve been working on.

Design System .italia is a project that aims to create a unified design system for public services in Italy, ensuring that digital services are accessible and user-friendly for all citizens. My presentation focused on the importance of accessibility in design systems and how we can leverage our experiences to create more inclusive digital experiences.

The conference was held at the historic Istituto dei Ciechi di Milano (Milan Institute for the Blind), which provided a meaningful and fitting backdrop for our discussions on digital accessibility.

The historic façade of Istituto dei Ciechi di Milano, where the conference took place

The institute’s beautiful architecture and rich history in supporting visually impaired individuals added an extra layer of significance to our conversations about inclusive design.

The conference brought together accessibility experts, designers, and developers from across Italy, creating an ideal environment to discuss the evolution of digital accessibility standards.

During my session, I focused on our ongoing efforts to enhance the accessibility of Design System .italia, with particular emphasis on our card component redesign initiative. This project emerged from our commitment to creating truly inclusive digital experiences for all users.

The current implementation of our card component, while functional, revealed several opportunities for improvement through user testing and community feedback. We discovered that keyboard users were experiencing navigation challenges, while screen reader users encountered inconsistencies in how content was being presented.

To address these challenges, we’ve developed a comprehensive redesign approach. Our new implementation introduces a more intuitive keyboard navigation pattern, ensuring users can move through card content efficiently and predictably. Perhaps most importantly, we’ve restructured our semantic markup and ARIA attributes to provide a more coherent and informative experience for screen reader users.

The accessibility community warmly received the changes presented at the conference. Attendees enriched the discussion with insightful questions and observations that will guide our continued refinement of the implementation.

As we prepare to roll out these changes, it’s clear that our work on Design System .italia is more than just a technical upgrade – it’s a step toward ensuring digital services in Italy are truly accessible to everyone. The discussions and connections made at Accessibility Days 2025 will continue to inform our approach as we move forward.

This event showed us something important: making websites accessible means more than just checking off requirements. It’s about making sure everyone can use them easily, no matter how they browse the web. This idea will keep guiding us as we improve Design System .italia.

Design Systems Report 2025

Fri, 28 Mar 2025 00:00:00 +0000

Zeroheight’s “Design Systems Report 2025” offers an in-depth analysis of the industry.

Based on a sample of about 300 professionals, it provides a detailed overview of the evolution of this tool and identifies the main challenges to be faced.

Cover image of the Design Systems Report 2025

Key findings

1. Dedicated teams grow

One of the most interesting data concerns the growth of teams dedicated to design systems: more and more companies are investing resources and people to maintain and evolve these tools, a sign of a growing maturity in the industry. It is no longer just a practice for a few entities, but a strategic asset for many organizations.

2. Secrets to successful adoption

The data show that the adoption of an effective design system depends not only on technical quality, but also on communication andintegration into workflows. Teams that succeed in explaining the value of the design system to business leaders and educating colleagues achieve more widespread and smooth adoption.

3. Design tokens adoption is growing

84% of teams have adopted design tokens, confirming their importance in improving design consistency and efficiency.
Only 10% of teams are using AI for documentation and idea generation, suggesting that there is still plenty of room to experiment with new technologies.

4. Unification of design and code

Another key trend is the increasing focus on the design token pipeline.

When designers and developers work together to make these processes more fluid, the entire ecosystem benefits: more speed in rebranding, fewer errors, and more consistency between design and development.

A pipeline refers to an automated workflow that manages the transfer and transformation of design tokens from design to code. It is like a digital assembly line that ensures that visual components and their properties are translated correctly from design to technical implementation.

In practice, a pipeline automates processes such as:

the conversion of design values (colors, typography, spacing) into usable formats for developers
the synchronization of changes between design tools and code
the automatic generation of the code needed to implement the defined styles

5. Measuring success

More and more companies are realizing that it is critical to monitor the use of their design system.

Collecting data and feedback from internal users allows you to demonstrate the value of your investment and continuously improve the system.

6. What lies ahead in the future

The report confirms that design systems are becoming increasingly central to the world of design and development. Improving communication between teams, better integrating processes, and leveraging new technologies such as artificial intelligence are the challenges of the present and near future.

Go to the full report →

Priority Matrix

Thu, 16 Jan 2025 00:00:00 +0000

In this era of frantic productivity and endless distractions, knowing how to manage our priorities is essential.

One of the main challenges I’ve encountered concerns choosing the number of priority levels to use when organizing activities.

The 3-tier model

The traditional model includes three differnt levels:

low priority
medium priority
high priority

It’s a simple and versatile system. However, the real challenge lies in clearly distinguishing between these levels, as the boundaries between them can be blurred.

A matrix system

For this reason, I found more effective to set and use a matrix system, structured into four main quadrants

1. Important and Urgent Activities

These are tasks that require immediate attention and are crucial for our daily work. They are activities that cannot be postponed and have a significant impact on our goals.

Some examples include:

Managing a crisis with an important client
Solving a technical problem that’s blocking team work
Completing a delivery with immediate deadline
Responding to an urgent request from management

Identifying the true urgency of an activity can be complex: we often find ourselves with a long list of tasks that we consider urgent even when they’re not.

In these cases, it’s essential to analyze each activity and evaluate the real impact of not completing it within the day.

2. Important but Not Urgent Activities

This category includes activities that can be planned in advance and are characterized by medium to long-term deadlines.

These are activities that require strategic planning and often repeat over time. Some examples include:

Creating content for blogs and newsletters
Strategic planning of future projects
Professional skills development
System maintenance and updates
Networking and building professional relationships

3. Not Important but Urgent Activities

This category includes activities like emails and follow-ups. While requiring immediate attention, they don’t directly contribute to achieving our main objectives. Here are some examples:

Responding to routine or non-critical emails
Handling basic information requests
Participating in brief update calls
Following up on minor projects
Completing routine reports

These activities generally require little time, so it’s efficient to group them into one or more specific times of the day.

4. Not Important and Not Urgent Activities

For these tasks, the strategy is clear: eliminate or delegate them. These are activities that distract us without adding real value.

Here are some examples:

Browsing social media without a specific purpose
Continuously reorganizing your desk or computer files
Attending meetings not relevant to your role or projects
Checking emails repeatedly without necessity
Handling tasks that could be automated or delegated to others

These activities create distractions and don’t add real value to work. The optimal solution is to eliminate or delegate them when possible.

Whatever system you use, developing your own priority matrix has several advantages because it allows you to focus on the activities that really matter, reducing the stress related to managing too many tasks simultaneously.

2024 year in review

Tue, 31 Dec 2024 00:00:00 +0000

The Most Important Lesson: Embracing Imperfection

As we bid farewell to 2024, I find myself reflecting on what has been a transformative year. Among all the lessons learned, one stands out prominently: the art of accepting myself when things don’t go as planned.

The Pressure of Perfection

Like many others, I started the year with ambitious goals and carefully laid plans. Each project had its timeline, each deadline seemed set in stone. The weight of these self-imposed expectations was sometimes overwhelming.

When Reality Hits

Throughout the year, I encountered several instances where projects didn’t meet their intended mark, and deadlines had to be adjusted. Initially, these felt like personal failures, each missed target a blow to my professional identity.

The Turning Point

The breakthrough came when I realized that these “failures” weren’t really failures at all – they were opportunities for growth. Each missed deadline or project setback taught me something valuable about:

Setting realistic expectations
The importance of flexibility in planning
The value of self-compassion
The difference between perfectionism and excellence

What I’ve Learned

The most profound realization was that accepting imperfection doesn’t mean lowering standards. Instead, it means understanding that the path to success isn’t always linear. Sometimes, the detours and delays are essential parts of the journey.

Moving Forward

As I look ahead to 2025, I’m carrying this lesson with me: self-acceptance in the face of setbacks is not just helpful – it’s essential. It’s about maintaining perspective and understanding that our worth isn’t measured by our ability to meet every deadline or perfectly execute every project.

Wrap up the work before holidays

Wed, 18 Dec 2024 00:00:00 +0000

As the holiday season approaches, I face the challenge of balancing deadlines with festivities. With projects in full swing, I’m focused on maintaining productivity while embracing the season’s spirit.

Though holiday gatherings vie for attention, I’ll share strategies to balance both work responsibilities and social engagements effectively.

Prioritize ruthlessly

Let’s face it: sometimes, getting everything done before Christmas Eve is impossible. So what should you do?

Ruthless prioritization of the must-dos, setting realistic expectations on the nice-to-dos, being okay with the did-not-dos, and recognizing they can look way easier after a good break.

How achieve this in practice:

Create a list of ongoing projects
Categorise tasks as Essential (must complete before holidays) / Can be postponed to January / Non-critical tasks that can be deprioritised

Housekeeping

One method to make you feel better can be to do a digital declutter before you head out on your holidays.

I dedicate an annual end-of-year day to digital housekeeping:

Archive old emails
Back up files
Organize documents (check filenames, folder names, organization, etc.)
Clean up newsletter subscriptions
Clear out download folders
Update productivity tools

It’s ok to “stop”

Many of us struggle to enjoy holidays because we’re caught in a mindset that constant work is necessary to prevent disaster. Yet deep down, we know this isn’t true. Breaking free from work addiction is essential for restoring balance and finding genuine peace.