Restructuring an evolving app
Cushion is coming up on 4 years soon. With the anniversary approaching, I’ve been reflecting a lot. I think about how this side project has become my full-time job. I think about how I’ve been able to employ people. I think about how incredibly far we’ve come since the original idea of Cushion.
I’d like to focus on this last thought—how far we’ve come. As positive as it sounds, there’s also a negative side to it. In a positive light, we’ve built dozens of useful features that help freelancers every day—I’m proud of this. However, while building these useful features incrementally, we’ve squeezed a lot into an interface that wasn’t designed with the new features in mind. This resulted in several compromise-based implementations—specifically regarding the layout, routing, and UX.
While it’s easier to release features and improvements little by little, there comes a point where we need to take a giant step back and make sure everything fits together as best it can. After years with a layout that worked, we eventually found ourselves playing a game of jenga with the UI—carefully placing new pieces on top, rather than rethinking the layout to consider all the pieces at once.
To make matters worse, the current routing system was structured with complete disregard for hierarchy. Rather than following a breadcrumb pattern with levels, like
schedule > overview > projects, we have something like
projectsScheduleOverview—a single route that defines all of the route’s views from a flat perspective. I still shake my head at the original dev who I inherited the code from—me from 4 years ago.
In an ideal world, a route’s views would cascade down, like a Russian doll. A child view wouldn’t know about its parent, nor would it need to know. If we wanted to separate out a specific part of the app, we could extract the view at any point and it could function on its own. Instead, the routes are tied directly to each level of navigation. Extracting a view would be like pulling a piece from the bottom of the jenga tower.
In addition to the layout’s UI, its UX didn’t age well, either. As Cushion grew beyond a single view, common workflows that once involved a single step now became two steps, or three. Creating a new invoice for a client now meant navigating to the invoicing section, knowing to click a button halfway down the page, then being taken to an entirely new page. Not only is this cumbersome for anyone familiar with Cushion, it leaves a terrible impression for anyone evaluating the app for the first time.
UI/UX aside, these are common workflows that freelancers are likely to experience at any given moment—meeting a new client, learning about a new project, sending an invoice to get paid, starting a timer. In the instant a freelancer needs to act, the last thought crossing their mind should be “Oh, I need to switch to the time-tracking section in order to start a timer.” Instead, this should involve one step—“Start a timer.”
I could go on and on about the issues that pile up over time, but that’s to be expected of any app that’s been around for years. Fortunately, we’re in a position to correct these flaws, and I’m determined to do so, instead of living with them. In the next post, I’ll detail the redesigned layout that we’re working on, including the design process and technical challenges.
I criticize Cushion quite a bit in this post, but at the end of the day, I’m thrilled with what we’ve been able to accomplish as a nimble team of three. The fact that anyone pays for Cushion is a win in my book.