Yann-Edern Gillet
Designer at Linear
About
Yann-Edern is a designer at Linear, working on the desktop app.
He works across product features, internal tools, with a focus on developer experience. Thunderstorm is his playground, a non-portfolio-only digital place where he shares his thoughts, experiments and projects.
This is his third appearance in Workspaces. He was previously featured in edition #261 in 2023 and edition #442 in 2024.
This is his updated setup in mid-2026.
Photos
3 images
Gear
9 itemsSoftware
6 appsInterview
7 questions› What has changed in your setup since you were last featured in 2024?
I moved to a new place, so the biggest change is natural light. I still like a dark, slightly overbuilt desk, but I’ve tried to balance it with a lighter, more colorful side: a small library, red and yellow accents, and some art by Rasmus Andersson.
I also expanded my Analog collection and pushed the pegboard further into proper workbench territory. There are LEGO sets nearby now, which is probably not helping the minimalism, but they make the room feel more like mine.
The physical setup is only half of it. Linear and Codex have become the central nerve of the system: one keeps the work in view; the other helps me turn loose ideas into something I can test.
› What's the first tool or website that you open every morning?
Usually mymind, starting with Top of Mind. Then my personal Linear workspace to see what I left open for myself. After that it’s Apple Music or Elsewhere, depending on whether I need a little energy or a little atmosphere.
› When would you consider leveraging prompt-driven design into your design process?
I don’t really prompt designs. I use agents to make small tools while I’m designing: something that lets me test a motion direction, generate a useful dataset, or turn a system change into something the whole team can use.
That changes the gap between an idea and a working interface. A discussion, sketch, or repetitive task can become a tool quickly enough to be part of the design process, rather than a separate engineering project.
The important part is keeping control. More options are only useful if they buy me time to explore, compare, and tune—not just produce more output.
› Is there anything in your workflow you've automated or built a small tool for, rather than working around it?
At Linear, our theming system starts with three core variables, which generate more than a hundred values for the product. I built a Figma plugin that imports those updated values as color variables, so the design file follows the system instead of becoming a manual translation job.
I’ve done something similar with data. Mock content only becomes useful once it has enough of the mess and constraints of real life, so I added Dune, TRON: Legacy, and NASA datasets alongside Linear’s default one, plus more properties across the different entities.
More recently, I’ve been using Figma Agent to make plugins directly in the file. The latest one generates Linear-style graphs by spreading points over time along a path. I like that these tools stay with the file when it’s shared; the capability travels with the work.
› Has the barrier to building your own tools dropped enough that you actually reach for it now? What was the last one you made?
The barrier has dropped dramatically, although writing code was never the main obstacle for me. There’s a double-edged-sword aspect to a world where building software is nearly frictionless: it becomes very easy to build the wrong thing or get carried away by side quests. Agents are context-hungry and very happy to consume your ideas and tokens, so being intentional matters more than ever.
The last mini-tool was for a Thunderstorm release. I wanted to reuse components from the AMA codebase in an animated Remotion visual, with real questions and a little physics shaping the composition. I used Josh Puckett’s DialKit to tune every parameter until it felt right.
› What's changed about how you handle animation and transitions in the last year?
I think about motion more as a system now, rather than a collection of enter and exit presets. Similar components should feel related, even when they are doing different things.
I’ve also become more interested in adaptive motion. A small, dense component should not necessarily move like a large, airy one; size, weight, and context should influence the transition.
The tooling has made the refinement loop much better. It’s easier to move between design and code, test a direction, and tune it instead of accepting the first plausible animation. DialKit has been especially useful for that kind of adjustment.
› What's the piece of your workflow that used to require jumping between three tools and now doesn't?
Our theme-variable flow is a good example. It begins in code and is brought back into Figma by a small plugin, so the design system arrives where designers need it without someone copying values between three tools. I still think the promise of one all-in-one tool is a mirage. I like tools the way I like cars: close to the ground, built for a particular kind of driving.
The goal is not to spend your whole life in one tool; it’s to make the handoffs seamless when they should be. A little translation friction can still be valuable, too. It forces you to distill an idea to its core, then refine it as it moves between tools.
Similar setups
Browse all
Gavin Nelson
Designer at OpenAI
Matt D. Smith
Designer and the Founder of Shift Nudge
Grace Walker
Designer and Creative Director based in Calgary, Canada
Oksana Popovichenko
Ukrainian software engineer based in Toulouse, France