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

推荐订阅源

Vercel News
Vercel News
SecWiki News
SecWiki News
WordPress大学
WordPress大学
小众软件
小众软件
博客园 - 司徒正美
酷 壳 – CoolShell
酷 壳 – CoolShell
V
Visual Studio Blog
Y
Y Combinator Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
云风的 BLOG
云风的 BLOG
MyScale Blog
MyScale Blog
K
Kaspersky official blog
T
The Exploit Database - CXSecurity.com
腾讯CDC
Scott Helme
Scott Helme
I
InfoQ
Cyberwarzone
Cyberwarzone
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Security Latest
Security Latest
The Register - Security
The Register - Security
Project Zero
Project Zero
F
Fortinet All Blogs
C
CERT Recently Published Vulnerability Notes
A
Arctic Wolf
C
Cisco Blogs
L
LINUX DO - 热门话题
P
Privacy International News Feed
IT之家
IT之家
U
Unit 42
P
Privacy & Cybersecurity Law Blog
H
Help Net Security
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
C
Cyber Attacks, Cyber Crime and Cyber Security
P
Palo Alto Networks Blog
F
Full Disclosure
宝玉的分享
宝玉的分享
Simon Willison's Weblog
Simon Willison's Weblog
L
Lohrmann on Cybersecurity
Google DeepMind News
Google DeepMind News
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
H
Hacker News: Front Page
Know Your Adversary
Know Your Adversary
PCI Perspectives
PCI Perspectives
Hugging Face - Blog
Hugging Face - Blog
AWS News Blog
AWS News Blog
MongoDB | Blog
MongoDB | Blog
S
Schneier on Security
Recent Announcements
Recent Announcements
Forbes - Security
Forbes - Security
Cisco Talos Blog
Cisco Talos Blog

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.