A Design Function, a Design System, and a Flagship Redesign

The first architectural decision was what kind of system the portfolio actually needed. The instinct of most six-product portfolios is six design systems, or one rigid system that flattens every product into the same brand. Neither was right for ID Plans. The acquired products had real brand equity with their customer bases — flattening them into a single visual identity would have created adoption friction with no business upside. But running six independent systems would have re-created the fragmentation problem I'd been brought in to solve, just at a more expensive layer.

The resolution was a single component library consuming semantic tokens, with each application setting its brand and accent colors at the codebase level. One framework. Six brand expressions. Consistent behavior across all of them. A button in ID Inspect and a button in any other product in the portfolio would behave identically, take the same props, and ship from the same library — they'd just paint themselves in different colors depending on which app instantiated them. The system was built on Tailwind in partnership with the Head of Engineering and the dedicated front-end engineer, with the token layer carrying the contract between design and code.

The scoping decision underneath the architecture was equally consequential. I used a cross-portfolio content inventory to determine what components the system actually needed to ship with — the foundations and the components required to cover the majority of user flows across the suite, not the maximalist coverage that typically stalls in-house systems before they're useful. The discipline was anti-completionist on purpose. A system that covers 80% of flows and ships is infrastructure; a system that targets 100% and never finishes is a Figma file.

With the system architecture decided, the next question was which of the six products got the first redesign. The case for ID Inspect was not aesthetic and not even mostly experiential — it was commercial. ID Inspect was the company's newest offering, and customers were waiting to onboard. The existing experience was the bottleneck. The redesign wasn't a polish pass; it was a direct unblock for new revenue.

That sequencing decision dictated everything downstream. ID Inspect went first because shipping it cleared a sales pipeline; the broader portfolio rollout could wait because the existing products were already in market and already generating revenue, even if imperfectly. The Head of Product and I made the call together, and once it was made, I built the design system in lockstep with the ID Inspect redesign rather than as a separate project — every component the system shipped with was a component ID Inspect needed, which meant the system's first proof point was a real product going to real customers rather than a demo.

The redesign rebuilt the inspection-centric workflow as the spine of the web product, replaced the legacy interaction patterns with the new system's components, and established the visual and behavioral baseline that the rest of the portfolio would migrate toward. It shipped on the system, with the system, as the system's first production implementation.

Partway through the ID Inspect work, the team was sitting on four open issues that read as unrelated. Report pages in the web interface were sluggish because an inspection typically carried a lot of property photos. A meaningful share of those photos rendered rotated the wrong way, which had surfaced a proposal to build a photo-editing tool with at least a rotate function. PDF exports of the reports were running large — five to ten times the file size of competitor exports with similar photo counts. And a customer had been asking for months to add a Share feature for reports, with link-based access and the file management, storage architecture, and link-security model that came with it. Four separate backlog items, four separate teams' worth of effort if we built them as they'd been described.

I pulled on the Share request first because it was the biggest scope and the one with the most downstream implications. Multiple conversations with the customer surfaced what the request was actually about: the PDF reports were too large for most email systems to handle, and the customer had reverse-engineered "send a link" as the solution that would let them keep their existing workflow. The Share feature wasn't a Share feature. It was a workaround for a file-size problem the customer had no way to address from their side.

Working with engineering, I traced each of the four issues back to the same underlying cause: every uploaded photo was being stored at full original resolution and then resized in the browser at render time. That single decision was producing the slow report pages, the oversized PDFs, the email-size problem driving the Share request, and — because the application wasn't reading the EXIF orientation metadata that mobile devices write at capture — the rotation issue. Four user-facing symptoms, one infrastructure cause. I'd carried a piece of pattern recognition into the conversation from a photo-sharing side project I'd built years earlier, where I'd used an image-processing library to handle exactly this kind of pipeline. I proposed the team adopt one on the server side: on upload, read the orientation metadata and correct the file, then generate a thumbnail for report overviews, a larger size for in-browser viewing, and a medium size optimized for PDF export.

What the proposal unlocked, beyond fixing the four reported symptoms, was a set of features we didn't have to build. No photo-editing tool with rotate controls. No report-sharing surface with link generation, expiration policies, and access controls. No new storage architecture for retained PDFs. No security review of public-versus-restricted link behavior. The major user-experience improvement shipped without a single change to the interface — the kind of outcome that's invisible in a portfolio screenshot and easy to undersell, but which is the actual job at the Staff level. The work that wasn't built is as much the deliverable as the work that was.

ID Inspect needed a mobile companion. The web product was the configuration and reporting surface; the field inspector needed a mobile experience to do the actual inspections. There was no existing mobile app to redesign. The 0→1 decision was real and the scope was open.

The temptation in any 0→1 mobile companion to an established web product is to port the web feature set to a smaller screen — to think of the mobile app as "the web app, but mobile." I designed against that instinct from the start. A field inspector on a phone walking through a commercial property isn't a desktop user with less screen real estate. The mobile product is the inspection workflow itself — the camera, the checklist, the spatial context of where you are in the building, the offline reality of basement parking garages and rooftop equipment — none of which the web app has to handle.

The design defined the inspection-centric workflow from a blank slate: the relationship between the inspection plan (built on web) and the inspection execution (consumed on mobile), the information architecture of a building walkthrough, the offline-first data model the work required, and the handoff back to the web for review and reporting. The two surfaces were designed as a paired experience — different products, shared system, one continuous job for the customer — rather than as one product spanning two screens.

The mobile app was delivered to the development backlog at engagement close. It didn't ship inside the engagement, but the product definition, the information architecture, and the design were positioned for the internal team to build from.

The final architectural decision was about what would still be there a year after I left. A contract designer who builds a beautiful system that no one in the org can extend has built a liability, not infrastructure. The handoff was a design problem, and I treated it as one.

I built the Figma UI kit on the same framework and token structure as the codebase — same tokens, same component model, same naming. Design and code didn't diverge because they couldn't; one was the other, expressed in a different surface. A designer or PM opening the Figma file got the same vocabulary the engineer got in their codebase, and vice versa. That symmetry is what made the handoff teachable in the time available.

Then I trained the two product owners to maintain and extend the kit after the engagement closed — sessions on how the tokens worked, how to add a component, when to extend the system versus when to ask engineering for a primitive that didn't exist yet. I also coached them on writing features, acceptance criteria, and user stories that engineering teams could act on — the framing layer the product function had been missing. None of that was in the scope of the original engagement. It was in scope because the alternative was leaving the team dependent on the contractor who built the system, which is the failure mode every in-house design system that doesn't survive its originator falls into.

The decision worth naming isn't a single artifact. It's the framing: every deliverable was designed to outlive the engagement, and the work that lived inside me as tacit knowledge was the work I made the most effort to externalize before I left.