The Five Axes of Interface Design: Why “User-Friendly” Means Nothing

And What to Say Instead

The term “user-friendly” has become the empty calorie of design vocabulary. It sounds nutritious, everyone nods along when someone uses it, but try to act on it and you’ll find there’s nothing there. The only reasonable interpretation of “user-friendly” is “friendly to the present user,” which tells you exactly nothing about what to build or why.

The phrase conflates at least five distinct properties that designers need to reason about separately. Collapsing them into a single term doesn’t just create vagueness, it creates what logicians call equivocation fallacies — arguments that seem sound but fall apart because a key term keeps shifting meaning mid-sentence.¹

Actionable Insight

Next time you hear “we need to make this more user-friendly” in a meeting — whether about a GUI, an API, or a configuration system — ask: “Do you mean simpler architecture, easier workflows, fewer options, better discoverability, or something else?” Watch the conversation transform.

What follows is a framework for thinking clearly about interface design by separating these properties into five distinct axes. The goal isn’t theoretical elegance, it’s preventing the cascading reasoning errors that happen when design teams use imprecise language.

This Applies Beyond GUIs

These axes apply to any interface, not just graphical ones — APIs, libraries, command line tools, configuration systems, and programming languages, to name a few. The Unix philosophy, “small tools that do one thing well,” is a stance on these axes:

• Simple (unbundled)
• Hard (requires composition)
• Large (many separate tools)
• Low certainty (users combine them in unpredictable ways).

“Batteries-included” frameworks like Rails take the opposite stance:

• Complex (bundled)
• Easy (conventions handle common cases)
• Small (few entry points)
• High certainty (the framework knows what you’re probably building)

Neither is wrong, but confusing the axes leads to incoherent design.

The Five Independent Axes

Each axis is independent. A system can be simple but hard, or complex but easy. Conflating them derails design discussions.

Axis 1: Simple vs. Complex

Rich Hickey, creator of the Clojure programming language, gave this distinction its clearest articulation in his influential 2011 talk “Simple Made Easy.” The etymology tells the story: simple comes from Latin roots meaning “one fold” or “one braid,” while complex means “braided together.”²

A simple system has components that are separate, independent, and unbundled. A complex system has components that are intertwined — where changing one thing necessarily affects others. Hickey uses the word “complect” (to braid together) to describe the act of adding complexity.

This is an objective property. Either things are braided together or they aren’t. You can look at a system and determine whether components can be understood and modified independently. You might disagree about whether the complexity is justified, but not about its existence.

The MikroTik router interface is extremely simple in this sense. Every setting is discrete. Port forwarding, firewall rules, DNS settings — they’re all separate configurations that don’t automatically affect each other. Nothing is bundled and nothing is assumed. Want to forward a port? You’ll need to understand the firewall, create NAT rules, and potentially configure multiple interfaces. Each piece stands alone.

A consumer TP-Link router, by contrast, is complex. When you forward a port, the router automatically adjusts firewall settings and bundles multiple underlying configurations into one user-facing action. These operations are braided together — you can’t easily untangle them.

The Counterintuitive Truth

The simple interface (MikroTik) is often described as “complicated,” while the complex interface (TP-Link) is called “simple.” This confusion happens because people conflate simplicity with ease. They’re measuring different things.

Axis 2: Easy vs. Hard

Easy and hard describe the effort required to accomplish a task. Unlike simplicity, ease is subjective and relative. Something is easy when it’s “near” the user — near their current knowledge, their available tools, and their mental models.³

The TP-Link router makes port forwarding easy. You navigate to a single screen, fill in a few fields, click save, and you’re done. The fact that this action internally triggers a dozen separate operations is hidden from you. The task is easy, precisely because multiple simple operations have been complected (braided) together.

MikroTik makes port forwarding hard. Each step is simple and independent, but there are many steps and you need to know what they are. The system doesn’t guess what you want.

“I could make Spanish easier for myself by spending time learning it. Same with piano, but the only way to make something complex simple is by spending the time untangling the web of knots.”

— Paul Cook, on Rich Hickey’s framework

Hickey makes a crucial point: you can make a hard thing easier by learning, by practicing, by becoming familiar. A proficient MikroTik user finds it quite easy to configure. But you cannot make a complex thing simple without actually untangling the braid. Complexity is structural; difficulty is experiential.

Actionable Insight

When evaluating tools, ask separately: “Is this system simple?” (can I understand each part independently) and “Is this system easy?” (can I accomplish my task quickly). The answers often differ — and both matter for different reasons.

Axis 3: Small vs. Large (Interface Size)

Interface size refers to the number of exposed options, controls, and decision points. A large interface has many visible elements. A small interface has few.

This might seem obviously related to easy/hard — smaller interfaces must be easier, right? This is not necessarily correct. Interface size primarily affects a different property: discoverability.

UX research consistently shows that discoverability depends heavily on interface size. As Nielsen Norman Group puts it: “if the user cannot find it, it does not exist.”⁴ A larger interface means more places to look, more cognitive load to scan options, more chance that the feature you need gets lost in the noise.

3DS Max vs. Blender: Size and Complexity Tradeoffs

3DS Max bundles operations into complex automated tools, keeping the interface smaller. Blender exposes individual tools, creating a larger, but simpler architecture. Both are valid tradeoffs.⁵

3DS Max, the professional 3D modeling software, maintains a smaller interface by bundling related operations into complex automated tools. Want to rig a character? There’s a dedicated Biped system that handles dozens of underlying operations. The interface stays smaller because complexity is hidden behind automation.

Blender, by contrast, exposes more of its underlying operations as separate tools. The interface is larger — more buttons, more panels, and more menus — each tool does one thing. The underlying architecture is simpler (less entangled), but the interface size is larger.

The same tradeoff appears in API design. A library with one doEverything(config) method has a small interface but complex internals — the config object must specify everything, and the method’s behavior depends on dozens of interacting options. A library with fifty focused methods has a larger interface but simpler architecture — each method does one thing, independently. The first is easier to start with; the second is easier to understand and debug.

Actionable Insight

When designing interfaces, track interface size as its own metric. Count the options visible at each level, then ask: does each exposed option earn its place, or is it just creating scanning overhead? The right size depends on user certainty (Axis 4).

Axis 4: Certain vs. Uncertain (Designer Certainty)

This axis describes how confident the designer can be about what the users are trying to accomplish. It’s perhaps the most important factor when determining what kind of interface is appropriate — and the most often ignored.

Consider the calculator app on your smartphone. Designers have near-total certainty about user intentions: people want to compute arithmetic. That’s it. This extreme certainty enables an interface that’s essentially just the domain itself — numbers and operators. There’s almost nothing to discover because there’s almost nothing to hide; the interface is the functionality.

Email sits one step back from that extreme. Designers can be highly certain about user intentions: people want to compose messages, read messages, organize messages, and search messages. The core user stories are well-understood and stable. This high certainty allows for a small, easy interface. Gmail’s compose window doesn’t expose SMTP settings, MIME encoding options, or header manipulation, because designers are certain those aren’t what most users need.

Now consider Blender again. Users might be modeling a character, creating architectural visualization, compositing video, simulating physics, generating procedural textures, or editing video. The designers have low certainty about user intentions because the software serves dozens of distinct workflows. This forces a larger interface with more exposed controls, because the designers can’t know which 20% of features any given user needs.

The spectrum runs from Calculator (near-total certainty, minimal interface) through Gmail (high certainty, small interface) to TP-Link routers (moderate certainty, medium interface) all the way to Blender and MikroTik (low certainty, large interface). Each position on this spectrum represents a legitimate design choice, not a quality judgment.

Certainty-Size Relationship

The spectrum from Calculator (near-total certainty) to Blender (low certainty). This tradeoff is unavoidable — when you don’t know what your users want, you have to give them options.

This creates an unavoidable tension:

There’s no way around this tradeoff. When you don’t know what users want, you have to give them options. When you give them options, finding the right option becomes harder.

Actionable Insight

Quantify your certainty. List the top 20 things users might try to accomplish, and weigh them by frequency. If 80% of users need only 20% of features, you can design a small interface for that 80% and progressively disclose the rest. If intentions are evenly distributed, you’re stuck with a larger interface — plan accordingly.

Axis 5: Discoverable vs. Hidden

Discoverability is how easily users can find and understand available functionality. It emerges from the intersection of interface size and certainty, but it’s worth tracking as a distinct axis because it’s what users actually experience.

A discoverable interface makes its capabilities apparent. When you look at it, you understand what you can do. An undiscoverable interface hides its capabilities — sometimes intentionally (to reduce clutter), sometimes accidentally (through poor organization).

The Interaction Design Foundation defines progressive disclosure as a strategy that “shows users only the most important or relevant information first, while hiding more advanced or less-used options until they’re needed.”⁶ It’s a way to cheat the certainty-size tradeoff — at least partially.

“Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.”

— Nielsen Norman Group

The pattern works well when designers have reliable data about what “essential” means for their users. This is where the 80/20 rule comes in: identify the 20% of intentions that cover 80% of users, make those maximally discoverable, and progressively disclose the rest.

Consumer routers do this with their “advanced settings” buttons. The main interface assumes common intentions (set up WiFi, maybe forward a port), while advanced users can access the full configuration space. It’s a multi-layer approach that serves both novices and experts, but only because the designers have good models of what different user populations need.

Actionable Insight

Audit your interface with fresh eyes. For each feature, ask: “How many clicks/taps are needed to reach this?” and “What percentage of users need this?” Plot them. Features that many users need but few can find are discoverability failures. Features that few users need but everyone can see are clutter — candidates for progressive disclosure.

Counterintuitive Correlations

Once you separate these axes, you’ll notice relationships that seem paradoxical until you realize the apparent paradox was created by conflating terms in the first place.

Complex Often Means Small and Discoverable

When operations are bundled together (complex), the interface exposes fewer options (small), and users can find high-level tasks more easily (discoverable). TP-Link’s “Port Forwarding” screen is highly discoverable — users find it immediately — but it achieves this by complecting NAT rules, firewall configuration, and routing logic into a single, bundled operation. The complexity enables the discoverability.

In API design, the same pattern appears. A framework with a createUser(email, password) method is discoverable and small — one function does the job, but internally it’s complex: it handles validation, password hashing, database insertion, email verification setup, and logging. The complexity is hidden, making the interface both small and discoverable.

The unbundled alternative — separate functions for each operation — is simple, but larger and less discoverable. New users won’t know which functions to call or in what order.

Simple Often Means Large and Hard

MikroTik’s RouterOS is structurally simple: each configuration element is independent, but this simplicity creates a large interface (many separate options) and makes tasks hard (you must understand how to combine the pieces). The simplicity is precisely why it’s harder to use.

In programming, the same tradeoff appears. Assembly language is simple — each instruction does one thing, independently. C is more complex — control structures bundle multiple machine operations. Haskell’s map function is even more complex — it bundles iteration, element access, and function application into one abstraction. Each step up in complexity makes programming easier for common tasks, at the cost of transparency about what’s actually happening.

High Discoverability Can Be a Problem

Discoverability isn’t always good. For experts who know exactly what they want, highly discoverable interfaces are obstacles. Wizards, tooltips, confirmation dialogs, and prominent “getting started” flows optimize for first-time users at the expense of everyone else.

A small, highly discoverable interface forces everyone through the same narrow path. There’s no escape hatch to lower-level controls. Power users are stuck with the designer’s assumptions — they can’t access the unbundled operations beneath the automation.

The Expert’s Frustration

When seasoned users complain that an interface is “dumbed down,” they’re often identifying a real problem: the interface is too discoverable, too small, and too bundled. It optimized so much for certainty about novice intentions that it becomes useless for anyone else. This isn’t a failure of discoverability, it’s a failure to provide abstraction layers.

Small Can Be a Trap

A small interface isn’t inherently good. “Small” often means “bundled,” which means “complex,” which means “opaque.” If you can’t see the underlying operations, you can’t control them. You’re locked into whatever the designer anticipated.

Consider a “simple” deployment tool with one button: Deploy. What if you need to deploy to staging first? Roll back? Deploy only the database migrations? The small interface that made day one easy makes day 100 impossible.

A larger interface — separate commands for build, test, migrate, deploy, and rollback — requires more learning but provides the control that professionals need. The Unix philosophy embraces this tradeoff explicitly: many small tools (large surface area) that are simple (unbundled) and hard (require composition) but ultimately more powerful because users aren’t limited to pre-bundled workflows.

Why Keeping These Axes Separate Matters

When these five properties get conflated, reasoning about design goes off the rails. The equivocation fallacy happens whenever a term changes meaning mid-argument.⁷ Single-term confusion is easy to spot. The dangerous version is when equivocation compounds across multiple statements, as each premise sounds reasonable, but the conclusion is absurd.

An Equivocation Chain

Consider this sequence of statements, each defensible in isolation:

1. “Our interface is too complex. Users are overwhelmed.” (Here “complex” means too many visible options — a size problem)

2. “We should simplify by making each component do one thing well.” (Here “simplify” means unbundle, reduce entanglement — the structural definition)

3. “So, let’s break the dashboard into separate focused screens.” (Follows logically from statement 2)

4. “Now users have to navigate five screens to do what took one screen before.” (Consequence of statement 3)

5. “We made it more complex! Users are even more overwhelmed.” (Back to “complex,” meaning too much effort, too many steps)

The team followed valid reasoning at each step but ended up where they started or worse. The hidden error: “complex” shifted from meaning “large interface” to “entangled architecture” back to “difficult workflow.” The solution to problem #1 (reduce size) is the opposite of the solution to the structural interpretation (unbundle into more pieces).

Case Study: Snapchat’s 2018 Redesign

This isn’t hypothetical. Snapchat’s 2018 redesign is a textbook case of equivocation-driven design failure.

The reasoning chain:

1. “New users find Snapchat confusing and hard to learn.” (Discoverability problem: users can’t find features)

2. “We need to simplify the interface.” (Interpreted as: reduce complexity by separating concerns)

3. “Friends and Publishers are different. Let’s unbundle them into separate sections.” (Structural simplification: less entanglement)

4. “This will make content easier to discover.” (Assumed: smaller, focused sections = better discoverability)

The result: The redesign moved friends’ Stories away from the Stories page into the Chat section. Each section was now “simpler” (less entangled, more focused), but:

• The interface became harder (muscle memory broken, more navigation required)
• Friends’ content became less discoverable (buried in a section users associated with DMs)
• The architecture was simpler but the user experience was worse

Kylie Jenner’s tweet — “sooo does anyone else not open Snapchat anymore?” — wiped $1.3 billion from Snap’s market value in a single day. A Change.org petition gathered 1.2 million signatures demanding a rollback.

The equivocation: Snapchat conflated “simpler architecture” with “easier to use” and “more discoverable.” They achieved structural simplicity by unbundling — which is exactly what made the interface harder and less discoverable. The axes moved in opposite directions, and no one noticed because they were all called “simpler.”

The Lesson

Each statement in an equivocation chain can survive scrutiny in isolation. The error only becomes visible when you track which axis each statement actually references:

When you catch yourself using “simple,” “complex,” “clean,” or “streamlined,” stop and ask: Which axis am I actually talking about? Now check whether your proposed solution moves that specific axis in the right direction, or whether it accidentally moves a different axis instead.

Clear terminology prevents these errors. When someone says “this interface is too complex,” ask the following questions: * Do you mean the underlying operations are too entangled? (simplicity axis) * Are there too many exposed options? (size axis) * Do tasks take too much effort? (ease axis) * Can users find what they need? (discoverability axis)

These are different problems requiring different solutions.

The Power Dimension: Abstraction Layers

One additional concept cuts across all five axes: power as the ability to operate at the desired level of abstraction.

Research on multi-layer interfaces shows that the most effective systems provide multiple layers of abstraction.⁸ At the highest level, complex automation handles common tasks easily. Users with high-certainty intentions can get in and out quickly. At lower levels, simple unbundled operations are available for users who need fine control.

Abstraction Layers

Users choose their level. Power = operating at the right abstraction.

Well-designed systems provide escape hatches between layers. Consumer routers with “advanced mode” exemplify this pattern.

Most users never see the complexity — they just want WiFi to work. But when someone needs unusual configurations, the layers beneath are accessible.

The failure mode is systems that provide only one level of abstraction. Either everything is automated and bundled (powerful for common cases, useless for anything else), or everything is manual and unbundled (powerful for experts, impenetrable for everyone else).

This is why MikroTik added QuickSet — a simple wizard interface over their deeply unbundled system. And why Blender’s recent versions have improved onboarding while preserving access to the full toolset. The most useful systems let users choose their abstraction level rather than forcing everyone into the same mode.

Actionable Insight

Identify your interface’s abstraction layers. Can users drop down to a lower level when needed? Can they climb back up when they want automation again? If users get stuck at one level with no escape hatch, you’ve created a trap — comfortable or frustrating — inescapable either way.

Applying the Framework

When evaluating or designing an interface, work through each axis independently:

1. Simplicity

SIMPLE ←———————→ COMPLEX

Are operations entangled or independent? Can components be understood in isolation? Could you change one thing without worrying about side effects elsewhere?

2. Ease

EASY ←———————→ HARD

How much effort does task completion require? What background knowledge is assumed? How long until a new user accomplishes their first goal?

3. Size

SMALL ←———————→ LARGE

How many options are exposed at each level? How much scanning is required to find functionality? What’s the option count at each hierarchy level?

4. Certainty

CERTAIN ←———————→ UNCERTAIN

How well do you understand user intentions? How stable are those intentions across your user base? Can you rank user goals by frequency?

5. Discoverability

DISCOVERABLE ←———————→ HIDDEN

Can users find what they need? Is the path to functionality apparent? How many users give up before finding a feature that exists?

Examine the relationships. High certainty enables smaller interfaces, which enables better discoverability. Low certainty forces larger interfaces, which forces progressive disclosure strategies. Complex automation creates ease, but sacrifices transparency. Simple architectures preserve transparency, but require more user expertise.

These aren’t value judgments. A large, hard, and simple interface is exactly right for some contexts. A small, easy, and complex interface is exactly right for others. The goal is matching the design to actual user needs, which requires reasoning precisely about what each axis contributes.

“User-friendly” tells you nothing. These five axes tell you what to build.

This framework emerged from a discussion among infrastructure engineers about why professional networking equipment feels so different from consumer gear, and whether that difference is inherent or incidental. The answer, it turns out, involves asking much more precise questions about what we mean when we call something “simple” or “easy.”

Sources & Further Reading

Additional Reading: - Nielsen Norman Group. “Progressive Disclosure” — Deep dive on when and how to defer features to secondary screens. - UI-Patterns.com — Practical examples of progressive disclosure in the wild.

Published December 2026 • Based on collaborative discussions about interface design terminology