惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 三生石上(FineUI控件)
Hugging Face - Blog
Hugging Face - Blog
小众软件
小众软件
量子位
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
IT之家
IT之家
V
V2EX
阮一峰的网络日志
阮一峰的网络日志
爱范儿
爱范儿
人人都是产品经理
人人都是产品经理
博客园 - Franky
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园_首页
V
Visual Studio Blog
Last Week in AI
Last Week in AI
有赞技术团队
有赞技术团队
WordPress大学
WordPress大学
博客园 - 司徒正美
大猫的无限游戏
大猫的无限游戏
博客园 - 【当耐特】
MyScale Blog
MyScale Blog
月光博客
月光博客

Linear Blog

Styling Linear for the future with StyleX Sharing Linear’s growth with the people building it Rebuilding Linear’s delta sync read path How we built Linear Agent Introducing Loops - Linear Teaching an agent to auto-fix bugs - Linear Now Linear writes the code, too - Linear Reviewing code in the agent era - Linear Code review should be fast - Linear Code Intelligence for Linear Agent - Linear How we hire at Linear - Linear Output isn’t design - Linear How we use Linear Agent at Linear Post mortem on Linear security incident on March 24th, 2026 A calmer interface for a product in motion Design is more than code - Linear How our Customer Experience team works in Linear - Linear Continuous planning in Linear - Linear Designing remote work at Linear - Linear Self-driving SaaS: When software runs itself - Linear A Linear spin on Liquid Glass - Linear Best practices for designing Linear Dashboards - Linear Why we committed to a zero-bugs policy - Linear How Commure uses Dashboards to track performance and guide planning - Linear How we built Triage Intelligence - Linear Giving our team liquidity through Linear’s first tender offer - Linear How Cursor integrated with Linear for Agents - Linear Quality Wednesdays: How we trained our team to see what doesn’t work - Linear Our approach to building the Agent Interaction SDK - Linear Inside Mercury’s six-month journey building with AI agents - Linear
A design reset (part I)
Karri Saarinen · 2024-03-27 · via Linear Blog

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.