Beam

Beam was built to reduce the manual work involved in moving enterprise applications between identity providers — work that, done by hand, ran to roughly two hours per application and months per company.

My engagement covered the experience around the migration system itself: research, information architecture, navigation, system states, future-state design, and the path from Figma into an Angular-based product.

I joined while the product was already technically sophisticated. What it did not yet have was a coherent way to orient an operator inside that sophistication.

The app dropped users directly into Discovery. There was no Home experience answering the basic questions a complex operational product needs to answer:

Automation wasn’t enough. The mental model didn’t translate.

The product made sense from the architecture inward. Operators had to make sense of it from the experience outward. That gap showed up everywhere.

Search was tied to individual containers, meaning someone effectively needed to know where an object lived before they could find it. Internal system copy surfaced directly in the UI. Authentication failures could expose raw Azure messages. Charts were given visual priority even when the more useful information was status, exceptions, and available actions.

During a May 8 working session, an Okta token expired twice while the product was being demonstrated. That moment made the problem unusually concrete.

A migration product could automate an enormous amount of technical work and still leave an operator unable to understand what had just happened or what to do about it.

My notes from the sprint include a line I still like:

“I don’t wanna just reskin it, you know?”

Because that was the temptation. This wasn’t primarily a visual redesign. It was an architecture problem.

I started by documenting rather than decorating.

The current-state inventory eventually included a 22-file walkthrough of the application, alongside research notes, competitive analysis, IA explorations, dated wireframes, future-state screens, and a decision/change log.

The goal wasn’t to create documentation for its own sake. I needed a model that let us see where Beam’s internal structure and the operator’s mental model stopped matching.

From there, I worked from current state toward a future state:

That distinction drove most of the decisions that followed.

DECISION 1Give people somewhere to land

The existing product opened directly into Discovery. I proposed a Home experience that acted as an orientation layer: current environment, migration state, exceptions, progress, and next actions.

Home wasn’t another dashboard for the sake of having a dashboard. Its job was to answer: What is happening, and what needs me?

DECISION 2Let people search the system, not its containers

The existing search model was container-specific. I proposed global search organized by entity, allowing an operator to begin with the thing they understood rather than the technical location where Beam stored it.

During the May 8 working session, the product lead endorsed that direction.

That looks like a small interaction change. It is actually a change in the product’s conceptual model.

DECISION 3Organize Beam around the migration work

The navigation and configuration model also needed a clearer hierarchy. The future-state direction made the major migration phases more legible while separating secondary system administration from the operator’s primary workflow.

Discovery, Remediation, Configuration, and Deployment became easier to understand as parts of one process rather than disconnected places in an application. Settings, options, logs, and other administrative material could sit where their purpose made sense instead of competing with the migration itself.

DECISION 4Separate system-wide problems from local ones

We also clarified how Beam should communicate failure. Global events needed a global signal. Contextual problems needed to appear where they occurred.

The resulting direction paired a bell-style notification model for broader events with inline markers and messages inside the affected workflow. The important part wasn’t the icon. It was the distinction: what does the whole system need to tell me, versus what does this specific thing need me to fix?

Once the architecture was clearer, the UI became much easier to reason about.

The sprint produced dated wireframes followed by a ten-screen high-fidelity future-state set covering areas including Discovery, Configuration, Deployment, Remediation, Home/Admin, loading states, and error handling.

The visual language became quieter because the information hierarchy became clearer. Status, counts, exceptions, and available actions took priority over decorative reporting. System copy became more human. Navigation gave people a stronger sense of place.

The screens were the visible output. The more important work was the shared model underneath them.

I can document the future-state design direction and the later continuation of the product. I cannot verify that every interaction or visual detail shipped exactly as proposed, so I don’t present the comps as a pixel-perfect record of production.

There is a lot I can prove about this project. There are also things I cannot.

Beam itself was marketed around reducing migration labor and time by up to 90%. That is a product claim. It is not my UX metric. I’m not going to turn it into one because it would look good in 48-point type.

For this case study, the evidence is the work itself: the current state, the decisions, the future-state architecture, and the artifacts created along the way.

The biggest lesson wasn’t about identity migration. It was about complex systems.

An interface is often the translation layer between the model a system needs in order to function and the model a person needs in order to understand it. When those models diverge, teams can spend a lot of energy polishing symptoms.

Next time, I would force that conversation earlier:

Once a team can answer that together, navigation gets easier to reason about. Error states get clearer. Search becomes less arbitrary. Even individual screens become easier to design because they belong to something larger.

That is the part of Beam I’ve carried forward.