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

推荐订阅源

T
Tor Project blog
B
Blog RSS Feed
M
MIT News - Artificial intelligence
WordPress大学
WordPress大学
H
Hackread – Cybersecurity News, Data Breaches, AI and More
罗磊的独立博客
GbyAI
GbyAI
N
Netflix TechBlog - Medium
博客园 - 司徒正美
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
宝玉的分享
宝玉的分享
W
WeLiveSecurity
Stack Overflow Blog
Stack Overflow Blog
Y
Y Combinator Blog
SecWiki News
SecWiki News
V
Vulnerabilities – Threatpost
Google DeepMind News
Google DeepMind News
C
CERT Recently Published Vulnerability Notes
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Register - Security
The Register - Security
Cisco Talos Blog
Cisco Talos Blog
Martin Fowler
Martin Fowler
A
About on SuperTechFans
S
Security @ Cisco Blogs
T
Tenable Blog
C
Check Point Blog
N
News and Events Feed by Topic
S
SegmentFault 最新的问题
The GitHub Blog
The GitHub Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
Attack and Defense Labs
Attack and Defense Labs
美团技术团队
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
C
Cisco Blogs
P
Palo Alto Networks Blog
V
V2EX
博客园 - 聂微东
Project Zero
Project Zero
酷 壳 – CoolShell
酷 壳 – CoolShell
D
Docker
N
News | PayPal Newsroom
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
小众软件
小众软件
Application and Cybersecurity Blog
Application and Cybersecurity Blog
人人都是产品经理
人人都是产品经理
V2EX - 技术
V2EX - 技术
I
Intezer
L
LINUX DO - 最新话题

Linear Blog

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 Building our way: Announcing our Series C - Linear Why is quality so rare? - Linear Design for the AI age Building what customers need, not just what they ask for - Linear The profitable startup - Linear Why and how Scale migrated to Linear - Linear Simplifying support at scale: How Pleo uses Linear Asks - Linear How we built multi-region support for Linear How we redesigned the Linear UI (part Ⅱ) - Linear Rethinking the startup MVP: Building a competitive product | Linear Descript's internal guide for using Linear Post mortem on Linear incident from Jan 24th, 2024 | Linear Why and how we do work trials at Linear Using AI to detect similar issues Planning for unplanned work How we run projects at Linear - Linear Linear raises $35M Series B led by Accel - Linear How we think about customer experience at Linear - Linear Scaling the Linear Sync Engine - Linear Welcoming Cristina Cordova to Linear How we built Project Updates Settings are not a design failure Linear – 2021 Wrapped Fast growing startups are built on Linear Building at the early stage Linear raises $13M in Series A funding from Sequoia Capital Invisible details - Building contextual menus - Linear Practices for Building — Linear is now open for all Startups, Write Changelogs Linear’s Next Chapter: Announcing our $4.2M Seed Round
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.