SSR ESP

Smith Seckman Reid has designed hospitals and other large infrastructure since 1968. For healthcare clients they handle the whole project: facility layout, equipment needs, procurement, and installation. All of that runs through Equipment Solutions Planning, a tool SSR built in-house in 2006.

By the Pixel rebuilt it as ESP 2.0. I was the lead designer, working with a PM and a lead engineer, and I ran discovery, the UX and UI, and QA. This case study covers the design side: a new interface, new workflows, and a system that can keep up with the projects running through it. We designed it in 2023, before SSR's rebrand, which is why it doesn't share the design system PMKP and Codex use.

Discovery was several rounds of interviews with a core team of about six people. Each had used ESP for years, and each had a different idea of what it should become. My job was to turn those ideas into one direction, and most of the design below is that reconciliation. The technical verdict was simple: the 2006 codebase couldn't be saved, and only a full rewrite would give SSR a secure, maintainable base. Discovery also produced personas, a competitor analysis, a product roadmap, and a data migration plan.

We set four goals. Rebuild the app on a codebase that would last. Redesign the UI and UX, because interface design had moved a long way since 2006 and every screen was costing people time. Move the data without disruption, including more than 100 in-flight projects that couldn't pause for the move. And add the features users had been asking for all along.

ESP is a data-heavy tool, so I kept the interface minimal. I stripped out anything that competed with the data and spent the design effort on keeping people oriented. The new navigation makes it clear where you are and quick to get where you're going. That had been one of the old app's worst problems, and the one complaint all six interviewees agreed on.

The tables got the most attention because that's where planners spend their day. People can set them up the way they work, edit data in place, and keep their bearings even in large datasets.

Seventeen years of workarounds had pushed the real work out of the tool. Budgets lived in side spreadsheets, clients couldn't see their own projects, and procurement had no guardrails.

The rebuild brought that work back in. A new dashboard gives each project an overview and analytics, and because permissions are built in, SSR can give clients access to their own project's dashboard to check reports and follow progress as it happens. Budgets update as expenses come in, so the team can spot problems early. Procurement now has guardrails that catch mistakes and show each project's progress as you work, and the item comparison tool was rebuilt so planners can add and remove items freely and come back to a comparison later.

A rewrite this big can fail two ways: the new stack ages as badly as the old one, or the data doesn't survive the move. For the first, the team chose a headless architecture with a Vue.js front end and a Laravel back end, both open source with active communities, which matters for a tool SSR will run for another decade. The data schema was also cleaned up to improve performance, cut complexity, and make the system easier to change.

The migration was the risky part: hundreds of projects and more than 100 million data points moved into the new system, with the in-flight projects landing without disruption. My part was QA. I tested every rebuilt workflow against the migrated data before the planners got it, because the person who finds a bad row first shouldn't be someone in the middle of a hospital project.