ISI Defense: Leading v5.0 through complex permissioning

ISI Defense builds a cloud-based SaaS security and compliance platform for defense contractors, storing sensitive security information and surfacing it through dashboards and reporting. I came on as the sole UI/UX designer on the team, working directly alongside developers and product managers to design v5.0 of the platform, an API-driven, React-based application where every screen had to map cleanly onto real data and real clearance rules, not just onto a Figma frame.

A note on this case study: because ISI Defense's platform handles classified and sensitive security information for defense contractors, I can't publish live screens. The diagrams below are redrawn from the working wireframes and flows I used with the engineering team, standing in for the real UI.

Visits was where I spent most of my time, but the patterns I built there needed to generalize across every one of those clusters.

Those steps had to hold up on real screens, not just in a diagram, which meant the interface itself had to carry the same logic: what a user could see and do had to track their clearance and the record's state at every point in that flow.

The clearance rules got more interesting wherever a record could change shape mid-workflow. Foreign Visitor was the clearest example, shown in the diagram at the top of this page: setting it to Yes appended four fields the form didn't ask for otherwise, the same record, two different shapes, and the platform needed to validate against whichever shape was active.

Because the application was so API-driven, design couldn't get too far ahead of the data. I worked through workflow logic in low-fidelity wireframes directly with the engineering team before moving into high-fidelity Figma designs, once we'd agreed on what states actually existed on the backend. Being the only designer on a team of developers also meant I was the one setting the design vocabulary: the patterns for how dashboards, reporting views, and permissioning states got built consistently as the platform grew, since no one else on the team was going to do that if I didn't.

What I learned

As the only designer on a team of engineers, the deliverable was never really the wireframes, it was a shared vocabulary the team could keep building on when I wasn't in the room. That reframed how I thought about my own output: a screen was only finished once a developer could look at it and know exactly what state produced it, without asking me.

I also came away thinking differently about edge cases. It would have been easy to treat the Foreign Visitor branch or the Assigned Personnel timing gap as exceptions to design around later. But in a compliance product, the exception is often the whole point, the case where getting it wrong actually matters. Designing the happy path first and patching the edge cases in afterward isn't an option when the edge case is a security requirement. I now start every complex workflow by asking what breaks the assumed sequence, not what the ideal sequence looks like.

This is the kind of engagement that defines UXcalibur's approach: owning the relationship end to end, from scoping through delivery, so the client has one person who understands both the interface and the compliance context it has to hold up under.