For most of its life, business software got a pass on feeling good to use. The logic was simple: nobody chooses enterprise software for fun. A procurement officer signs a contract, an IT department rolls it out, and employees are simply told to use it. Unlike a consumer app that lives or dies by whether people enjoy opening it, B2B software has historically survived on lock in, training manuals, and the sunk cost of a multi year contract.

That logic is starting to fall apart, and the data backing it up has been piling up for years. Companies that treat design as a core discipline rather than a coat of paint applied at the end of a build cycle are outperforming their peers on revenue, shareholder returns, and product delivery speed by wide margins. The research is no longer anecdotal. It comes from McKinsey, Forrester, IBM, Salesforce, Atlassian, and the Nielsen Norman Group, and it converges on a single, somewhat uncomfortable conclusion for anyone still building B2B software the old way: design thinking isn’t a nice to have for enterprise products. It is one of the clearest, most measurable levers a SaaS company has.

What the numbers actually say #

In 2018, McKinsey published one of the most rigorous studies ever conducted on the financial value of design. The firm tracked the design practices of 300 publicly listed companies across multiple countries and industries over five years, collecting more than two million pieces of financial data and cataloguing over 100,000 individual design actions, things like whether a company had a design leader on its executive board or tied bonuses to customer satisfaction scores. From that mountain of data, McKinsey built the McKinsey Design Index, a single score reflecting how seriously a company treats design.

The companies that landed in the top quarter of that index grew revenue 32 percentage points faster than their industry peers over the five year period, and delivered 56 percentage points higher total returns to shareholders. Those results held across medical technology, consumer goods, and retail banking, three industries with very little in common except that all of them sell to demanding, sophisticated buyers. McKinsey also found that more than 40 percent of the companies it studied weren’t talking to their end users at all during product development, and roughly half had no objective way to measure their own design output. In other words, half the market is still flying blind on the thing that correlates most strongly with outsized growth.

Forrester’s research tells a similar story from a different angle. The firm’s Total Economic Impact studies, a methodology it has used for two decades to model the financial return of specific technology investments, have repeatedly found that organizations investing in user experience research and design see measurable gains in retention, conversion, and cost savings. One often cited Forrester derived figure puts the return on UX investment at roughly 100 dollars for every dollar spent, an implied return on investment north of 9,900 percent. That number gets thrown around so often it has become something of a cliché in design circles, but the underlying pattern, that UX investment pays back many times over, shows up again and again in Forrester’s more recent, narrower studies too. A 2025 Forrester TEI study of a continuous user testing program found that organizations adopting ongoing UX research saw revenue retention climb 3.6 percent in year one, 7.2 percent in year two, and 10.8 percent by year three, even after the firm’s standard risk adjustments.

None of this would matter much if B2B software were already good. It generally isn’t. The Nielsen Norman Group, the research firm cofounded by usability pioneer Jakob Nielsen, has spent decades documenting why. In a foundational piece on enterprise usability, Nielsen pointed out that business software has to succeed at three separate, nested levels: the individual user trying to complete a task, the group of people who depend on each other to get work done inside the tool, and the enterprise as a whole, where total cost of ownership, training overhead, and IT administration become usability problems in their own right. A beautifully designed individual screen can still be an enterprise usability disaster if it requires a help desk army to support or breaks every time two departments are on different software versions. Most product teams only design for the first of those three levels. Almost none design deliberately for all three.

Why B2B is a fundamentally different design problem #

It’s tempting to assume that B2B software just needs a B2C style makeover: cleaner typography, friendlier copy, fewer clicks. That assumption misses what actually makes business software hard.

Consumer products are usually designed around a single decision maker who is also the end user. B2B software almost never has that luxury. Gartner’s research on enterprise purchasing puts the typical B2B buying group at six to ten stakeholders for complex software decisions, and other recent analyses, including Forrester’s 2024 State of Business Buying report, put the average closer to thirteen people spanning multiple departments, with enterprise scale deals sometimes exceeding twenty. Gartner has also found that nearly three out of four B2B buying teams experience what it calls unhealthy conflict during the decision process, and that teams who manage to reach genuine internal consensus are two and a half times more likely to report the resulting deal as high quality.

That complexity doesn’t disappear once the contract is signed. It just moves from the sales process into the product itself. The person who approved the software purchase is rarely the person logging in every day. The administrator configuring permissions has different goals than the salesperson updating a pipeline, who has different goals than the finance lead pulling a quarterly report. A single SaaS platform is effectively being used by several different audiences simultaneously, each with their own mental model of what the software is even for.

The Nielsen Norman Group’s own B2B usability research, based on 12 focus groups and one on one usability testing with 55 business users performing real tasks from their actual jobs, found that this multi audience problem shows up constantly in small, frustrating ways. A common one: B2B platforms segment their content or navigation by criteria, like company size, that sound objective on paper but don’t match how customers actually see themselves. A 40 person company might think of itself as a scrappy startup or as a serious mid market operation depending entirely on its industry and ambitions, and software that forces a rigid label onto that identity creates friction before a user even finds the feature they came for. The researchers also noted that B2B sites tend to suffer worse usability than consumer ecommerce sites partly because the connection between a design decision and a sale is so much less direct. A retailer can watch its conversion rate move in real time when it changes a checkout button. A B2B software vendor might not feel the cost of a confusing onboarding flow for months, by which time it shows up as a vague, hard to diagnose rise in churn or support tickets rather than an obvious design failure.

Two companies that took design thinking seriously, and what happened #

The clearest way to see the impact of design thinking on B2B software is to look at companies that adopted it deliberately and had the discipline to measure the results.

IBM is probably the most studied example. After investing heavily in what it calls Enterprise Design Thinking, training more than 100,000 employees across the company and standing up a global network of roughly 50 design studios, IBM commissioned Forrester to independently evaluate the financial impact. Forrester interviewed IBM clients directly and surveyed 60 senior executives at Fortune 1000 sized organizations that had adopted the practice, then built a composite financial model from the results. The findings: teams using IBM’s design thinking framework cut the time needed for initial design and alignment by 75 percent. Minor projects that used to take 24 weeks were finished in 16, saving roughly 223,000 dollars per project. Major projects dropped from 60 weeks to 40, saving over a million dollars each. One health and human services organization cut software defects by more than half simply by building user research and iterative testing into its process from the start. Aggregated across a composite organization, Forrester calculated 48.4 million dollars in benefits against 12 million dollars in costs over three years, for a net present value of roughly 36 million dollars and a return on investment of 301 percent. Multiple executives interviewed for the study described release cycles shrinking from six to eight months down to three or four.

Salesforce offers a different but related lesson, less about a one time redesign and more about what happens when a company decides design needs to scale with the product instead of trailing behind it. Salesforce’s design system started small in 2013, an internal framework called Landmark built ahead of the company’s first major mobile push. By 2015 the team had merged its visual guidelines with an actual CSS framework, and in 2016 that combined system, by then renamed the Salesforce Lightning Design System after CEO Marc Benioff embraced it, was folded directly into Salesforce’s core codebase. The company eventually open sourced it, making it one of the first large scale enterprise design systems available to the public. The payoff showed up in productivity numbers that Salesforce and Forrester have since published: Lightning users report saving up to ten hours per employee per week compared with the older interface, developers see a 25 to 50 percent reduction in build time when using prebuilt Lightning components, and one Forrester Total Economic Impact analysis credited the migration with a 341 percent return on investment and 3.4 million dollars in net present value for the organizations studied. In its newest iteration, called SLDS 2, Salesforce introduced what it calls styling hooks, CSS variables that let individual organizations and partners restyle and rebrand their instance of the product without touching the underlying component code. That single architectural decision is the difference between a design system that enforces sameness and one that enables customization at scale, a distinction this article comes back to below.

A smaller but very concrete example comes from the Nielsen Norman Group’s own case study archive. A research firm called Marketade was brought in to help Baileigh Industrial, which sells complex, expensive machinery like computer programmable rotary draw benders priced between 11,000 and 80,000 dollars, fix a website where customers couldn’t find the technical information they needed before buying. Marketade started by interviewing the company’s own sales representatives, who already knew exactly where customers got stuck because they were the ones fielding the resulting phone calls. After restructuring the site’s information architecture based on that research, the team measured an 85 percent improvement in findability, well above the roughly 75 percent average improvement NN/g has documented across more than 40 of its own redesign case studies. The lesson generalizes well beyond machinery: the people on the front line of customer confusion, sales engineers, support agents, customer success managers, are often the fastest, cheapest source of design research a B2B company already has on payroll.

The real challenge: every business is not the same business #

Here is where most write ups of design thinking in B2B software stop short. It’s relatively easy to argue that B2B software should be more usable. It’s much harder to explain how a single SaaS platform, sold to thousands of different organizations with different workflows, org charts, and vocabularies, can possibly deliver a custom feeling interaction to every one of them without collapsing under its own complexity or going broke trying.

The honest answer is that you don’t customize the interface for every customer. You customize the configuration, and you standardize the architecture underneath it. This is the core insight that separates B2B design systems like Salesforce’s and Atlassian’s from a typical static style guide, and it’s the part of design thinking that engineering and product teams most need to internalize, because it determines whether good design scales or just gets reinvented, badly, with every new enterprise contract.

Atlassian’s experience building its design system is instructive precisely because the company’s products, Jira, Confluence, Trello, and others, are used by wildly different kinds of teams, from software engineers to marketing departments to construction project managers. The design organization that maintains Atlassian’s system grew from six designers in 2012 to a team spanning multiple disciplines, eventually supporting more than a dozen products across cloud and on premise deployments used by millions of people. The team’s own retrospective on what made the system actually work is candid about what failed early on: simply building a beautiful component library wasn’t enough. What mattered more was a layered system of design tokens, structured variables that capture a design decision once (a particular shade of blue, a spacing unit, a border radius) and let every product reuse it without redefining it from scratch. Most mature systems, including IBM’s widely referenced Carbon Design System, organize these tokens into three tiers: global tokens that hold raw values, semantic or alias tokens that describe how those values should be used (a background color, a warning color), and component level tokens that apply those decisions to a specific button or card. When a brand needs its own identity inside a shared system, teams can swap out the values behind a semantic token, like color brand primary, without touching a single line of component code. That is what makes white labeling, multi brand theming, and per customer visual customization possible without forking the product into dozens of incompatible versions.

This tiered token approach solves the visual half of the customization problem. The interaction half, the actual workflows, permissions, and information density that different roles and different businesses need, gets solved through a related but distinct discipline: modular, configuration driven product architecture. Instead of hard coding a single dashboard, a well designed B2B platform builds a set of composable building blocks, modules, fields, automation rules, permission scopes, and lets each organization assemble its own version of the product by combining and sequencing those blocks. The administrator at a hundred person logistics company and the administrator at a five thousand person hospital network are using the same underlying component library and the same underlying data model. They are not using the same configuration.

A practical framework: how to build custom interactions that actually scale #

Pulling the research together, a few concrete principles emerge for product and design teams trying to do this well.

Start with role based research, not company based research. The mistake many B2B teams make is segmenting their user research by industry or company size, the same trap NN/g found in its B2B usability work. A more durable approach is to research by role and by job to be done. An operations manager at a logistics company and an operations manager at a hospital network have more in common with each other than either has with a salesperson inside their own organization. Design around the job, and the industry specific customization becomes a configuration layer on top, not a redesign for every vertical.

Separate the design language from the product configuration. This is the lesson from Salesforce’s styling hooks and Atlassian’s token tiers. Visual identity, color, type, spacing, should live in a layer that any customer or business unit can adjust without engineering involvement. Functional configuration, which modules are visible, which fields are required, which automations run, should live in a separate layer that product and customer success teams can adjust through settings rather than code. When these two layers are tangled together, every customization request turns into a custom build. When they’re separated, customization becomes self service.

Design for progressive disclosure across roles, not one screen for everyone. A platform used by both an individual contributor and an executive should not show both of them the same dashboard with different permissions bolted on. The contributor needs depth on their immediate task; the executive needs breadth across the organization. Building distinct, role aware entry points into the same underlying data, rather than one dense screen that tries to serve both, is what actually delivers the “custom feeling” experience research shows drives retention, without requiring a unique build for every customer.

Treat your own support and sales teams as a standing research panel. The Baileigh case study is a useful reminder that a company doesn’t need a large research budget to find its highest impact usability problems. Sales engineers, onboarding specialists, and support agents already absorb the friction customers experience daily. A lightweight, recurring practice of interviewing them, the same starting point Marketade used, often surfaces the same issues a formal study would, at a fraction of the cost and time.

Measure design the way you measure revenue. McKinsey’s research found that the companies getting the biggest financial return from design were the ones tracking design performance with the same rigor as their P&L, not the ones with the most talented individual designers. That means setting concrete usability and adoption metrics, time to first value, task completion rates, support ticket volume per feature, and reviewing them at the same cadence and in the same rooms where revenue and churn get reviewed.

Build governance before you build flexibility. Both Atlassian and Salesforce learned, sometimes the hard way, that a system flexible enough to be customized is also flexible enough to fragment into chaos without active stewardship. A dedicated design systems function, even a small one, that documents patterns, reviews new components, and actively governs how tokens and modules are extended is what keeps a thousand customer specific configurations from turning into a thousand subtly broken products.

The bigger picture #

It’s worth stepping back to notice what these companies have in common. None of them treated design thinking as a branding exercise or a single redesign sprint. IBM built an internal certification program reaching a third of its global workforce. Salesforce built design directly into its engineering pipeline through an open sourced system used by its own product teams every day. Atlassian built a dedicated organization whose entire job is making sure flexibility doesn’t come at the cost of coherence. In every case, the empathy that design thinking is famous for, understanding the actual human trying to get a task done, got translated into something durable and structural: a token system, a research cadence, a governance model, rather than staying a one time workshop with sticky notes.

That distinction matters more now than it ever has. As AI lowers the cost of building software features, the technical capability gap between SaaS competitors is shrinking fast. What is much harder to copy is an organization’s accumulated understanding of how its specific users actually work, encoded into a system flexible enough to serve a thousand different businesses without feeling generic to any one of them. The research is consistent on this point across a decade of studies from McKinsey, Forrester, and the Nielsen Norman Group: the companies that build that understanding deliberately, and design the architecture to scale it, are the ones pulling ahead on growth, retention, and the only metric that ultimately funds a design team’s existence, revenue.

Sources and further reading #

• McKinsey & Company, “The Business Value of Design,” 2018
• Forrester Consulting, “The Total Economic Impact of IBM’s Design Thinking Practice,” commissioned by IBM, 2018
• Forrester Total Economic Impact studies referenced in Salesforce Lightning implementation analyses, and Forrester’s continuous UX research TEI modeling, 2025
• Nielsen Norman Group, “Enterprise Usability,” Jakob Nielsen, 2005
• Nielsen Norman Group, “B2B Usability” research and “Quantifying UX Improvements” case study series
• Gartner, research on B2B buying group size and buyer conflict, 2023 to 2025
• Salesforce Trailhead, “Learn How and Why We Developed SLDS”
• Atlassian Design, public documentation on the Atlassian Design System and design tokens