SSR ESP

Smith Seckman Reid designs hospitals and other large-scale infrastructure, and has since 1968. For healthcare clients they carry the whole project lifecycle: facility layout, defining equipment needs, procurement, and installation. The tool that manages all of that is Equipment Solutions Planning, a proprietary application SSR built in 2006.

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

Discovery was rounds of interviews with a core team of about six people, each of whom had used ESP for years and had their own view of what it should become. My job was to reconcile those views into one coherent direction, and that reconciliation is most of what the design below is. The technical verdict was blunt: the 2006 codebase wasn't usable, and a full rewrite was the only way to get a secure, maintainable foundation. Discovery also produced personas, a competitor analysis, a product roadmap, and a data migration strategy.

That set four goals. Modernize the app on a codebase built for the future. Revamp the UI and UX, because interface design had moved a long way since 2006 and efficiency was leaking out of every screen. Migrate the data without disruption, including more than 100 in-flight projects that couldn't stop while the ground moved under them. And add the functionality users had been asking for all along.

ESP is a data-heavy tool, so I designed it deliberately minimal: strip everything that competes with the data, and spend the interface budget on keeping people oriented. The redesigned navigation makes it easy to understand where you are at all times and to get where you're going quickly, which had been one of the old app's sorest points and the one complaint all six interviewees agreed on.

The tables got the most attention, because that's where planners live. They're fully featured: customizable to how each person works, editable in place so data manipulation happens right in the table, and built to hold context even when the datasets get large.

Seventeen years of workarounds had pushed the real work outside the tool. Budgets lived in spreadsheets on the side, clients had no window into their own projects, and procurement ran without guardrails.

The rebuild pulled that work back in. A new project dashboard gives every project an overview and analytics, and because permissions are built in, SSR can hand clients access to their own project's dashboard to check reports and monitor progress in real time. Live budgets track expenses as they happen, so the team watches progress and flags issues early. The procurement system gained guardrails that improve accuracy and give users real-time feedback on each project's progress, and the item comparison tool was rebuilt so planners can add and remove items freely and come back to a comparison whenever they need it.

A rewrite this size fails in one of two ways: the new stack ages as badly as the old one, or the data doesn't survive the move. Against the first, the new stack is 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 refined along the way to improve performance, reduce complexity, and leave the system more adaptable than the one it replaced.

The migration was the high-wire act: hundreds of projects and more than 100 million individual data points moved into the new system, with the in-flight projects landing without disruption. My part in that stretch was QA. I worked every rebuilt workflow against the migrated data before the planners did, because the person who finds a bad row first should not be someone in the middle of a hospital project.