Photo by Gabriel Rodrigues

For fifteen years, I've used Balsamiq on almost every UX job I've ever had (I checked my 1Password earlier and I have 35 unique logins for different projects and clients). I loved Balsamiq because it was the fastest wireframing tool on the market.

Not because it had more features than its competitors, but because it had fewer. The scratchy pencil sketch aesthetic, the Comic Sans typography, the deliberately constrained component library: all of it was designed to make one thing blazing fast: iterating on information architecture before we started discussing visual design.

Then they redesigned the interface. And in doing so, they forgot the fundamental principle that made their product so valuable in the first place: interaction cost.

What Is Interaction Cost?

Interaction cost is the total mental and physical effort users spend to reach their goals when using a website or app.

A direct measure of usability. Every successful product spends enormous resources minimising it. Ideally, you want almost-zero interaction costs: a user thinks of a goal, and it just happens, but that's not realistic, because most products do many things. So instead, users look around, read, scroll, click, wait for pages to load, remember information from one screen to apply it on another and so on. All of these physical and mental actions add up to interaction cost.

Highly usable products minimise this cost across multiple dimensions:

Mental Interaction Cost (Cognitive Load)

The brain power you spend learning, reading, remembering and figuring things out. It increases when tasks require more attention and memory to complete.

Your working memory is limited. Psychologist George Miller famously demonstrated that the average person can hold only 5 items (plus or minus 2) in working memory at one time. Good interfaces work with this constraint through techniques like chunking information into meaningful units, using short paragraphs, clear visual hierarchy, and grouping related items together.

Recognising things is easier than remembering things. It's far easier to recognise something when you see it than to recall it from memory. This is why labelled buttons outperform icon-only interfaces—unless you're using those icons so frequently that they become second nature. Making field labels visible, providing step-by-step tutorials in context rather than forcing users through documentation, and using familiar design patterns all reduce the mental cost.

Physical Interaction Cost

Clicking, scrolling, typing, and moving between interface elements.

Fitts's Law describes how some aspects of this works: the time required to move and click a target relates to distance-to-the-target divided by the size-of-the-target. Longer distances and smaller targets both increase interaction time.

This is why mobile interfaces need larger buttons, and why toolbars with persistent locations, especially pinned to sides and corners, are faster to use than context menus that appear in unpredictable positions.

Measuring Interaction Cost

You can measure interaction cost through task analysis—the process of observing users to understand how they perform tasks and achieve goals. A task-analysis can map the mental and physical steps required to complete a goal, revealing:

• Total number of tasks: Are there opportunities to remove steps?

• Frequency of tasks: Which operations are repetitive?

• Cognitive complexity: How much mental load does each step generate?

• Physical requirements: Could these affect performance or accessibility?

• Time taken: Which steps add unnecessary duration?

Why Interaction Cost Matters

Expected utility = Expected benefits - Expected interaction costs

That formula governs every product decision users make, including HOW they use your product and IF they will use your product.

People naturally want to maximise expected utility. When there are multiple ways to reach the same goal with similar benefits, they'll choose the path of least resistance. Designers call this a desire path.

But when the interaction cost of using your site or app becomes too high, people will simply choose a different product. This is why interaction cost isn't an academic concern—it's an existential one. The more effort you ask of them, the greater reward they expect.

If the benefits stay the same but the costs go up, the expected utility goes down. The formula is unforgiving: A product that increases interaction cost is a product that's decreasing its own value.

Balsamiq's Forgotten Fundamentals

Balsamiq launched in 2008 as a wireframing tool that understood one thing perfectly: time-to-results matters more than sophistication, and their value proposition was explicit about speed and how that impacts outcomes:

Wireframe your way to faster, better product decisions.
Turn product ideas into clear visuals in seconds....

What is Wireframing?

Although the definition has crept in recent years, wireframing is traditionally an exercise in information architecture, not interface or interaction design.

It's the practice of creating sketch drawings in low fidelity to allow fast iteration on content before committing to hierarchies and flows across a website or application.

The value of working in low fidelity is the separation of concerns: you focus on content and layout, not pixels and polish. This reduces cognitive load and lets everyone in the design process discuss content and structure without getting derailed by visual design decisions.

Balsamiq seemed to understand this deeply. The scratchy aesthetic and Comic Sans typography weren't just stylistic choices—they were functional constraints. You couldn't do visual design in Balsamiq. That was its power. You could only focus on information architecture, which is exactly what wireframing is supposed to be about.

You could make something just tidy enough to understand.

The Old Interface: Designed for Speed

In the old Balsamiq interface, selecting a component on the canvas revealed all available properties and actions in a persistent sidebar. The properties were:

• Immediately visible: Zero clicks required to see what you could configure

• Clearly labelled: No need to memorise icon meanings

• Consistently located: The sidebar didn't move, disappear, or change position based on canvas navigation

• Logically organised: Properties were grouped in a sensible order

Apart from occasionally scrolling within the sidebar, you could configure components almost as fast as you could think. One click to select a component, immediate access to all properties.

That's minimal interaction cost by design.

The New Interface: Design Pattern Cargo-Culting

The new interface replaces the sidebar with a minimal floating 'selection toolbar'.

• Appears above the selected component: Position varies based on where the component is on the canvas

• Uses unlabelled icons: You must memorise what each icon means

• Hides properties in nested submenus: Some properties require clicking through two or three levels of navigation

• Scrolls off-viewport: If you navigate the canvas while a component is selected, the toolbar disappears

• Changes between components: The same property uses different icons depending on which component type you're working with

Comparing Old & New

Lets think about a simple everyday task for a wireframer: configuring a button component with custom text, a colour, and a link.

In the old interface, I might:

1. 1.

   Click the button component on the canvas

2. 2.

   See all properties visible in sidebar, always in the same position

3. 3.

   Edit text in visible field

4. 4.

   Select colour from labelled dropdown

5. 5.

   Set link in visible field

6. 6.

   Add an icon from the dropdown

That's 4 actions, taking about 10 seconds with the minimal cognitive load.

In the new interface, I must:

1. 1.

   Click the button component on the canvas

2. 2.

   Find the toolbar when it appears in a new position

3. 3.

   Scan row of icons to find text option

4. 4.

   Click into text submenu

5. 5.

   Navigate back out, locate colour options among unlabelled icons

6. 6.

   Click through to find link property ("which submenu was that in?")

7. 7.

   Add an icon from the dropdown menu (which changes icon every time)

8. 8.

   Repeat if toolbar scrolled off-screen during canvas navigation

That means more actions, more clicks, more time and more mental effort for a simple and frequent operation.

Every Dimension of Interaction Cost Increased

Recognition Replaced with Recall

Nielsen's heuristic #6 is "recognition rather than recall".

Systems should minimise the information users must remember. Labels let you recognise the option you need. Icon-only interfaces force you to recall what each icon means. Some icons are so universal, they're immediately recognisable. Like the B and I that signal bold and italic text. But most, must be learned.

The old sidebar used recognition. The new floating toolbar uses recall. And worse: the icons aren't even consistent between component types. The same property (such as auto-resize) uses different symbols depending on the selected component. Now, you're not just building a single icon vocabulary, you're memorising multiple icons and forced to account for inconsistency.

Can you feel your brain getting tired?

Fitts's Law Violations

The floating toolbar violates Fitts's Law in at least three ways:

1. 1.

   Moving target: The toolbar position changes based on component location. Your muscle memory for "where is the colour picker" is invalidated with every component you select in a different position on the canvas.

2. 2.

   Disappearing target: The toolbar can disappears off-screen during canvas navigation, and is only visible on component selection. This requires me to scroll and re-select the component to make it reappear.

3. 3.

   Smaller target: Individual icon buttons are smaller than the labelled sidebar fields were, increasing error rate potential, plus the time to find and click targets.

The old sidebar had a fixed location and was constantly visibility. These are optimal conditions for building muscle memory and minimising physical effort. The floating toolbar destroyed both of these advantages.

Working Memory Overload

The old sidebar required minimal working memory: scan visible labels, click the one you need. Nothing was hidden in sub-menus. The new toolbar requires you to maintain a mental map of:

• What each unlabelled icon means

• Which properties are in which submenus

• How the icon meanings change between component types

• Whether the toolbar is currently visible or has scrolled off-screen

That's 4 additional cognitive burdens for every single component configuration! Multiply across 50 components in a wireframe. Multiply across a day's work. The accumulated cost is potentially exhausting.

How Did This Happen?

The floating toolbar is a design pattern borrowed from visual design tools. It makes sense in those contexts because.

• Canvas real estate is precious for pixel-perfect visual work

• Users configure fewer properties more deeply (extensive colour adjustments, precise positioning, complex layer effects)

• Visual designers expect to memorise complex tool palettes as part of professional expertise

• The pace of work is slower because each component receives detailed styling attention

But wireframing is the opposite use case:

• Canvas real estate management is less relevant because you're sketching, not pixel-pushing

• Users configure many properties shallowly (lots of components, basic configurations, rapid iteration)

• Speed users need fast menus with immediate labelled access because memorising icon vocabularies is pure overhead that doesn't contribute to information architecture thinking

• The pace of work must be fast because the entire value proposition is rapid iteration

This is design pattern cargo-culting: copying an interaction pattern from a different product category without understanding why it works there or whether it solves an actual problem in your context.

The floating toolbar is a solution looking for a problem. And by implementing it, Balsamiq created a much worse problem: they made rapid wireframing slow.

A Category Error

Balsamiq succeeded precisely because it wasn't a visual design tool. It was the anti-Figma. The constrained component library, the deliberately 'ugly' aesthetic, the focus on content over form—all of it positioned Balsamiq as the tool you used before you opened Figma.

Are Balsamiq trying to compete with Figma? That's a category error. They built a genuinely great product by understanding the use case and optimising ruthlessly. This redesign suggests they've forgotten their primary proposition and values:

• Simplicity beats complexity
  The best tools get out of your way (!!!)

• Clarity leads to better products

The Solution?

Interaction cost is a measurable usability metric and clicks count, especially the wasted ones. Consider the mental load. Compare alternatives quantitatively. Task analysis exists for a reason. Use it. Map the steps required to complete core workflows. Count actions. Measure timing. Identify mental overheads.

Do not cargo-cult design patterns from other product categories without understanding whether they actually solve the problem in your context.

The best design is not 'less on screen'. The best design helps me to achieve my goals and gain benefits without paying high interaction costs to achieve it.

Dear Balsamiq

You built a truly great product by understanding that rapid iteration requires minimising interaction costs. This redesign broke that fundamental principle. Without a rollback, your power users (people like me who've been using Balsamiq for more than a decade) will haemorrhage productivity.

The formula is simple. The expected utility of Balsamiq has decreased because the interaction costs have increased the burden of use while the benefits stays the same. The solution is obvious.

Restore the sidebar! (and remember to count the cost of design changes)

🙏