JRNI Studio Redesign

I was tasked with leading the UX & Design team in benchmarking, researching and redesigning JRNI’s entire platform.

Background and scope

Demand for a UI refresh at JRNI had been building since 2019. We had just undergone a drastic rebrand, but the app itself hadn’t been updated to match, so there was a visual mismatch between our product and the rest of our online presence.

Then in 2019, Google announced they were ending support for AngularJS, a JavaScript-based framework. AngularJS was being used at JRNI across the entire Admin platform, so suddenly there was a huge incentive for the business to rewrite the entire front-end codebase using a new, supported framework.

This is where JRNI’s Product team stepped in. The combined demands of updating the platform’s UIs, with the tech requirement to rewrite vast swathes of the front-end code, provided the incentive to finally tackle this mammoth project. As Senior UX/UI Designer at JRNI, I was tasked at the start of 2021 with spear-heading this design initiative, leading the design team in researching our current product offering, highlighting key areas of improvement, and building out a Design System and process for both updating the existing UIs and introducing new functionality where needed.

Tools / Tech stack

Due to the growing product team at JRNI, we moved from Sketch to Figma as our primary design tool in March 2021. This would allow for closer collaboration between designers, and its excellent component & library functionality would help us maintain visual consistency across all our designs.

Zeplin would remain our primary hand-off tool, though one of my aims for the project was to ensure that no developer would be surprised when designs landed in their lap. As such, I made sure devs were included early in the process, were invited to design crits and provided technical feedback throughout the design process.

Pendo was a new tool the Product team had invested in earlier in 2021. It provided us with incredible, granular detail on how users interact with our software, and a direct line of communication with our end-users for questionnaires, NPS & CSAT functionality.

Usertesting.com was a tool we initially started using in 2020 as a response to COVID-19 limiting our ability to perform in-person testing. It has since become a core part of our process and is used weekly to validate and test designs against fresh-eye users.

Scope

I split the scope into two key areas – Existing Functionality Overhauls, and New Functionality Areas. The former were pages that mostly required a UI update, while still allowing room for UX improvements and new features where the research indicated they were necessary. The latter were more robust; either completely new functionality, or pages requiring a serious UX rethink.

We also split the work into invidividual product areas (e.g. Calendar, Customer Profile, Sign-in). The aim here was that these could be worked on with relative independence; each would have a generous ‘discovery’ phase to benchmark the current solution, analyse the market and collate any internal feedback. Ultimately this provided a constant loop through the User-Centred Design process, and allowed for multiple streams of design work to occur simultaneously.

Roadmap

As mentioned above; work was tackled on a per-feature basis. This allowed multiple designers to work independently, and ensured a high rate of designs hitting hand-off to meet the developers’ velocity. Each of these feature areas was further split into a discovery phase and a design phase, the durations of which depending on an approximate sizing of the work beforehand. Unsurprisingly, keeping the team aligned with a shared roadmap was vital for keeping track of our progress.

Design System

From the outset, I began working on what would ultimately become the JRNI Design System. This included all the tools and guides to ensure that the design team could maintain consistency across their work, which was vital considering the somewhat segmented approach we were taking. The document was a bit barebones to start, however I considered it a living doc and continued to update it throughout the project, adding details and tweaking aspects as needed. Ultimately a lot of the content here would be usurped by an online component library the developers were building; however it remained a key pillar of our design process (not to mention the source of many heated discussions…)