Modernising a legacy desktop app

Prior to beginning the redesign process, we recognized that the product's Java FX and Swing foundation, being part of an acquired codebase, seemed to place fairly significant limits on what could even be proposed. As a result, we spent the early weeks of the project working to understand what the framework could and could not reasonably support, leveraging AI tools to help us get up to speed on an unfamiliar stack more efficiently, which in turn allowed us to bring better, more informed questions to engineering sooner rather than later.

In light of the fact that a proposed redesign could be easily dismissed as simply a designer’s opinion, we made the decision to lead with churn data instead. This data seemed to suggest that the outdated experience may have been contributing to a significant portion of user attrition, and that the appropriate fix was a full pivot. As a result of this insight, leadership’s position on the redesign ultimately shifted.

After winning the argument for a full pivot, the natural next step could have been to pursue a full re-platform, though this approach seemed likely to be both costly and time-consuming. To address this, we designed the modernization to work within the existing legacy Java constraints, collaborating closely with engineering to identify workarounds in the instances where the framework was not necessarily able to support what the design called for. In this way, the constraint itself became a key driver of the overall design direction.

Upon observation, we found that launching Studio dropped users directly into the document viewer with no document present, which could be seen as a less than seamless first impression. The app appeared to show users where a file should go, while leaving them to work out how to get one there themselves, and in addition, every tool it offered sat behind a menu that a user would already need to be familiar with in order to find it. To address this issue, the new UI was designed to open on a home screen instead, surfacing recent files alongside the six most-wanted jobs, named clearly as tasks, in order to create a more user-friendly and intuitive starting point.

Upon analysis, we found that older versions had shipped with a bug that allowed the demo to run indefinitely, meaning that anyone still using those builds effectively had access to a paid product at no cost, which was not necessarily sustainable from a business perspective. To address this issue, we introduced a gate at the end of the trial period: once the demo expires, the product stops functioning and presents the three available paths forward, namely signing in, subscribing, or entering a perpetual license key. Throughout the trial, the banner communicates the countdown transparently, so that the eventual lockout is never a surprise to the user, which we believed would help preserve trust and overall satisfaction.

In addition, this fix needed to function seamlessly across both interface shells, as the redesign was still mid-flight while the revenue leak remained live. As a result, we built the gate as a single shared component that both the old blue chrome and the new interface could host, which ultimately allowed this revenue fix to ship on its own schedule, without being held back by the broader redesign timeline.

As a result of recognizing that a redesign of this scale could easily drift if every screen were designed in isolation, we built an internal design system alongside the broader project, with components named clearly enough that a developer could hover over any element and understand what it represented. This was intended to function as a working library to support our own screens and to streamline the hand-off process, though we would not necessarily characterize it as a company-wide design system.