How to Redesign Legacy Enterprise Software Without Breaking What Works - A Case Study

Most redesign stories start with a product that's failing. Users are leaving. Metrics are dropping. Something is clearly broken and needs fixing.

PassagePoint wasn't that story.

PassagePoint was a visitor management platform built by Stopware — a company with years of operational history, an active customer base, and organizations that depended on the product daily for physical security, access control, and facility compliance.

The product worked. Customers relied on it. It had been running successfully for a very long time.

And that's exactly what made this project terrifying.

Because when a product is failing, you have permission to change everything. Users are already frustrated. Stakeholders are already convinced something needs to be different. There's urgency and alignment.

When a product is succeeding — when real organizations use it to manage who enters their buildings, when security teams depend on it, when compliance workflows are built around its exact behavior — you can't just waltz in and redesign things.

Every feature exists for a reason. Every screen has users relying on it. Every configuration rule was added because someone, somewhere, needed it.

The challenge wasn't "make this better."

The challenge was "make this understandable — without breaking what made it successful."

"The product wasn't broken. It was buried. Twenty years of features, workflows, and configuration logic had accumulated into something that worked perfectly — and was nearly impossible for new users to learn."

What we walked into

Let's be honest about the first impression.

The existing platform looked like software from the dinosaur era. Desktop-native UI patterns. Dense, utilitarian screens. Tiny text, cramped layouts, and interface conventions that made perfect sense in 2005 and absolutely none in the modern web.

But here's the thing we learned quickly: the interface wasn't the problem.

The problem was that the product had been growing for over two decades. Feature after feature. Configuration option after configuration option. Exception after exception. Each addition was reasonable in isolation — a customer needed something, the team built it, the product absorbed it.

Over twenty years, those reasonable additions compounded into something that no single person could hold in their head.

The platform didn't have a complexity problem because someone made bad decisions. It had a complexity problem because it had been making good decisions for a very long time — and never stopped to reorganize.

The moment we realized the scope

For the first several stakeholder sessions, we barely understood what the product was doing.

This isn't something design teams usually admit. We're supposed to walk into a project, assess the situation, identify problems, and start solving them.

With PassagePoint, we couldn't even identify the problems — because we couldn't yet understand the system.

Not because the stakeholders explained things poorly. They were knowledgeable, articulate, and deeply invested in the product. The problem was that the product had evolved through so many iterations, with so many interconnected systems, that understanding it required studying it. Not skimming. Not auditing. Studying.

We spent weeks:

• Walking through legacy screens, one by one

• Mapping existing user flows

• Documenting configuration dependencies

• Cataloging feature inventories

• Tracing how settings in one module affected behavior in another

• Building system relationship diagrams

Before we designed a single screen, we had to become students of a product that had been built by people who understood it intuitively — because they'd been building it for years.

We didn't have years. We had to learn it from the outside.

"The project became less about redesigning screens and more about understanding an ecosystem. We couldn't fix what we couldn't explain."

The two centers of gravity

PassagePoint contained multiple modules — Reporting Center, Directory Center, Security Center, and others. But the redesign focused on two:

Visit Center

The operational heart. The daily-use tool.

This is where front-desk staff, security personnel, and facility managers actually did things:

• Register visitors

• Manage check-ins and check-outs

• Process pre-registrations

• Track who was in the building in real time

Visit Center was the product most users saw. It needed to be fast, clear, and operationally reliable.

Configuration Center

The engine room. The power tool. The beast.

This is where administrators controlled everything:

• What registration workflows looked like

• What fields visitors filled out

• What data got collected

• How layouts were structured

• What capture devices were used

• What validation rules applied

• What permissions governed who could do what

Configuration Center didn't just manage settings. It was a platform for building the experience that Visit Center delivered.

Administrators were, in effect, designing registration experiences — without knowing they were doing design.

The relationship between these two modules was the core tension of the entire project.

Configuration Center built the experience. Visit Center delivered it.

But in the existing platform, these two worlds were visually disconnected. An administrator configuring a screen policy couldn't easily see how their changes would affect what front-desk staff experienced. And front-desk staff encountering a confusing workflow couldn't trace it back to the configuration that created it.

The system was deeply connected underneath and completely fragmented on top.

The Configuration Center: a case study within the case study

If the Visit Center redesign was a renovation, the Configuration Center redesign was an archaeological expedition.

This was the most complex area of the project — and it became the most interesting story.

What administrators could do

The Configuration Center allowed administrators to:

• Create policies

• Define sections within those policies

• Configure layouts for those sections

• Add fields — both predefined and custom — to those layouts

• Set behaviors for those fields — validations, requirements, visibility rules

• Define capture methods — ID scanning, passport scanning, photos, signatures, biometrics

• Manage settings at every level of the hierarchy

That's a lot of power. And in the original platform, most of it was exposed simultaneously.

What that looked like in practice

Imagine opening a single screen and seeing:

• The policy name and settings

• A list of sections, each expandable

• Inside each section, a list of fields

• Each field with its own settings panel

• Capture method configurations

• Validation rules

• Layout controls

• Behavior toggles

• Permission overrides

All on one screen. All visible at once. All editable simultaneously.

For administrators who had used the system for years and understood the hierarchy intuitively, this was efficient — they knew where everything was and could make changes quickly.

For anyone else — a new hire, a transferred admin, someone covering for a colleague — this was a wall of complexity that required training just to navigate.

The system exposed its own internal architecture directly to the user.

"Users weren't struggling because the system lacked features. They were struggling because the system showed them everything it could do — all at once."

The insight that shaped everything

After weeks of research, one principle emerged that guided every design decision for the rest of the project:

"Complexity should be handled by the software, not the user."

The product was genuinely complex. That complexity was real — it existed because the system needed to support wildly different organizations with wildly different visitor management requirements.

A corporate office in Manhattan has different visitor workflows than a government facility in Virginia. A hospital has different compliance requirements than a tech company. A multi-building campus has different configuration needs than a single-floor office.

That flexibility was the product's greatest strength. And it was the source of its greatest usability problems.

The redesign couldn't remove the complexity. It had to absorb it — letting the software organize, structure, and guide users through configuration instead of dumping the raw system hierarchy on their screens.

The Screen Policy breakthrough

Screen Policies were the heart of the Configuration Center — and the heart of the redesign.

A Screen Policy defined what a visitor registration experience looked like: what fields appeared, what information was collected, how the form was structured, what capture devices were used.

In the original system, all aspects of a Screen Policy were managed in a single, dense interface. Structure, layout, behavior, and settings were interleaved. Changing a field's position, its validation rule, and its visibility condition all happened in the same context.

This was efficient for experts. And paralyzing for everyone else.

The separation: Structure, Layout, Behavior

The single biggest design decision in the project — and the one that unlocked everything else — was splitting Screen Policy configuration into three distinct conceptual layers:

Structure — What appears. Which sections exist. Which fields are included. What capture components are active. This is the content layer.

Layout — How it appears. Field ordering. Section arrangement. Visual grouping. Column behavior. This is the presentation layer.

Behavior — How it functions. Validation rules. Required vs. optional fields. Conditional visibility. Dependency logic. This is the logic layer.

Each layer got its own dedicated tab within the Screen Policy builder.

Why this mattered

This separation did something deceptively powerful: it changed how administrators thought about configuration.

Instead of approaching a Screen Policy as one giant, interconnected settings screen — where every decision felt entangled with every other decision — administrators could now think in stages:

1. First, decide what appears. Add sections. Add fields. Include capture components. Don't worry about ordering or rules yet.

2. Then, decide how it looks. Arrange sections. Order fields. Group related items. Don't worry about validation yet.

3. Finally, decide how it behaves. Set requirements. Add validation. Define conditional logic. Build on the structure and layout that's already established.

Each step was manageable. Each tab was focused. The total complexity was identical — but the cognitive complexity was dramatically reduced.

This wasn't a visual change. It was an information architecture change. And it was the single most impactful decision in the entire project.

"We didn't remove complexity. We gave it rooms. Instead of everything living in one overwhelming space, each concern got its own address."

The tabs nobody notices

Here's what's interesting about tabbed interfaces: when they work well, nobody talks about them. They're the most mundane UI pattern in existence. Tabs. Big deal.

But tabs aren't just a pattern. They're an argument about information hierarchy. Every tab says: "These things belong together, and they're separate from those other things."

Choosing which tabs to create — what goes together, what gets separated, where the boundaries fall — is one of the hardest information architecture decisions in enterprise design. Get it wrong and users can't find things. Get it right and they don't even notice the organization — it just feels natural.

We debated the tab structure for the Screen Policy builder extensively. Early explorations included:

• Four tabs: separating settings into its own tab. Too granular — users kept switching between tabs for related actions.

• Two tabs: combining structure and layout. Too cramped — the "what" and "how" of content felt distinct enough to warrant separation.

• Three tabs with a different split: organizing by field type rather than concern. Failed — it created the same "everything everywhere" problem at a smaller scale.

Three tabs. Structure, Layout, Behavior. That was the version that clicked.

The Dynamic Form Builder

Inside the Screen Policy builder, administrators needed to construct forms — the actual registration experiences that visitors would interact with.

The original system handled this through configuration screens that felt more like database management than form design.

We built a dynamic form builder that let administrators construct visitor registration forms using familiar components:

• Short text fields

• Paragraph text

• Radio buttons

• Dropdowns

• Upload fields

• Date pickers

• Search fields

• Capture components (cameras, scanners, biometric devices)

The key design decision: the form builder showed a representation of what visitors would see.

Instead of configuring fields in an abstract list and imagining how they'd appear, administrators could see their registration form taking shape as they built it. Adding a field showed it in context. Rearranging sections updated the preview. The gap between configuration and outcome — the disconnect we'd identified in research — was closed.

Configuration stopped being abstract. It became visual.

"In the old system, configuring a registration form felt like programming. In the new system, it felt like building."

Visitor capture configuration

PassagePoint supported an impressive range of visitor verification methods:

• ID scanning

• Passport scanning

• Business card capture

• Photo capture

• Digital signatures

• Biometric verification

Each of these had its own configuration requirements — device settings, data mapping, validation rules, storage policies.

In the original system, configuring capture methods required navigating to separate areas of the platform, understanding device-specific settings, and manually connecting capture configurations to the correct Screen Policies.

We brought capture configuration into the Screen Policy builder itself. Capture components became drag-and-drop elements — just like text fields and dropdowns — that administrators could add to their registration forms and configure in context.

The complexity of device integration still existed underneath. But the administrator's experience of choosing and configuring capture methods became as simple as adding any other form element.

Redesigning the Visit Center

While the Configuration Center was the most complex redesign, the Visit Center was the most consequential — because it was the product that front-line staff used every day.

Visit creation that flows

The original visitor registration workflow required staff to navigate multiple screens, enter information in a non-obvious sequence, and manage several types of data — visitor details, host information, document capture, categorization — across disconnected interfaces.

We redesigned the visit creation flow as a guided sequence:

1. Visitor information — who's visiting

2. Host information — who they're here to see

3. Document capture — ID verification, photos, signatures

4. Categorization — visitor type, purpose, access level

5. Confirmation — review and complete

Each step was a focused screen. Progress was visible. Back-navigation preserved entered data. The sequence matched the natural conversation a front-desk employee would have with a visitor: "Who are you? Who are you here to see? Can I see your ID? Let me get you set up."

The workflow matched the social interaction, not the database structure.

Multi-visitor workflows

One complexity we hadn't anticipated: groups.

Visitors often arrive in groups — a team of contractors, a delegation for a meeting, a tour group. The original system handled this by requiring staff to register each person individually. For a group of twelve, that meant twelve separate registration processes.

We designed multi-visitor workflows that allowed:

• Adding multiple visitors to a single visit

• Sharing common information (host, purpose, access level) across the group

• Individual capture (ID, photo) per person

• Batch check-in and check-out

This sounds like a minor feature. For front-desk staff processing a group of visitors during a morning rush, it was transformative.

Real-time tracking

The Visit Center's tracking view was redesigned to give staff immediate visibility into facility status:

• Who's currently in the building

• Who's expected today (pre-registrations)

• Who's overstayed their scheduled visit

• Who needs to be checked out

The tracking view was designed for ambient awareness — a screen that could sit open on a front desk, providing real-time facility intelligence at a glance.

Filters that think for you

This is a small feature that solved a surprisingly large problem.

The original platform allowed search and filtering, but it required users to understand the underlying data model. Filtering by visitor type meant knowing the exact category names. Filtering by date range meant understanding the system's date format conventions. Complex queries required manual construction.

We introduced structured filtering — a system where users could build queries through intuitive interactions:

• Select a filter category (visitor type, date, host, status)

• Choose an operator (is, is not, contains, before, after)

• Provide a value (from a dropdown, date picker, or search)

• Combine multiple filters with visible logic

The filter system translated user intent into backend queries without exposing database logic. Users could ask complex questions — "Show me all contractor visits to Building C in the last 30 days that haven't checked out" — by stacking simple, readable filter components.

"The old filters assumed users understood the database. The new filters assumed users understood their question. Big difference."

User and role management

The redesigned user management system modernized how administrators controlled access:

• User profiles with clear status indicators

• Role-based access controls with visible permission sets

• Granular permissions configurable per module and action

• Bulk operations for managing large teams

The design challenge here was making permission systems — inherently abstract and hierarchical — feel understandable. Permissions are one of those enterprise features where the underlying model is complex (who can do what, where, under which conditions) but the administrator's question is simple ("Can this person check in visitors at the front desk?").

We designed permission configuration around questions rather than matrices. Instead of a giant grid of checkboxes, permissions were organized by scenario: "What can this role do in Visit Center?" "What can this role configure?"

The design system

PassagePoint's design system was built for a specific purpose: making enterprise complexity feel manageable.

This wasn't a startup design system optimized for speed and delight. It was an enterprise design system optimized for clarity, density, and consistency at scale.

What it needed to handle

• Dense data tables with sortable columns, bulk actions, and inline status

• Complex forms with conditional fields, validation states, and nested sections

• Configuration interfaces with multiple hierarchy levels

• Dashboard components with real-time data

• Multi-step workflows with progress tracking and back-navigation

• Notification patterns for security-critical events

• Empty states that guided users instead of abandoning them

What we prioritized

Consistency obsessively. In a product this large, inconsistency multiplies. A button that behaves differently in Configuration Center than in Visit Center erodes confidence. A table that sorts differently in two modules creates confusion. Every component behaved identically everywhere.

Density without overwhelm. Enterprise users work with lots of data. The design system supported dense layouts — compact tables, information-rich cards, multi-panel views — while maintaining clear hierarchy and breathing room.

States for everything. Fields could be empty, filled, invalid, disabled, loading, or read-only. Rows could be selected, highlighted, flagged, or inactive. Visitors could be pre-registered, checked in, checked out, or overstayed. Every state needed a distinct, consistent visual treatment.

Accessible defaults. Contrast ratios, focus states, keyboard navigation, screen reader compatibility — built into the foundation, not retrofitted later.

Building what we designed

This wasn't a design-and-handoff project.

Our team contributed directly to the frontend development — implementing the designs in production, working within the engineering team's stack, and ensuring that the gap between mockup and reality stayed as small as possible.

This changed the design process in ways we didn't expect:

We designed more practically. Knowing we'd build it ourselves made us more disciplined about interaction complexity. Every animation, every transition, every conditional layout had to be implementable — not just presentable.

We caught problems earlier. Edge cases that would have been discovered during QA — long text overflow, unexpected field combinations, performance with large datasets — were caught during development by the same people who designed the interactions.

We iterated faster. When a design decision didn't work in practice — a layout that felt right in Figma but cramped in a browser, a flow that was logical in a prototype but confusing with real data — we could adjust immediately. No handoff gap. No "can you update the mockup?" delay.

The tighter loop between design and development didn't just improve fidelity. It improved the product.

"Designing and building the same product forced us to be honest about what actually works — not just what looks good in a presentation."

What made this project genuinely hard

You can't interview the ghosts of decisions past.

Every feature in a twenty-year-old product exists for a reason. But the people who made those decisions aren't always still around. Documentation is sparse or outdated. The only way to understand why something works the way it does is to study the system itself and work backwards from behavior to intent. This is slow, painstaking, and sometimes you guess wrong.

Success makes change politically difficult.

When a product is failing, everyone agrees something needs to change. When a product is succeeding, every change is a risk. "Why are we moving this? Our customers know where it is." "Why are we changing this workflow? It works fine." These weren't objections from resistant stakeholders — they were legitimate concerns from people who understood that real organizations depended on this product daily.

We had to earn trust through demonstration, not argument. Early redesigns of smaller, lower-risk areas — proving that the new approach was more usable without sacrificing capability — built the confidence needed for larger changes.

Flexibility and usability are genuinely in tension.

PassagePoint's flexibility was its competitive advantage. Organizations could configure the platform to match almost any visitor management workflow. That flexibility required configuration options — lots of them. And every configuration option is a potential confusion point.

We couldn't just remove options. We had to reorganize them — making the common path simple while keeping the advanced path accessible. Progressive disclosure became our primary tool: show what most administrators need most of the time, and let them reach deeper capabilities when they need them.

This sounds easy in principle. In practice, deciding what's "common" versus "advanced" for a product used by organizations as different as hospitals, corporate offices, government facilities, and industrial sites was an ongoing negotiation.

The configuration-execution disconnect was architecturally embedded.

The fact that Configuration Center and Visit Center felt disconnected wasn't just a UI problem. It reflected how the system was built — as separate modules with separate interfaces. Fixing the experience of disconnection required design changes that spanned both modules, which sometimes meant frontend changes that touched different parts of the codebase.

The design principles, in practice

The principles that guided PassagePoint weren't theoretical. They were practical tools for making daily decisions.

Progressive disclosure. "Show only what users need now." This meant default views showed common options. Advanced configuration was one click deeper — not hidden, but not competing for attention.

In the Screen Policy builder, basic field configuration (name, type, required/optional) was visible by default. Advanced settings (validation rules, conditional logic, capture integration) were accessible through a clearly labeled expansion.

Hierarchy first. "Structure information before styling it." Before making anything look good, we made sure the information architecture was sound. The tab structure, the section grouping, the navigation hierarchy — these were settled before any visual design began.

Many design projects start with visual direction. PassagePoint started with spreadsheets, hierarchy diagrams, and card sorting exercises.

Configuration without fear. "Make advanced configuration approachable." Administrators should never feel like they're one wrong click away from breaking the visitor experience. The redesigned system included clear labels, descriptive helper text, and preview capabilities that showed the impact of changes before they were saved.

Consistency over cleverness. "Reduce variation wherever possible." One table pattern. One form layout. One modal behavior. One filter system. Applied everywhere, without exception. In a product this size, consistency is the most valuable design asset.

Enterprise doesn't mean complicated. "Powerful software can still be understandable." This was the north star. The product's power wasn't reduced. Its presentation was transformed.

Reflection

PassagePoint taught us something that every enterprise designer eventually learns — but that no one can teach you in advance:

The hardest design problems aren't visual. They're structural.

Making something look modern is straightforward. Making twenty years of accumulated logic feel modern — without losing the logic — is a fundamentally different challenge.

A few things this project left us with:

Respect the legacy.

It's easy to look at old software and see only what's wrong. What's harder — and more important — is seeing why it works. Every decision that survived twenty years did so because it served someone. Understanding that history before changing it isn't just good process. It's respect for the people who built something that lasted.

Information architecture is the most powerful design tool.

Not color. Not typography. Not animation. The decision of what goes where — what's grouped together, what's separated, what's visible by default, what's revealed on demand — shapes the user's understanding more than any visual treatment.

The tab structure in the Screen Policy builder is, visually, the most boring element in the entire redesign. It's also the most impactful.

Successful products are the hardest to redesign.

Failing products give you freedom. Successful products give you constraints. Every change risks disrupting someone's workflow, confusing a trained user, or breaking a process that an organization depends on. Designing within those constraints — improving without disrupting — is a discipline that requires patience, evidence, and humility.

Complexity is not the enemy. Exposed complexity is.

PassagePoint is a genuinely complex product. It needs to be. The organizations it serves have complex requirements. The mistake isn't having complexity — it's showing all of it at once, to every user, on every screen. The redesign didn't simplify the product. It simplified the experience of the product. The complexity is still there. It's just organized now.

What PassagePoint became

PassagePoint went from a powerful-but-impenetrable legacy system to a modern enterprise platform that preserved every capability its customers relied on — while making those capabilities accessible to people who hadn't spent years learning the system.

The same flexibility. The same power. The same configurability.

With an experience that no longer required a training manual to navigate.

Not a new product.

A better version of the one that already worked.