Francesco Improta

On the last redesign

Francesco Improta — Mon, 21 Sep 2026 00:00:00 +0000

For three years I kept this website alive with small commits: a fix here, a new post there, never the rewrite I knew it needed.

Last week I finally shipped v2.0: a full redesign of the layout, content architecture, case studies, and build pipeline.

Why a redesign, and why now

Because I’m about to change chapter. By the end of November I’ll leave the Italian Department of Digital Transformation — a journey that started four years ago. A site that no longer described my work was going to become a problem very soon.

So the goal became simple: make the site say clearly what I do — design systems and product design leadership — and then prove it. The old portfolio talked about projects; it never showed them.

Now every case study opens with context, challenge, and outcome, followed by a curated gallery. The long version is still there, just collapsed by default: skim it in thirty seconds, or expand it and read the whole story.

Main changes

Most of the work happened under the surface. What changed visually is the smallest part of it.

The styling system was reorganized around Tailwind CSS 4, centralized design tokens, light and dark themes, and locally hosted variable fonts—making the interface more consistent and easier to maintain.
A shared layout was introduced, with a desktop sidebar and a full-screen mobile navigation system featuring active-page states, keyboard dismissal, and focus management.
Dark mode now persists across visits through localStorage, while still respecting the system preference by default.
New structured templates were built for portfolio projects, posts, and workshops. These are more modular, responsive, and driven by structured content data rather than duplicated markup.
Media handling was improved with responsive images through Netlify Image CDN, srcset, lazy loading, asynchronous decoding, and videos that load only when they enter the viewport.
Performance was improved through versioned assets, long-lived immutable caching for CSS, JavaScript, and fonts, critical-resource preloading, and deferred loading of the ConvertKit script until user interaction.
SEO was strengthened with canonical URLs, dynamic meta descriptions and Open Graph tags, fallback social images, a sitemap, robots directives, and Schema.org structured data for the website, profile, articles, and case studies.
Accessibility received focused improvements, including better footer contrast, meaningful image alternatives and dimensions, semantic galleries, safer external links, and clearer navigation labels.
Legacy stylesheets and layouts were removed, while permanent redirects were added for older URLs and the Jekyll configuration was simplified.
The project also explored cross-page transitions during development, but these were ultimately removed from the final version to reduce rendering work and keep the experience lightweight.

What I learned along the way

Four things I’d tell myself before starting again:

Ship the structure before the styling. The sidebar and the work layout did more for the site than any visual refinement.
Let the content model drive the design. featured.yml exists because the homepage needed to change weekly without a deploy ritual.
Don’t run two design styles in parallel. Commenting out the legacy Sass was the moment the refactor became real.
Treat transitions and prefetch as design work. They’re the difference between a document and a product.

153 commits and one merge later, the site finally matches the way I actually work.

Go have a look.

Using AI as a product designer

Francesco Improta — Tue, 15 Sep 2026 00:00:00 +0000

My AI stack as a designer in 2026 looks very different from the one I used only a few years ago.

Claude → planning, brainstorming, and thinking out loud. Notion AI (Sonnet 5 / Opus 5) → writing specs, documentation, and content. Cursor Pro and Codex → turning design decisions into working software.

And then there’s the tool that is increasingly missing from the process: Figma.

I’m not saying Figma is no longer useful. I still use it for specific tasks: exploring visual directions, reviewing interface patterns, collaborating with other designers, or creating shared artifacts that a team can discuss. But it is no longer the automatic starting point for every product problem.

More and more often, I move directly from intent to code.

Challenge assumptions

Claude is where I start when the problem is still unclear.

I use it to unpack a brief, challenge assumptions, compare possible approaches, and turn scattered thoughts into a direction I can act on. It works less like a tool that gives me “the answer” and more like a thinking partner that helps me make the question better.

A typical session might include:

defining the actual user problem behind a feature request;
mapping constraints, risks, and open questions;
exploring alternative flows before committing to one;
reviewing the logic of an interaction;
stress-testing a decision from the perspectives of users, product, design, and engineering;
turning a vague idea into a sequence of experiments.

The point is to keep the reasoning visible. Rather than jumping too quickly into an interface, I can stay with the problem longer without slowing the process down.

Organize knowledge

Once the direction is clearer, I move into Notion where a simple conversation becomes a durable artifcat: product specs, decision logs, content drafts, project notes, principles, checklists, and documentation.

I mainly use Notion AI with Sonnet 5 or Opus 5 to:

structure rough notes without losing the original reasoning;
draft and refine product requirements;
turn design discussions into explicit decisions;
create documentation that connects intent, behavior, and implementation;
review writing for gaps, ambiguity, and unnecessary complexity;
reuse knowledge already stored in the workspace.
register meeting notes, archiving them in project page.

For me, this distinction matters. AI becomes far more useful when it operates within the context of a project rather than in an isolated chat. Knowledge behind the work should be easier to retrieve, question, update, and share.

Design in the real product context

Cursor Pro and Codex are where design becomes tangible.

I use them to build interface concepts, connect components, test states, refine responsive behavior, and work directly with the constraints of the real product. Instead of describing a design and waiting for someone else to interpret it, I can express the decision in the medium where it will ultimately live.

A coded prototype can reveal things that a static mockup often hides:

whether the layout survives real content;
how the interface behaves across breakpoints;
what happens in loading, empty, error, and edge-case states;
whether the interaction feels right rather than merely looking right;
how well the proposal fits the existing component library;
which design decisions create unnecessary implementation complexity.

Code is part of the design process itself. I don’t question that anymore.

Skipping the artifacts

The traditional workflow was linear: understand the problem, sketch a solution, create polished mockups, hand them off, and wait for implementation.

This process made sense when design and engineering relied on different tools, skills, and representations. But AI-assisted development has compressed the distance between an idea and a working interface.

For many problems, a high-fidelity mockup has become an expensive intermediate artifact. It can look complete while leaving the most important questions unanswered. The same interface then has to be rebuilt in code, where new constraints emerge and decisions are made again.

Going directly to code removes part of that translation layer.

Designing this way lets me work with real components, real tokens, real content, and real behavior from the start. Feedback also becomes more concrete, because people can interact with the proposal instead of imagining how a static screen might work.

Where design tools still fits

This is not a “Figma is dead” argument. Anzi, sono molto interessato a provare Paper nei prossimi giorni.

A design tool remains valuable when visual exploration is the work—when many people need a shared canvas, or when changing pixels is still cheaper than changing code. It’s also useful for mapping flows, documenting patterns, comparing directions, and maintaining design-system assets.

The difference is that I now choose Figma deliberately instead of using it by default.

If the core uncertainty is visual, I use a visual design tool. If the uncertainty is behavioral, structural, or technical, I would rather test it in code.

The stack is really a workflow

The tools matter less than the handoffs between them. I still make the decisions, evaluate the trade-offs, and take responsibility for the outcome. AI accelerates exploration and execution, but it does not replace judgment.

That’s the most important part of our role as designers.

What an interface inventory really tells you

Francesco Improta — Mon, 08 Jun 2026 00:00:00 +0000

I used to think an interface inventory was a tidying exercise. You open the product, screenshot the components, sort them by type, and at the end you’ve got a nice grid that says “look at the mess.” Everyone agrees there’s a mess, and you start consolidating.

I don’t think that anymore.

After running inventories on a handful of large products, I’ve started to think an interface inventory is closer to a confession. It’s not a tool to fix the system. It’s a mirror that forces a team to admit how the system was actually built, by whom, and against which deadlines.

That’s why nobody wants to look at it for too long.

The clean version

The story we tell to leadership is short. We collect every screen, extract every component, group them by category, find duplicates, and consolidate. The design system improves.

It fits in a slide. It has a “before” and an “after.” It makes a manager feel like the team is mature.

The problem is that the middle of that sequence is where the real work happens, and none of it is mechanical.

What I actually do

The moment I start sorting components, the categories begin to lie.

Take an accordion. Is it navigation, because it’s how a user reaches content? Is it disclosure, because it hides content until requested?

On one project we argued about this for 2 weeks. We weren’t arguing about the accordion. We were arguing about who, in the next release, would own it: the navigation squad or the content squad.

The taxonomy was a proxy for org chart.

Modals are worse. Where does a modal live in your inventory? Is it a layout element, a feedback element, or an anti-pattern you tolerate because legal asked for it?

I’ve seen the same team classify modals 3 different ways in the same audit, depending on who was holding the spreadsheet that day.

Or take a card you can click. The whole card is the affordance, with no button inside. Is the card a surface, or is it a button?

If you say “button,” your accessibility audit explodes overnight. If you say “surface,” your interaction model becomes inconsistent across the product. There is no right answer, only a choice, and the inventory forces you to make it in public.

These aren’t edge cases. They are the inventory.

The doubts I don’t write down

When I run an inventory, there are questions I quietly ask myself and almost never put on the wall.

Why are there 14 buttons? Usually it’s not because designers were sloppy. It’s because the design system never gave them the variant they needed, and they shipped what they had to ship by Friday.

Who designed this component? Sometimes I find a well-thought-out widget tucked into a corner of the product, and nobody on the current team remembers building it. The person who did the good work has often already left.

Which of these “duplicates” are actually duplicates? Two date pickers can look identical and behave in completely different ways. A pixel-level diff misses the point.

What would break if we deleted this one? A component on an inventory is just a screenshot. Removing it from the product means understanding flows, contracts with the backend, accessibility commitments, and, on public-sector work, sometimes a regulation.

The deepest question is the one I keep last. Am I cataloguing components, or am I cataloguing decisions the team has been avoiding? Mostly the second.

I keep these questions out of the artifact because the moment I put them in writing, the conversation stops being about design and starts being about blame. And blame kills consolidation faster than anything.

Inventory as politics

This is the part nobody writes about, so I will.

An interface inventory is a political act. The moment you put 14 buttons on a single page, you’re publicly stating that 13 of them shouldn’t exist. Every one of those 13 has a parent: a designer, a developer, a product manager who fought for it in some sprint planning 2 years ago.

Some of them are still in the room.

If you treat the inventory as a neutral artifact, those people will quietly defend their buttons. You’ll leave the workshop with 14 buttons still alive and a Miro board full of post-its.

If you treat it as a confession, you have a chance. You move from “whose button is right?” to “what did we mean to do, and what did we actually do?” That second question doesn’t have a winner.

On public-sector projects the stakes are higher. The duplicates aren’t just ugly. They are inconsistent experiences for citizens trying to do things they didn’t want to do in the first place.

“Which submit button is the real one?” isn’t a fun question to leave open when someone is renewing a permit at 11pm.

What I tell teams now, before we start

I’ve stopped opening interface inventories with a kickoff slide about taxonomies. I open with 3 sentences instead:

“We’re not going to find a clean answer.” This sets ambiguity as the working condition, not a failure mode. The PMs in the room visibly relax when I say it.

“Every duplicate has a reason, and most of those reasons aren’t ‘the designer was sloppy.’” I usually pair it with a concrete example, like the 4 different date pickers I once found in the same product, each shipped to satisfy a different legal or backend constraint. The blame in the room drops by half.

“The output of this exercise is a list of decisions to make, not a list of components to delete.” This one does most of the work. It reframes the inventory from a cleaning exercise into a governance exercise.

It tells PMs they’ll be asked to choose, engineers they’ll be asked to deprecate on a timeline, and designers that “consolidate” isn’t the same as “delete.” Some duplicates will survive the audit, because the cost of removing them is higher than the cost of keeping them.

What I’ve learned to do differently

I don’t inventory alone anymore. The wall of components is only meaningful when the team that built it is in the room reacting to it, because their faces tell you which components are politically expensive before anyone speaks.

I’ve also stopped sorting by appearance. Two visually identical buttons can do completely different things, and two visually different buttons can do the same thing. Sort by intent, and the duplicates appear in a much more honest place.

And I’ve made peace with the fact that some duplicates are correct. A public service for citizens and an internal back-office for operators may need 2 different “primary buttons,” even when the brand says otherwise. The inventory’s job is to surface the divergence, not to flatten it.

An interface inventory is not a tidying exercise. It’s a snapshot of every shortcut, every deadline, every org-chart fight, and every quiet act of design heroism that produced the product you have today.

If you’re honest about that, the inventory becomes useful. If you’re not, you get a beautiful Figma board, a few rationalized components, and the same problem 18 months later.

Either way, the wall doesn’t lie. You just have to be willing to read it.

Interactions hidden by gestures

Francesco Improta — Sun, 26 Apr 2026 00:00:00 +0000

How many features on your phone have you never discovered simply because no one told you they were there?

There is a class of design decisions that deserves more scrutiny than it usually gets: placing functionality behind interactions the user has no reason to attempt.

The long press is the canonical example. Hold your finger on an icon and a hidden menu surfaces. Hold it on a word and selection handles appear. Hold it on a message and reaction options emerge. The pattern is everywhere, and it is almost always invisible.

Explicit vs. implicit interactions

An explicit interaction is one you can see. A button, a labelled icon, a visible affordance — something that signals to the user that an action is possible here.

An implicit interaction leaves no trace. It operates through convention, muscle memory, or — more often than designers like to admit — accidental discovery. Long press, swipe-to-action, double-tap, pinch-to-zoom, pull-to-refresh: none of these announce themselves. They require prior knowledge to be found at all.

The assumption baked into implicit interactions is that the user already knows. That assumption is almost always wrong for at least part of your audience.

Why we keep doing it

The honest answer is interface cleanliness. Hiding complexity behind gestures is a convenient way to appear simple without actually being simple. Show every available action at all times and the screen becomes unmanageable. So designers reach for the implicit interaction as a tidy solution.

But there is a meaningful difference between simplifying and hiding. Simplifying means reducing real complexity — fewer features, more linear flows, fewer decisions. Hiding means relocating complexity from the interface into the user’s head. The screen looks cleaner. The user has to work harder.

When a core feature is only reachable through an invisible gesture, the interface has not been simplified. The cognitive load has simply been transferred.

An accessibility problem we tend to overlook

Implicit interactions are not just a discoverability issue. For a significant portion of users, they are an access barrier.

The long press is unreliable for people with hand tremors or limited motor control. Pinch-to-zoom fails for anyone using a single finger. Shake-to-undo — still present in iOS — is effectively unusable for many people. When any of these gestures is the only path to a feature, that feature is silently excluded from part of the audience.

The principle that should govern this is simple: an implicit interaction can be a shortcut, but it can never be the sole route.

When implicit interactions earn their place

They work well as accelerators for experienced users who have already learned the interface.

Drag and drop is a good example: the interaction adds speed for those who know it, but removing it entirely does not break the product.

They also work when a well-established convention makes them nearly legible. Pinch-to-zoom on an image is so pervasive it barely registers as implicit anymore. Even so, the best implementations pair it with visible controls.

The test is straightforward: if someone never discovers the gesture, can they still use the product fully? If the answer is no, the implicit interaction is a problem, not a feature.

A few practical adjustments

Audit your product’s implicit interactions and ask which features are accessible only through them.

For anything important, add a visible path: it does not need to be prominent, but it needs to exist. Use temporary visual hints, contextual tooltips, or onboarding moments to surface gestures that are genuinely worth discovering. And test with users who are new to the product, not with a team that has spent months internalising every shortcut.

Visual elegance is not an end in itself. An interface that looks calm by hiding half its functionality behind gestures it is an incomplete one.

The design system nobody uses

Francesco Improta — 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

Francesco Improta — 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

Francesco Improta — 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

Francesco Improta — 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

Francesco Improta — 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

Francesco Improta — 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.