You know the look. Blue header. Grey sidebar. A table with twelve columns and no hierarchy. Buttons that say "Submit" and "Cancel" in the same size and colour. A search bar that searches everything and finds nothing useful. Welcome to your enterprise portal. It was built in 2016 but it feels like 2005.
The Pattern
I've audited more enterprise portals than I can count. They all share the same DNA. Not because the technology is outdated, but because the process that produced them treats design as decoration.
Here's how it usually goes. A business analyst writes requirements. An architect designs the data model. Developers build the functionality. And then, at the end, someone asks: "Can we make it look better?"
That question, asked at that point, is the problem.
By the time design enters the picture, every decision has been made. The information architecture is locked. The navigation structure mirrors the database schema. The forms display every field the system tracks, regardless of whether the user needs all of them at once. "Making it look better" means choosing a colour scheme and maybe rounding some corners. It doesn't mean rethinking the experience.
Why It Matters More Than People Think
Your staff use this portal eight hours a day. Every extra click, every confusing label, every screen that shows too much information at once costs time. Not a lot of time per interaction. But multiplied across hundreds of users and thousands of interactions per week, it adds up to real money and real frustration.
The portal that feels like 2005 isn't just ugly. It's slow to learn, slow to use, and the reason half your team has a parallel process running in a spreadsheet.
When people build workarounds for your system, they're not being difficult. Listen to the spreadsheet.
Rainui Teihotua
Chief Creative Officer
The Fix Isn't a Redesign
Slapping a new skin on a badly structured portal doesn't fix anything. You'll have a modern-looking interface with the same twelve-column tables and the same navigation that makes no sense to anyone who isn't a database administrator.
The fix is involving design from the start. Before the data model is finalised. Before the navigation is set. Before anyone decides what goes on which screen.
What does the user need to do? What information do they need to do it? What's the most common task, and how many clicks does it take? These are design questions, and they should shape the architecture, not the other way around.
Consumer software figured this out years ago. Enterprise is still catching up. But the organisations that close that gap, that treat their internal tools with the same care they treat their customer-facing products, get something back. Adoption. Speed. Staff who don't hate Monday mornings quite as much.
Your portal doesn't have to feel like 2005. But fixing it starts earlier than most organisations think.