2025 Bolt Survey Recap

• Summary of results
• New efforts for 2026
  • Modularity
  • New components
  • AI accelerators
  • Upskilling
  • Bolt 8
• Continued efforts
  • Support
  • Component build
  • Component documentation
• Additional feedback
  • Customization
  • Figma limitations
  • Handoffs

Bolt's annual survey provides its users a chance to share their experiences, while helping our team ensure we're on the right track.

In this article, we'll break down what we heard in that survey, and how it relates to our plans for 2026. Some of these plans involve new efforts to improve Bolt, while others are a renewal of commitment to the work that already serves consumers well. Finally, we'll address feedback not covered by our plans for 2026, including questions that can be addressed by capabilities Bolt already provides.

The 2025 survey had 49 respondents across UX and IT, up from 40 in 2024. The overall scores were remarkably similar to the previous year. Most respondents were satisfied with Bolt in general, and the highest scores went to Bolt's support, documentation, and modern appearance. The lowest scores (though still positive overall) were Bolt's flexibility and the number of components it provides.

Qualitatively, the comments reinforced and expanded on the same trends seen in the quantitative data. The written feedback was immensely helpful for evaluating our 2026 plans, what's working well, and what may need extra attention.

The strongest request among UX respondents was for more new components, and for more visibility into what components we have planned. We've already taken a few steps to address this in 2026, by adding a component roadmap and performing an industry-based analysis of coverage.

In the current landscape, it would be hard to write about the future of any technology without acknowledging the potential of AI. A number of survey comments mentioned desire for combining Bolt with AI, whether that's making our system more compatible with AI-driven coding and design tools, or using AI to enhance the capabilities of our own team and expand our output. In order to explore these possibilities in earnest, the Bolt team now has a dedicated AI specialist role, with Chris Webb acting as Design Intelligence Lead.

While velocity may be impacted in the short term by one of our existing developers transitioning to a new focus area, the hope is that investing in these new technologies will help us scale up in the long term. It should not only help us support the steadily increasing use of Bolt across the enterprise, but also allow us to respond to changes in the needs of Bolt consumers as we enter a new technological era.

While people were generally highly satisfied with Bolt's documentation and support, some mentioned they would love to have a wider variety of resources for learning about Bolt. In alignment with this, one of our big goals for the year is to create stronger onboarding content for both designers and developers, allowing new users to learn about Bolt independently and at their own pace. The survey feedback highlighted the importance of exploring multiple modalities as we create those resources-- many people learn best in different ways, and having a variety of formats will improve the accessibility of that knowledge. These might include interactive courses, videos, showcases of real-world Bolt use, or interconnected examples and patterns.

An interesting proposal we hadn't considered was creating skill checks-- not only providing knowledge about Bolt, but also ways to assess knowledge gaps about the system and recommend applicable resources. Along those lines, we are investigating whether Bolt may be able to make use of educational tools used for other courses at Nationwide, and potentially even provide credit through those systems. And since Bolt has joined forces under a larger Design and Research Operations umbrella, we are especially well situated this year to learn from the work of others at Nationwide and create empowering educational experiences.

Although many already know this, 2026 will be the first calendar year without a planned major release of Bolt. This change received several positive mentions in the survey feedback, with teams appreciating the increased stability and longer period of support between upgrades. With its new 2 year cadence, Bolt will begin work on version 8 this year, with a targeted release in early 2027.

Depending on the outcome of the Build Your Own Bolt exploration, those changes could provide a backbone for the scope of Bolt 8. Additionally, updates to brand colors could have widespread impact, and may be a defining feature of a next major release. Though, it may be possible to provide early access to brand updates through the opt-in future theme.

Regardless of which changes make it into Bolt 8, releases will almost certainly be larger on a 2 year cadence. To offset this, we plan to dedicate resources this year toward upgrade assistant tools, and finding ways to ease the burden of those upgrades on our consumers.

"If it ain't broke, don't fix it."

As we add new initiatives this year, we also want to ensure capacity for the things that already serve our consumers well. Identifying what's gone right is just as impactful, and sometimes even harder to pinpoint than what's gone wrong.

Bolt provides synchronous support through office hours sessions twice per week, and asynchronous support primarily through its teams channels. Both of these were highlighted in comments as especially helpful resources, and we plan to keep investing the same time and energy into them.

For the most part, comments were extremely satisfied with the speed of issue resolutions. We will continue to prioritize defect fixes, and have typically been able to resolve any issues in time for the next release, even providing extra mid-month releases when necessary.

The one exception to support satisfaction was in the case of requests for structural or compatibility issues, which some felt were not being addressed. While those are a larger undertaking than straightforward defect fixes, we hope that our investigation into modular Bolt use this year provides more confidence that those questions are at least being heard and considered.

Although consumers would like to see more components from Bolt, comments were extremely positive about the components that already exist.

In particular, respondents praised Bolt's components for their accessibility, usability, alignment with standards, and for looking good out of the box. While some voiced a desire for the ability to directly modify components, a larger proportion specifically appreciated that the components look and feel consistent across experiences, and felt positively about having guardrails in place.

The question of consistency versus flexibility is something we continue to weigh with each new component, but the feedback indicates we are generally striking close to the right balance in these decisions. We plan to continue evaluating requests for customization along the same metrics we use now, analyzing the impact of decisions across many possible scenarios and building in as much usability and accessibility into each component as possible.

While approaching new components through this lens can be time-consuming, we believe it is more effective in the long run for us to make those design decisions from a top-down perspective. Our team takes on more design and testing burden upfront, thinking through all allowable scenarios, so that individual teams can more confidently pick up and use pieces that have already been thoroughly vetted and not have to solve the same questions again and again.

One of our big exploratory efforts last year was adding Storybook and Code Connect integration for components-- though we weren't entirely sure how much value these would have in the eyes of consumers.

It turns out, people loved both of them.

As mentioned previously regarding new component build, the survey results included conflicting feedback regarding customization. Some people wanted additional flexibility, while others appreciated the structured options provided by Bolt.

Some of the comments in the survey requested configurations that are already provided by Bolt, though not everyone may be aware of these possibilities.

For data-dense applications, there are a number of configurations that can be used to comfortably display more information on the page. This includes global density configuration, locking responsive typography to a minimum size, or opting into a larger grid breakpoint.

Similarly, the HTML pattern versions of components may provide direct access and control that some are looking for with components, although these come with a few tradeoffs. While the web components provide built-in behavior and accessibility, developers will have a greater burden wiring up HTML versions and ensuring they meet requirements and standards.

Additionally, just because the HTML versions can be modified doesn't mean they should. Any modifications to Bolt assets are considered at-your-own-risk, and may come with a risk of breaking changes between major versions, or additional tech debt when it comes time to upgrade.

Several designers reported frustration when trying to interpret Bolt's style utilities in Figma, especially in the case of typography. Unfortunately, there is simply not a great way to indicate CSS classes with Figma's existing functionality. While this comes up most often with typography classes, it also affects other CSS style utilities such as spacing classes or background color classes.

For now, our recommendation is to cross reference the variable names in a design against corresponding documentation for typography, spacing, and color classes. We also strongly encourage you to let Figma know about this limitation, which our team has already done, and we will continue to advocate for solutions.

A final interesting pattern that emerged was that both designers and developers voiced concerns surrounding handoffs.

In both cases, the comments stated that this was not an issue with Bolt itself. But since Bolt is a common factor, we will be keeping an eye on those scenarios to see if we can proactively do anything to reduce friction.

On the UX side, designers mentioned that developers seemed hesitant to ask questions about using Bolt, or to ask for clarification when running into issues with a design. On the IT side, developers mentioned receiving designs that were not possible to build with Bolt-- either components had been configured in ways code did not permit, or elements looked very similar to Bolt, but were not actual Bolt components. These issues may have been coming from older Bolt libraries, and may be at least partially solved by upgrading to versions that are more tightly synced with Code Connect for easier handoff.

Regardless of the source of the issues, we encourage teams to reach out whenever they are unsure or have questions about using Bolt.

Hearing from teams is the best way for us to grow, and we greatly appreciate all of the feedback we receive, from annual surveys to everyday interactions throughout the year.