A design reset (part I)
We have redefined the foundational layers of Linear’s application with a full redesign. This is the first post in a two-part series where we dive into why and how we redesigned the application. In this post, we share why redesigns are important. In part two, we introduce you to the new UI and cover how we tackled the project.
No software design is truly timeless. We often hesitate to do product redesigns, even when we probably need one. I've been part of these projects several times in my career as a designer and it has never been something easy to pull off.
The challenges start from the fact that it's never a good time to do a redesign. It's hard to make it a priority. It's difficult to calculate the ROI on it. And if you run your product with A/B testing, every global redesign will tank the metrics in the short term. Teams get furious and try to push back as they don’t want to see their product surfaces changed outside of their control.
However painful it might be, there is a real need for redesigns, and your product experience suffers if you never do it.
Design debt is real
The real need for redesigns often comes when you have created a successful product and it has evolved with the market and users over time. This is also the case with Linear.
We ship small changes daily, and something major almost every week. Every year, it's almost like a new product. This incremental way of building the product is hugely beneficial, and often necessary — though it unbalances the overall design, and leads to design debt. Each new capability adds stress on the product's existing surfaces for which it was initially designed. Functionality no longer fits in a coherent way. It needs to be rebalanced and rethought.
I believe this debt has to be paid if you aim to keep your product experience excellent. If your product evolves fast, you should be paying this debt every 2-3 years. The longer you wait and the more successful your product becomes, the more you will have to untangle.
Slowly the user sentiment and perception might start turning negative and you might start looking like a dinosaur incumbent. This leaves an opportunity for some nimbler player to come along and compete in your market. Companies often try to address this with brand refreshes, but if you don’t refresh the product, nothing truly changes about the experience.
While the design debt often happens in small increments, it’s best to be paid in larger sweeps. This goes against the common wisdom in engineering where complete code rewrites are avoided. The difference is that on the engineering side, a modular or incremental way of working can work as the technical implementation is not really visible. Whereas the product experience is holistic and visual. You cannot predict which path the user takes. If you update just one module or view at a time, the overall experience becomes more disjointed. Secondly, if your goal is to reset and rebalance the whole product UI and experience, you have to consider all the needs simultaneously. An incremental approach doesn’t let you do that.
There needs to be a major reset on which you can leap forward.
CEOs & leadership need to be behind the change
A real redesign can only happen when there is a reset on the design across the whole product. That’s why I’ve never seen redesigns successfully executed without the CEO behind it. While design might have a seat at the table generally, they are usually not able to convince everyone around that table. Only the CEO can push through all the excuses and give the latitude to a project touching all of the surfaces the product needs.
The CEO's interest is not only critical because it gives the project the air cover it needs, it also gets them and many other execs involved and makes sure they take it seriously. While leadership might not have direct input on the design itself, they have a perspective on where the company is headed, so you can proverbially skate to where the puck is going.
The way to get the CEO involved is to tie a design reset into a larger company shift or directional change. For example, if a company is looking at a new product, or major new feature, a redesign project can be a way to imagine how it might look or feel. This can be the justification for why you need to spin up the team (and at the same time, you can make a case for updating the rest of the product experience).
For the leadership team, this design project can be the initial momentum they need to galvanize the company and steer it into a new direction. Organizations are often quite stuck in their views and ways of doing things, making them less enthusiastic about something new. When I was at Airbnb, the mobile redesign project was a way to shift the company to become mobile-first. It set the tone and got the message across to the whole company that mobile was happening and that it was happening now. While it looks like an obvious change in hindsight, there were many arguments against it at the time and it took a lot of convincing. Switching to think about mobile meant the design and features had to be rethought to work in that platform.
While Linear is a smaller and younger company, we’re also undergoing a shift. The product vision has widened from a simple issue tracker to a purpose-built system for product development. We are now moving into planning workflows that naturally come before the building or execution phase of building products. This product evolution creates new future needs from the product design, and we have to make space for it.
From concept to yes
When you realize that a design reset is needed for your product, how do you actually get started with the project? You start with a standalone team to explore the new concept design and create something the company can rally around.
The auto industry has a practice of building “concept cars”, where they explore the next version of the car freely and boldly without considering practicality. A concept car sets the direction, but usually is not expected to land in production because it’s too impractical or costly to manufacture.
Calling it a concept is important, especially at the start. A secret I've learned is that when you tell people a design is a "concept" or "conceptual" it makes it less likely that the idea is attacked from whatever perspective they hold or problems they see with it. The concept is not perceived as real, but something that can be entertained. By bringing leaders or even teams along with the concept iterations, it starts to solidify the new direction in their mind, eventually becoming more and more familiar. That's the power of visual design.
It becomes something easier and easier to say yes to, not something to say no to.
But eventually the concept has to become real in some way. How did we do this for Linear? We cover that in Part II.
