Zipify OCU

Several visible usability issues needed attention. I first wanted to understand why the team kept producing them and where design could have more influence.

I ran a DesignOps workshop with the design team, followed by working sessions with product, engineering, support, and other stakeholders. Together, we mapped how decisions were made, where handoffs failed, what other teams expected from design, and which gaps were slowing the work down.

The previous workflow placed designers near the middle of delivery. A task was assigned during planning, the designer created a concept, technical limitations were discussed, and the work moved into development. User validation and post-release evaluation were not established parts of the process.

I led the work to reshape this workflow. In the updated process, design joined discovery, backlog shaping, and roadmap conversations.

Before detailed UI work began, the team defined the user need, mapped the relevant journey, stated the research question, and aligned on technical constraints. Concepts were reviewed earlier, prototypes could be validated, implementation received design support, and released changes returned to analytics and a success check.

To support the new workflow, I also introduced regular one-to-ones and design retrospectives, created growth plans connected to product needs and OKRs, and began building a shared knowledge base. Collaboration with support and engineering became a regular source of input for design work.

The intended result was a continuous cycle in which design could help frame the problem, test the direction, and learn from the outcome.

Once the operating model was clearer, I assessed the product itself.

A heuristic review, available usage data, and recurring feedback from support, engineering, and product exposed two layers of work: immediate problems in key flows and broader debt across the interface.

A complete redesign was possible, but the cost was high. It would take longer and force existing users to relearn a product they already knew.

We started with the critical flows and kept the broader interface update for a later phase. This gave us a way to improve the product without resetting the whole experience at once.

The Offer Builder became a practical test of the new approach.

We began by bringing feature requests, known pain points, business expectations, and technical constraints into one discovery space. This helped the team see the problem as a connected system instead of a collection of requested screens.