Been designing the last few weeks and realized how simple but effective the @linear design system is. There is no design system team, no councils, no meetings about what we should call it or if it’s “atomic" or not. We have a system which has colors, type, icons and components
We have had the system from the beginning which helped to speed up both design and development, and even allow supporting dark, light and custom user themes in the app. We have one file in Figma which describes it and also built in to the code.
Colors. So we have basic groups like Bg, Label, Control. So when I’m designing I just draw a shape, then write "bg base" to get the default background color, and label base to get the default text color. Then there is variations like Shade, Muted, Faint etc.
Same for text. We have to groups Body and Title, which has Large, Regular, Small and Mini type with "+" variations which means it's heavier weight. Default text size is Regular, lot of attributes and secondary stuff is Small and titles are Large.
Then we have Elevation which set of standard shadows for dark and light modes. shadowLow is for small things like buttons, shadowMedium/High is for slightly larger boxes that are elevated and Float is for larger boxes that float over everything else.
Then we have Icons as components and they can be pulled in to the designs or components like buttons.
We don't have all the components Figma, but they exist in the code. We have common ones like Buttons or List items or Status things that you need often. We try to use existing components when can but it's usually faster to redraw the component than trying to maintain a library
It feels very simple and light but still useful. Like a good tool. There is no drama or complex ideas. Just the things we need. I don't feel constrained by it but feel like it speeds me up.
Like it should be but seems there is this tendency to complicate things uncessarily
This kind of mirrors the philosophy we have for @linear and Linear Method:
Focus your efforts on the actual task on hand (building software), not on side quests (building process or management systems).
While we don’t have a “design system team”, everyone contributes to the system. It’s a natural part of the tool chain and we improve as we go
I was just reminded that for our Series A, we sent a questionnaire to the investors we were considering to understand if we have alignment.
Then the investor needed to write a doc or a presentation explaining their answers and thinking.
It had questions like which other investors they would add to the round and why, what kind GTM they would see effective and examples, how to resolve specific challenge X, Y, Z, key hires and how they help with hiring, how to grow business to ARR, how sales plays etc...
This helped us to understand much better the differences between the investors.
Ideally we wanted to see that the investor had similar values or alignment but also they they could add something and impress us with their thinking.
Being a designer, and obviously design was important for Coinbase, this is a bad take even by Twitter’s standard.
(Btw, I was managing the metalab’s work for the landing page. We stopped working with them after that project and I redid the landing pages few months later)
The reality is more nuanced. When I joined as the first designer back in 2014, Coinbase had already hired compliance and legal. They thought about security, banking relations. Things that make or break it. Companies don’t succeed or fail because of a color choice
The success happens because get lot of things right, and not that many critical things wrong. The early team was excellent in many ways. Everyone regardless of the role completed 2 week work trial before getting an offer.
At @linear_app, we don’t write user stories. They’re unnecessary and slow down the team.
I also always found them very weird to write and read. It’s like the tasks are in ancient Greek instead of English that everyone can understand. Wonder if other people felt this way?
More👇
User stories are a roundabout way to describe a todo. It would be ridiculous to write your todos this way. “As a human, I need to go to the store in order to have food to eat”. You would never write that. Instead: “Get groceries” and list items to buy.
Or imagine trying to build a rocket with user stories. Behind the “Fly me up the gravity well and not blow me up” user story, there is thousands of technical parts systems that needs to be built and considered. User stories is the wrong kind of abstraction for most tasks.
1/ For anyone considering leaving SF, here is my story: After living 7 years in SF, 6months ago finally moved out to San Diego, close to Encinitas
2/ My main worry was losing on the SF scene and ambition but actually been able to keep in touch with many investors and fellow founders and friends, especially now since no-one can meet anyway. Also, I guess in 7 years to learn a lot that stays with you
3/ There are some startup, YC founders, etc here and I’m guessing more will also come here as companies go remote. At this pre-launch stage, it’s been also good be away from the SF distractions and focus on the company and the product. T