Learning Curve & Tesler's Law: The UX Principles Behind Better Internal Tools

Internal tools rarely get the same attention as the products a company sells. There's always something more urgent: a new feature for paying customers, a conversion problem on the marketing site, a redesign that's been postponed for two years. The internal platform quietly accumulates technical debt, workarounds become habits, and at some point nobody remembers why the process works the way it does.

The problem is that the people using these tools aren't occasional visitors. They're there every day, running the same workflows, hitting the same friction points, building the same inefficient muscle memory. A confusing step in a checkout flow costs a business some conversions. A confusing step in an internal workflow costs the team time, every single day, multiplied by every person who needs to complete it.

That's the context I keep coming back to when working on internal platforms. And it's the context where two specific UX principles become genuinely useful, not as talking points in a presentation, but as tools for thinking through real design decisions.

The Learning Curve isn't just about time

Most designers are familiar with the concept: users get faster at tasks as they repeat them, until performance plateaus. The Nielsen Norman Group documented this in their research on interface learning, showing how task completion time drops sharply in the first few exposures and then gradually levels off.

What's easy to miss is that the shape of that curve is a design outcome, not just a measurement. A well-designed interface should produce steep early improvement. Users should feel noticeably more capable after their first few sessions, not after weeks of grinding through the system.

This matters even more when a team is transitioning from an old platform to a new one. Those users aren't starting from scratch. They're carrying years of habit from the previous system, and the new interface is asking them to unlearn and relearn at the same time. That's a significant cognitive cost, and it shows up in adoption metrics, support tickets, and in the quiet resentment that builds when a tool feels harder than the one it replaced.

The way to shorten that curve isn't to oversimplify. It's to build on what users already know. If the old platform established visual conventions that users internalized, the redesign should carry those patterns forward where they still make sense. Familiar affordances reduce the mental effort required to navigate something new. The user's attention stays on the work, not on figuring out the interface.

Tesler's Law is a reminder that complexity doesn't just disappear

Larry Tesler's Law of Conservation of Complexity states that every application has a certain amount of complexity that cannot be removed. It can only be moved. The designer decides whether the user absorbs it or the system does.

This is one of those principles that sounds obvious until you're in a project where someone is asking you to "make it simpler" and you realize that what they're actually asking is for the complexity to relocate somewhere else, ideally invisible, ideally handled automatically, ideally someone else's problem.

The honest version of that conversation is harder. Some processes are complex because they're supposed to be. There are regulatory requirements, operational dependencies, edge cases that actually matter. Stripping those out to hit a simplicity goal doesn't simplify the work. It just pushes the complexity back onto the user in a different form, usually at the worst possible moment.

The more useful question isn't "how do we make this simpler" but "what kind of complexity is this?" Accidental complexity, the kind created by poor information architecture, inconsistent patterns, unnecessary steps, should absolutely be eliminated. Essential complexity, the kind that reflects the actual nature of the task, needs to be handled thoughtfully, not hidden.

On internal platforms, this distinction is critical. These tools often exist precisely because the underlying work is complex. Oversimplifying the interface can quietly break critical processes, or worse, create a system that looks clean but forces users to carry more in their heads to compensate for what the UI refuses to show them.

Where these two principles intersect

Working on internal platform redesigns, I've found these two ideas end up informing each other in a specific way. The Learning Curve is about time, meaning how quickly users reach competence. Tesler's Law is about load, meaning how much complexity users are asked to manage at any given moment. Together, they define the experience of actually using something over time, not just in the first interaction.

A redesign that reduces accidental complexity shortens the learning curve because users spend less effort navigating confusion and more time doing the actual work. A design that respects essential complexity prevents the kind of breakage that happens when a simplified interface gets deployed and then immediately develops a shadow system of workarounds next to it.

In practice, this has translated into a few recurring decisions: identifying what's genuinely hard about a process before touching the interface, distinguishing between the new hire who needs guardrails and the experienced user who needs efficiency, and designing for both without treating them as opposites. Measuring improvement not just in task completion but in how fast new team members reach the performance level of experienced ones.

That last metric is underused. Onboarding speed is one of the clearest signals of interface quality in internal tools and one of the most directly connected to business outcomes.

Why internal tools deserve more serious design attention

There's a tendency to treat internal tool design as a lower-stakes version of product design. The users are employees, not customers. They can't churn. They'll figure it out eventually.

But "they'll figure it out eventually" is a design failure that never gets counted. It shows up as slower onboarding, higher error rates, more support overhead, and teams that have quietly learned to work around the system instead of through it. None of that appears in a dashboard. All of it has a cost.

The Learning Curve and Tesler's Law aren't the only frameworks worth applying here, but they're two of the most grounding ones. They push past the surface-level conversation about what looks clean or feels modern and into the harder question of what it actually costs someone to use this thing over time.

That's the question internal tools deserve to have asked about them. Not just once at the start of a redesign, but as an ongoing standard for what good design in this context actually means.