What Games Taught Me About Enterprise Software
I started in art and games, long before enterprise software became most of my work.
Back then, the two felt like opposites. One was built to entertain. The other was built to get things done. It took me years of living in both to notice they were never really opposites at all.
Different worlds. Same human needs.
Design · Games · Enterprise
The problems were different. The human wasn't.
If you've ever opened a piece of software and felt a small wave of "where do I even start," you already know what this piece is about. That feeling isn't a personal failure it's a design failure. And games solved it decades before most enterprise products even tried.
Complexity was never the real problem
A good game can be enormous hundreds of rules, systems, mechanics stacked on mechanics. But no good game ever hands you all of it on day one. It gives you one thing. You try it. The world responds. Then it gives you the next thing.
Most enterprise software does the opposite. It shows you everything it knows the moment you log in, because more visible features felt like more value to whoever built it. But you don't experience "everything available" as powerful you experience it as noise.
The fix was never removing capability. It's deciding what a person needs to understand right now, and trusting the system to hold the rest until they're ready for it.
The invisible rules are where the frustration lives
Every game teaches you its rules without ever opening a manual. You learn what's possible by testing the edges of the world, and the world teaches you back.
Enterprise software has just as many rules permissions, dependencies, states, business logic but it rarely explains any of them. A button goes gray and nobody tells you why. A field locks and the reason stays buried in a system you'll never see.
That gap between what the software knows and what the person in front of it knows is where most "UX problems" actually start. Not from bad screens. From invisible logic.
You did something. Did the system notice?
Games are relentless about feedback. Every action gets a response a sound, a shift, a visible consequence so you always know the system heard you.
Open an enterprise tool and click something, and often you get a spinner, then silence. Somewhere, a record changed. You're left wondering whether it actually worked, or whether you should click it again.
That silence isn't neutral. It quietly erodes trust, one unclear moment at a time.
That silence isn't neutral. It quietly erodes trust, one unclear moment at a time.
Failure should teach you something, not punish you
You try something in a game, it doesn't work, and you learn a little and try again. Nobody designed that loop to be forgiving out of kindness they designed it because a system that punishes every mistake stops people from exploring it at all.
Enterprise software carries higher stakes; a mistake here can ripple into someone else's workflow, someone else's week. So we can't copy the forgiveness of a game directly.
But we can borrow the principle underneath it: make the consequence visible before the click, not after.
Give people a way back. Let the system explain itself when something goes sideways.
You were never navigating screens. You were navigating work.
This is the one that changed how I think most.
A requirement becomes a task. The task moves through a process reviewed, blocked, picked up again, handed off, finished. That's not a sequence of screens. That's a single continuous piece of work moving through a system, and you're moving with it.
Most enterprise products are built screen by screen, team by team, so that continuity gets lost somewhere along the way.
The real question was never "how do I get someone from Screen A to Screen B." It's "does this person always know where they are in the work, what just happened, and what's next.
That's a far bigger design problem than any single screen can solve.
A great world holds together. Most enterprise products don't.
The best games never feel like a pile of separate features bolted together. Every rule, every interaction, every visual choice reinforces the same world.
Enterprise products almost never get built that way. One team ships a workflow. Another ships reporting. Another patches in an integration to satisfy one customer's request. None of those decisions were wrong on their own but years later, the product has real power and no coherence.
That's the deeper responsibility in enterprise design. Not making one screen better. Designing the world people actually work inside of, all day, every day.
That's a far bigger design problem than any single screen can solve.
What I actually carried forward
None of this ever meant "add points and badges to work software." That was never the lesson.
The real lessons were quieter: reveal complexity instead of dumping it. Make the rules legible. Let the system respond. Show the consequence before it happens. Make the path back possible. Build one coherent world instead of a hundred disconnected features.
Working across both taught me that complexity was never the enemy. Poorly organized complexity was.
Where this is heading next
Software is starting to understand context, and take action on its own which changes what a designer's job even is. It's less about specifying every click now, and more about deciding when the system should act on its own, when it should explain itself, and when it needs to hand control back to a person.
How do you help someone make sense of a complex system and move through it with confidence?
That question followed me from games into enterprise software. I suspect it's going to follow all of us into whatever comes after this too.
"The best experiences never hide complexity.
They give you a way through it."
