FORGE-001 / Linear neden hızlı hissettiriyor?

İnceleme sınırı

Bu bir "Linear klonu nasıl yapılır?" yazısı değil. Ayrıca özel bir Linear workspace'ine veya erişim kontrolü gerektiren yüzeylere dayanmaz. Bu public vaka; Linear'ın güncel, kamuya açık ürün dokümantasyonu üzerinden doğrulanabilen etkileşimleri kullanır.

Bu ayrım FORGE için önemli: kanıtlayamadığımız davranışı olmuş gibi yazmıyoruz.

Kanıt seviyesini bu çalışma için şöyle okuyabilirsin:

• E1: Kamuya açık resmi ürün dokümantasyonu
• E2: Doğrudan ürün/tarayıcı gözlemi
• E3: Birden fazla bağımsız sinyalle doğrulama

Bu public teardown'daki temel bulguların çoğu E1 seviyesinde. Ücretli bir FORGE çalışmasında izin verilen ürün yüzeyleri ayrıca gerçek kullanım akışında gözlemlenir.

Tez

Linear'ın hızlı hissettirmesini yalnızca animasyonlara, tipografiye veya "minimal UI" estetiğine bağlamak eksik olur.

Benim çıkardığım temel tez şu:

Linear, sık yapılan işlerde kullanıcının bağlam değiştirme ve karar verme maliyetini düşürüyor.

Bunu beş ayrı davranışta görebiliyoruz:

1. issue oluşturma, 2. listeden ayrılmadan detay görme, 3. klavyeyle seçim ve toplu işlem, 4. bağlama göre farklı arama yolları, 5. issue bağlamını coding aracına taşıma.

E-001 / Issue oluşturmak ayrı bir "form doldurma işi" olmak zorunda değil

Linear dokümantasyonuna göre yeni issue oluşturmak için doğrudan C kısayolu kullanılabiliyor. V tam ekran oluşturmayı açıyor. Template için Alt/Option + C var. Kullanıcı ayrıca linear.new URL'siyle doğrudan oluşturma akışına girebiliyor.

Daha önemli ayrıntı şu: issue için zorunlu alanlar temel olarak başlık ve durum; diğer özellikler ve ilişkiler isteğe bağlı. Linear ayrıca oluşturmayı izleyen ilk üç dakikadaki property değişikliklerini creation sürecinin parçası sayıyor.

Kaynak: Linear Docs — Create issues

Çıkarılan prensip / P-001

Sık yapılan bir oluşturma eylemini, ilk anda tüm metadata'nın doldurulmasına bağlama.

Kullanıcı önce işi kaydedebilmeli; bağlam, öncelik, etiket, ilişki gibi ikincil kararları sonra tamamlayabilmeli.

Bu prensibi şöyle ifade edebilirim:

1const creationCost = requiredDecisionsBeforeSave;2
3if (action.frequency === "high") {4  minimize(creationCost);5}

Bu her üründe geçerli değil. Örneğin banka transferinde veya yasal başvuruda gerekli alanları sonradan bırakmak yanlış olabilir. FORGE'un görevi prensibi almak; ekranı kopyalamak değil.

E-002 / Peek: detay görmek için listeden çıkmak zorunda değilsin

Linear'ın Peek özelliği listede veya board'da odaklanan issue ya da project detaylarını ana görünümü terk etmeden önizliyor. Space ile açılabiliyor; açıkken yukarı/aşağı hareket edildiğinde önizlenen kayıt da değişiyor.

Kaynak: Linear Docs — Peek preview

Bu küçük davranış önemli çünkü klasik yapı şudur:

1LISTE2  ↓3DETAY SAYFASI4  ↓5GERİ6  ↓7LİSTE

Peek ise şuna yaklaşıyor:

1LISTE + GEÇİCİ DETAY

Çıkarılan prensip / P-002

İnceleme eylemi, çalışma bağlamını gereksiz yere yok etmemeli.

Bir kullanıcı art arda 15 kaydı karşılaştıracaksa 15 kez route değiştirmek yerine ana bağlamı koruyan bir preview modeli daha düşük etkileşim maliyeti yaratabilir.

E-003 / Klavye desteği ayrı bir "power user modu" değil

Linear'ın seçim davranışlarında issue'lar ok tuşları veya J / K ile highlight edilebiliyor. X ile seçim yapılabiliyor. Seçili issue üzerinde keyboard shortcut, command menu veya sağ tık menüsü üzerinden işlem uygulanabiliyor.

Kaynak: Linear Docs — Select issues

Buradaki ilginç nokta yalnızca çok sayıda kısayol olması değil.

Aynı nesne için birden fazla etkileşim yolu var:

• fare,
• klavye,
• command menu,
• contextual menu.

Çıkarılan prensip / P-003

Yüksek frekanslı profesyonel araçlarda klavye, farenin alternatifi değil tamamlayıcısı olabilir.

Ama burada kopyalanmaması gereken bir şey de var: her ürün onlarca kısayola ihtiyaç duymaz. Haftada bir kullanılan tüketici ürününe Linear kadar keyboard density eklemek öğrenme maliyetini gereksiz artırabilir.

E-004 / "Arama" tek bir global kutu değil

Linear farklı arama niyetlerini farklı giriş noktalarına ayırıyor. Dokümantasyonda:

• / workspace genelinde arama,
• Cmd/Ctrl + F mevcut board/list/inbox içinde arama,
• O → I issue odaklı hızlı arama / recent issues

gibi farklı davranışlar tanımlanıyor.

Kaynak: Linear Docs — Search

Çıkarılan prensip / P-004

Arama kapsamını kullanıcıdan her seferinde seçmesini istemek yerine, eylemin başladığı bağlam kapsamı belirleyebilir.

Global search ile "şu an baktığım listenin içinde bul" aynı kullanıcı işi değildir.

E-005 / Düzenlemek için ayrı "edit mode" zorunlu değil

Linear issue başlığı ve açıklamasının doğrudan tıklanarak inline düzenlenebildiğini belgeliyor.

Kaynak: Linear Docs — Edit issues

Çıkarılan prensip / P-005

Basit ve geri alınabilir değişikliklerde görüntüleme ile düzenleme arasındaki töreni azalt.

Her alan için ayrı "Edit → Form → Save → Return" zinciri, özellikle sık güncellenen operasyonel nesnelerde gereksiz sürtünme yaratabilir.

E-006 / Issue ile coding agent arasındaki context taşıma

Linear'ın güncel dokümantasyonu issue'ları Cursor, Claude Code veya Codex gibi coding araçlarında açmayı destekliyor. Issue verisi ve isteğe bağlı özel prompt, coding aracının işe doğru bağlamla başlaması için aktarılabiliyor.

Kaynak: Linear Docs — Assign and delegate issues

Bu FORGE açısından özellikle ilginç.

Çünkü modern ürün akışının yeni problemi yalnızca "task developer'a nasıl atanır?" değil:

Task ile birlikte doğru bağlam nasıl taşınır?

Çıkarılan prensip / P-006

Execution handoff yalnızca iş kimliğini değil, işi doğru uygulamak için gereken bağlamı da taşımalı.

FORGE'un uygulama sözleşmesi fikri de burada aynı temel probleme dokunuyor; fakat daha üst seviyede, tek issue yerine ürün kararlarını ve sistem sınırlarını kapsıyor.

Sistem çözümlemesi

Bu kanıtları ekranlara göre değil sistemlere göre toplarsak Linear'daki hız hissinin en az şu katmanlardan üretildiğini görebiliriz:

Burada ortak desen "az ekran" değil.

Ortak desen daha az bağlam kaybı.

Neyi kopyalamazdım?

Bir FORGE çalışmasının görevi yalnızca iyi tarafları listelemek değil, referans ürünün hangi prensiplerinin bizim probleme uygulanmaması gerektiğini de belirlemek.

1. Her ürüne yoğun keyboard sistemi koymazdım

Linear profesyonel ve tekrarlı çalışma için tasarlanıyor. Ayda iki kez açılan bir tüketici uygulamasında onlarca shortcut yatırımının getirisi farklı olabilir.

2. Issue merkezli nesne modelini otomatik kabul etmezdim

Bir CRM, kişisel bilgi sistemi veya sağlık uygulamasının ana nesnesi "issue" değildir. Linear'ın interaction pattern'leri taşınabilir; domain modeli taşınmak zorunda değildir.

3. Command menu'yu sırf modern göründüğü için eklemezdim

Command menu ancak yeterli sayıda tekrar eden, bağlamdan bağımsız eylemi hızlandırıyorsa değerlidir. Beş aksiyonlu basit bir uygulamada ekstra keşif yüzeyi olur.

4. "Hız" uğruna kritik doğrulamaları kaldırmazdım

Linear'da düşük riskli metadata kararlarının ertelenebilmesi mantıklı. Finans, erişim kontrolü veya geri döndürülemez işlemlerde aynı prensip doğrudan kullanılamaz.

Bir ürüne nasıl uyarlarım?

Varsayalım freelancer'lar için proje ve müşteri işlerini yöneten yeni bir ürün geliştiriyoruz.

Yanlış yaklaşım:

Linear'ın sidebar'ını, issue modal'ını ve command menu'sunu yap.

FORGE yaklaşımı:

Karar D-001 / Hızlı iş kaydı

Kanıt: E-001 Prensip: P-001 Karar: Yeni iş oluşturmak için yalnızca başlık + müşteri/proje bağlamı zorunlu olsun. Tarih, etiket ve tahmin sonradan eklenebilsin. Neden: Kullanıcının ana işi işi sisteme kaydetmek; planlama metadata'sını eksiksiz doldurmak değil.

Karar D-002 / Bağlamı koruyan önizleme

Kanıt: E-002 Prensip: P-002 Karar: Masaüstünde listeden iş detayına hızlı preview ver; mobilde aynı pattern'i zorla kopyalama, tam ekran sheet kullan. Neden: Aynı prensip farklı ekran sınırlarında farklı UI gerektirir.

Karar D-003 / Keyboard yatırımı

Kanıt: E-003 + E-004 Prensip: P-003 + P-004 Karar: İlk sürümde yalnızca create, search ve quick switch kısayolları olsun. Komple shortcut matrisi kullanım verisi oluşmadan yapılmasın.

İşte "referanstan sisteme" geçiş burada gerçekleşiyor.

Uygulama sözleşmesine nasıl dönüşür?

Araştırmanın son çıktısı "Linear güzel, hızlı bir şey yap" değildir.

Örneğin coding agent'a giden sözleşmenin küçük bir bölümü şöyle olabilir:

1## CREATE WORK ITEM2
3REQUIREMENTS4- Desktop shortcut: C5- Required before first save: title, projectId6- Optional after save: dueDate, estimate, labels, assignee7- Creation must not navigate away from the current project list8- Unsaved draft must survive accidental modal close within the same session9
10RESPONSIVE11- Desktop: modal composer12- Mobile: full-height sheet13
14ACCEPTANCE15- Given a project list is open, pressing C opens the composer without route change16- A valid item can be saved with title + projectId only17- Closing an unfinished composer and reopening it in the same session restores the draft18
19DO NOT20- Copy Linear visual assets, layout or wording21- Add a global command menu in v122- Require estimate, labels or due date before first save

Bu noktada coding agent'ın görevi ürün tasarlamak değil; kilitlenmiş kararı uygulamak olur.

FORGE-001 sonucu

Linear'dan çıkardığım temel sonuç "çok kısayol ekle" değil.

Daha derindeki prensip şu:

Sık yapılan işlerde bağlam geçişini ve karar sayısını azalt.

Bu prensip farklı ürünlere farklı UI ile uygulanabilir.

FORGE'un amacı tam olarak bu ayrımı yapmak:

1REFERANS2↓3KANIT4↓5PRENSİP6↓7BİZİM KARARIMIZ8↓9UYGULAMA SÖZLEŞMESİ

Bu çalışma FORGE-01 ürün çözümlemesinin kamuya açık, sınırlı kapsamlı bir örneğidir.

FORGE metodolojisini incele veya FORGE paketleri ve fiyatlarını gör.