How to spot the tiny design decisions like Linear

Imagine you’re in the home stretch of a new project.

You’re proud of the designs, feeling confident, but then you get a Slack notification from your engineering counterpart…

“Hey, how should we handle [edge case]?”

Shoot.

That impacts an entire flow of screens and all of a sudden you’re scrambling because you’re blocking engineers and your PM just posted a message about shipping next week 🤦‍♂️

Sound familiar?

Spotting these edge cases are where the lines between design and engineering become the most blurred.

Because the deliverables are design-driven, but the needs often surface while writing code.

That’s why your goal is to push design thinking into this messy middle zone to uncover as many tiny design decisions as possible 👇

"By the time you hand off your designs to an engineer, if they’re the ones who have to come back and ask you about the edge cases, to me… that’s too late”
​— Julius Tarng (Engineer at Linear)

🔍 How to uncover the edge cases in design

A few ideas that stood out to me after interviewing Julius Tarng 👇

Treat edge cases as a deliverable

Tiny design decisions are typically the ~3% of designs you didn’t realize you needed.

Unfortunately, this means they often surface late in the product development process. This is when design becomes reactive 😬

Not only that, but you’re most likely now dealing with constraints based on what has already been written in code.

Nobody wants to be the designer who makes engineers backtrack days before a deadline.

That’s why I encourage you to list out all of the edge cases you can think of as early in your design thinking as possible. Treat this as a regular deliverable in your process. Share it with your PM, engineers, etc. A lot of times I do this in Notion instead of Figma.

It might look something like this 👀

The key is to start these conversations before prepping a Figma file for engineers. Don’t let polished UI block you from getting everyone aligned on the edge cases.

Reach for greater fidelity

Remember how I encouraged you to view design and engineering as one continuous spectrum of fidelity?

Well… the higher the fidelity of your explorations, the more likely you are to spot these tiny design decisions—especially when you’re dealing with interaction details.

Static mockups are less likely to be a forcing function than a true prototype. And that’s a big reason why the designers we look up to keep pushing further down this spectrum:

• Raphael Schaad talked about “sketching in code” while designing Cron

• ​Origami keeps coming up as a theme in these interviews (because you can do stuff like this)

I'll admit it... I don't use Origami (and maybe I feel a bit self-conscious admitting that to thousands of people 😅).

But it's also why my plan for 2024 is to start experimenting in Play 👀

Think like an architect

Architects have a deep understanding of structural materials and how to use them effectively. It’s not just about having vision for how a building can be aesthetically pleasing. They also consider load-bearing requirements, thermal contraction, etc.

If you want to go from UX designer to software designer, then you need to start thinking like an architect.

Because the more you understand the materials your UI will be built with, the better you’ll be at proactively spotting these tiny design decisions.

In my interview with Julius Tarng, he used Linear’s project dependencies as an example.

It’s tough to design a Gantt chart system without having a basic understanding of how your frontend will be built. For example, a challenge they are currently thinking through is how do you design the arrows when one project has multiple dependencies? Not easy...

"The best software designers I know think through these tiny little decisions. Even though they’re not engineers, they have this technical intuition to look at a problem and understand what is going to be important in order to make this thing real” — Julius Tarng (engineer @ Linear)

btw if you're looking to level up your technical intuition then I recommend bookmarking this Youtube playlist — Web development for designers​

Why the tiny design decisions matter

When you read “craft” and “Linear” I bet the first image that pops into your mind is a dark purple landing page.

However, Linear's commitment to quality is most evident in the product itself. Because on the surface it’s hardly more than a glorified spreadsheet.

What sets Linear apart is the team's focus on identifying and prioritizing these tiny design decisions. Ultimately, it's the sum of these decisions that determines the quality of a product.

So don’t wait for engineers to point out the edge cases. Put in the reps and practice seeking them out.

Speaking of Linear... 👇

🌀 Dissolving the line between design and engineering

​Julius Tarng is the ultimate generalist designer.

He started the design tools team at Facebook (where he made a massive impact on products like Origami).

Then he freelanced as a design engineer creating early prototypes for companies like Felt, Anthropic, and even some of the early AI explorations for Arc.

But then he did something a bit crazy...

He decided to join Linear in his first-ever engineering role to serve as his "anime training arc" 😄

So this conversation is a deep dive into what it looks like for designers to approach their work with an engineering mindset. We talk about Julius’s background in prototyping, how he collaborates with designers at Linear. And we also get into some pretttty spicy takes about design engineering.

Listen on YouTube, Spotify, Apple, or wherever you get your podcasts 👇