Inheriting someone else's product

How it started

The brief said reskin. The product had other ideas.

The starting point was a portal from NokNok Labs, a company OneSpan had just acquired. The brief was clear: replace the UI components and align them with OneSpan's design system. No redesign, no new scope, just a visual cleanup.

The product came with 19 screenshots from the kickoff walkthrough and nothing else. No documentation. Flows had to be reconstructed from the screens alone. It became clear quickly that the scope wasn't what the brief described. The labels were wrong, the patterns were inconsistent, the button conventions didn't match the system, and several dialogs had no equivalent in the OneSpan design language. "Reskin" was where it started, not where it stayed.

Before touching Figma, I rebuilt the flow map. Nineteen screens became a full user journey: sign-in, admin users table, app actions, user actions, permissions, approve users. That document became the shared reference for every conversation with engineering from that point on.

The problem

Nobody owned the decisions yet

The stakeholder list was wider than the brief suggested. The engineering lead owned the technical direction. QA flagged usability issues throughout. The PM held the product brief. On top of that, there was a broader inherited engineering team from the acquired company whose conventions were already in the codebase.

The most common problem was that a decision that looked settled would surface again later because a different stakeholder hadn't been in the room. The "App Domain" field got renamed to "Allowed email domains" after QA flagged it. The "Delete user" label got changed to "Remove from app" and then changed back when the engineering lead clarified what the action actually did — which was full account deletion when the last app was removed, not just an app-level change. The button order on destructive dialogs took three iterations before it landed consistently.

None of these were design problems. They were alignment problems that showed up as design problems. The work was mostly about making sure the right people had seen the right decisions before anything went into the codebase.

The design work

Pattern by pattern, dialog by dialog

The system that emerged from Q2 wasn't dramatic. The sign-in screens got proper copy: "Sign in" not "Login", "Sign in with Registration Code" as a clearly labelled secondary option, "Send recovery link" instead of a generic submit. The navigation got two sidebar items with icons that made sense: a list icon for "App Access" (renamed from "User List" because every row was a user-app access record, not a user), a user-check for "Approve User".

The dialogs were the main work. Add App, Edit App, Remove App. Create User, Edit User. Assign to App, Show Registration Code, Delete User. Each one went through the same process: draft from what the existing screen implied, check against the design system, check against the actual behaviour, align with whoever had authority over that decision. The Permissions panel was rebuilt entirely, replacing six category dropdowns with a flat checkbox list that could handle dynamic DB values, with Super Admin separated at the top by a divider and a distinct visual state when checked.

The labelled divider pattern introduced in the Permissions panel became a new system component. That's the kind of decision that looks local until it isn't. I flagged it before it was picked up elsewhere.

Q3 and beyond

The scope got wider

Q3 introduced a Customer entity. Apps and domains would no longer be assigned directly, they would be assigned to a Customer, and the Customer would own them. That changed the data model, the navigation, and the actions available in every dialog. A new top-level "Customer Actions" dropdown appeared alongside App Actions and User Actions, with Add, Edit, and Remove Customer dialogs designed from scratch.

The Q2 pattern decisions held. Add Customer disabled Submit until the required field had a value, same as Create User. Edit Customer used Save not Submit, consistent with every other edit dialog. Remove Customer led with the consequence rather than asking "are you sure." Q3 felt like extending what already existed, not starting over.

The project is still in progress. Q3 is not finished. The scope will probably expand again next quarter.

Outcome

Reflection