Neden “daha az inşa et” AI ile yapılan uygulamalarda daha da önemli\n\nÇoğu ürün özellik eksikliğinden başarısız olmaz. Başarısız olmasının nedeni genellikle karmaşık hissettirmesidir: çok fazla düğme, çok fazla ayar, bir kişinin yaptığı tek işi bitirmesine yardımcı olmayan yan yollar.\n\nAI bu sorunu kötüleştirir çünkü fazla inşa etmeyi kolaylaştırır. Sohbet tabanlı bir araç dakikalar içinde bir gösterge tablosu, roller, bildirimler, analizler ve ek sayfalar oluşturabiliyorsa, bunları eklememek sorumsuzluk gibi hissedilir. Ancak hız fayda demek değildir. Sadece dağınıklığı daha hızlı üretebileceğiniz anlamına gelir.\n\nKısıt odaklı ürün tasarımı basit bir karşı ağırlıktır. Ne inşa etmeyeceğinize karar verin ki inşa ettiğiniz parça net kalsın. “Daha az inşa et” bir slogan değil. Gerçek bir üründe bu, bir iş akışı, bir hedef kitle ve bir başarı anı seçmek ve bunları desteklemeyen her şeyi kesmek demektir.\n\nİyi bir test tekrarlanabilir değerdir: bu, birinin normal bir haftada tekrar tekrar ihtiyaç duyduğu bir sonucu almasına yardımcı olur mu?\n\nTekrarlanabilir değer genellikle tanıdık ritimlerde ortaya çıkar. Günlük görevlerde (gönder, planla, onayla, cevapla), haftalık rutinlerde (gözden geçir, uzlaştır, planla, yayınla) veya görev başına sürtünmede (kopyalama, biçimlendirme, durum takibi) yardımcı olur. Değer tekrarlanabilirse, kullanıcılar hatırlatma olmadan geri döner. Değilse, uygulamayı unuturlar.\n\nKüçük iş akışları büyük platformlardan üstündür çünkü öğrenmesi daha kolay, güvenilmesi daha kolay ve sakin tutulması daha kolaydır. Tam bir web uygulamasını hızlıca inşa edebilseniz bile, genellikle kazanan hamle, birinin tekrar edebileceği en küçük iş akışını göndermek ve o iş akışı zaten sevildiğinde genişlemektir.\n\n## Kısıt odaklı ürün tasarımı, tek bir fikirde\n\nKısıt odaklı ürün tasarımı, sınırları engel olarak değil, bileşen olarak ele almayı ifade eder. Ürünün ne olmayacağına baştan karar verirsiniz, böylece yaptığınız şey açık, sakin ve tekrarlanması kolay olur.\n\nJason Fried’in “sakin yazılım” fikri burada uyar: yazılım dikkat çalmaya çalışmamalı, dikkati hak etmeli. Bu genellikle daha az ekran, daha az uyarı ve daha az ayar demektir. Uygulama gerçekten ihtiyaç duyulmadıkça sessiz kaldığında, insanlar ona daha çok güvenir ve kullanmayı sürdürür.\n\nKısıtlar ayrıca karar yorgunluğunu azaltır. Ekip kurallar net olduğunda sonsuz seçenekler üzerinde tartışmayı bırakır. Kullanıcılar daha az yol ve daha az “belki bu işe yarar” anı olduğu için tahmin yürütmeyi bırakır.\n\nPratik bir kısıt seti spesifik olur. Örneğin: birincil bir iş akışı (üç rakip akış değil), sadece birkaç seçenekle bir varsayılan yol, kullanıcı istemedikçe bildirim yok ve gerekli olana kadar ileri düzey yapılandırma yok.\n\nEn zor kısım takastır: bilinçli olarak neyi desteklemeyeceksiniz (şimdilik). Belki “istek oluştur ve onayla”yı desteklersiniz ama “özel onay zincirleri” değil. Belki “bir projeyi takip et”i desteklersiniz ama “portföy panelleri”ni değil. Bunlar sonsuza dek hayır demek değildir. “Henüz değil, çünkü odak kazanır.” demektir.\n\nBasit bir dürüstlük kontrolü: yepyeni bir kullanıcı 10 dakikada başarılı olabilir mi? Bir yürütme, ayarlar turu veya üç seçenek gerekiyorsa, kısıtlarınız çok gevşek. İlk kazanımı hızlı, net ve tekrarlanabilir olana dek kapsamı sıkılaştırın.\n\n## Yapılacak en küçük işe odaklanarak başlayın\n\nBir ürünü sakin tutmanın en hızlı yolu, kullanıcıyı işe almak için adlandırılmış tek bir işi seçmektir. “Daha üretken olmak” gibi belirsiz bir sonuç değil; sıkça ortaya çıkan, tek tek tekrarlanabilir bir görev.\n\nBir kullanıcı tipi ve bir durum seçin. “Küçük işletme sahipleri” hâlâ çok geniştir. “Müşteriler arasında, telefonda olan bir kafe sahibi” tasarım için yeterince spesifiktir. Açık bir bağlam, özellikler üzerinde doğal sınırlar oluşturur.\n\nBaşarıyı bir cümleyle tanımlayın, mümkünse bir sayıyla. Örneğin: “Bir destek lideri, 20 karışık sohbet mesajını 10 dakikadan kısa sürede tek sayfalık bir özet haline getirebilir.” Ölçemiyorsanız, uygulamanın yardımcı olup olmadığını anlayamazsınız.\n\nSonra ilk değer anını seçin: kullanıcının kazandığını hissettiği en erken nokta. Bu dakika içinde olmalı, günler içinde değil. Kısıt odaklı tasarımda o ilk zafer bağlayıcınızdır. Diğer her şey bekler.\n\nTek bir sayfada yakalamak isterseniz, basit tutun:\n\n- Kullanıcı: tam olarak kim?\n- Bağlam: nerede ve ne zaman kullanacaklar?\n- İş: düz sözlerle ne yapılmasını istiyorlar?\n- Başarı: “işe yaradı” ne demek (zaman, sayı, hata oranı)?\n- İlk zafer: ilk olarak ne olur ki bu faydalı hissettirir?\n\nSon olarak bir non-goals listesi yazın. Bu karamsarlık değil; korumadır. Destek-özet uygulaması için non-goals takım izinleri, özel panolar ve tam bir CRM olabilir.\n\nAI anında özellikler oluşturabildiğinde bu adım daha da önem kazanır. “Sadece bir şey daha” sakin araçların kontrol panellerine dönüşmesinin yoludur.\n\n## İşi minimum sevilebilir iş akışına dönüştürün\n\nİşi bildikten sonra, birisinin düşünmeden bitirebileceği küçük, tekrarlanabilir bir sıraya dönüştürün. İşte kısıtların gerçek olduğu yer: yolu kasıtlı olarak sınırlarsınız ki ürün dengeli hissetsin.\n\nİş akışını basit fiillerle adlandırın. Beş adım içinde tarif edilemiyorsa ya birden fazla işi karıştırıyorsunuz ya da işi henüz anlamıyorsunuz.\n\nYararlı bir desen:\n\n- Yakala: kullanıcının üzerinde çalıştığı şey\n- Seç: küçük, net bir seçenek (ayrıntılı ayarlar değil)\n- Üret: taslak veya sonuç\n- Gözden geçir: hızlı düzenlemeler, hızlı karar\n- Dışa aktar: kaydet, paylaş veya gönder\n\nSonra neyin vazgeçilmez neyin isteğe bağlı olduğunu ayırın. Vazgeçilmez adımlar çoğu kullanıcı için her seferinde gerçekleşir. İsteğe bağlı adımlar, çekirdek döngüyü bozmadan sonra ekleyebileceğiniz ekstralardır. Yaygın bir hata, temalar, entegrasyonlar, panolar gibi etkileyici görünen isteğe bağlı adımları önce göndermektir; temel döngü hâlâ sallantıda iken.\n\nSadece uç durumlar için var olan adımları kesin. Bir müşteri için 12 onay aşaması gereken bir sürümü bir numaralı sürüm olarak tasarlamayın. Normal durumu iyi yönetin, sonra kaçış yolları ekleyin: elle bir müdahale veya tek bir serbest metin alanı gibi.\n\nAyrıca uygulamanın neyi hatırlaması gerektiğine karar verin ki kullanıcılar bir sonraki sefer daha az iş yapsın. Tekrar çabayı azaltacak birkaç şeyle sınırlayın: son seçilen çıktı formatı, kısa bir stil tercihi, sık kullanılan girdiler (şirket adı, ürün isimleri) ve varsayılan dışa aktarma hedefi.\n\nSon olarak, her adımın kullanıcının saklayabileceği veya paylaşabileceği bir şey üretmesini sağlayın. Bir adım gerçek bir çıktı üretmiyorsa, neden var olduğunu sorgulayın.\n\n## Uygulamaları küçük tutan bir kapsam yöntemi\n\nKısıt odaklı ürün tasarımı, bulanık bir fikri sıkı, test edilebilir bir iş parçasına dönüştürebildiğinizde en iyi çalışır. Bu yaklaşım, AI ile üretilen kod kapsamı ucuz hissettirmeden önce açıklık zorunlu kılar.\n\n### 1 sayfalık kapsam döngüsü\n\nHer şeyi gerçeklikle temellendirerek başlayın. İnsanların bugün nasıl yaptığını gösteren birkaç gerçek girdi toplayın: ekran görüntüleri, dağınık notlar, örnek dosyalar veya hatta bir kağıt kontrol listesinin fotoğrafı. Gerçek girdiler bulamıyorsanız muhtemelen işi henüz anlamıyorsunuz demektir.\n\nSonra kısa bir döngü çalıştırın:\n\n- Girdileri yakala: işi gösteren 3 ila 10 gerçek örnek toplayın.\n- 1 sayfalık kapsam yazın: kullanıcıyı, işi, iş akışının başlangıç ve bitişini ve başarıyı kanıtlayan kesin çıktıyı adlandırın.\n- Veri modelini insan diliyle tanımlayın: uygulamanın bildiği 3–5 “şeyi” seçin (Müşteri, İstek, Durum, Not). 12 nesne gerekiyorsa bir suite inşa ediyorsunuz demektir.\n- 3 ana ekran taslağı çizin: işi başlat, işi yap, sonucu gözden geçir.\n- 1 boş durum ekleyin: henüz hiçbir şey olmadığında uygulamanın ne göstereceğine karar verin.\n\nBir “kasıtlı olarak manuel” karar verin: şu anda otomatikleştirmeyeceğiniz en az bir bölümü seçin (içe aktarma, bildirimler, roller, analitik). Yazın. Bu sizin sınırınızdır.\n\nİnce bir versiyon oluşturun, üç gerçek kullanıcı ile test edin ve tekrar kesin. Yalnızca şu soruyu sorun: işi daha hızlı mı bitirdiler, daha az hata mı yaptılar ve gelecek hafta tekrar kullanırlar mıydı? Değilse, minimum sevilebilir iş akışı bariz olana dek özellikleri kaldırın.\n\n## Sakin, tekrarlanabilir kullanım için tasarım taktikleri\n\nBir ürün, kullanıcı için daha az seçenek sunduğunda sakin hisseder. Amaç, 200. güne değil, 2. güne de anlaşılır kalan küçük bir yüzey alanıdır.\n\nVarsayılanları gerçek bir tasarım işi olarak ele alın. En yaygın, en güvenli seçeneği seçin ve gerektiğinde açıklayın. Kullanıcının nadiren değiştirmesi gereken bir şeyse, bunu bir ayar haline getirmeyin.\n\nUygulamayı şu birincil görünüm etrafında sabitleyin: “Bir sonraki ne yapmalıyım?” sorusuna cevap versin. İkinci bir görünüm gerekirse, açıkça ikincil yapın (geçmiş, detaylar, makbuzlar). Daha fazla görünüm genellikle daha fazla gezinme ve daha az dönüş anlamına gelir.\n\nBildirimler “yardımcı” olmaktan gürültüye dönüşür. Varsayılan olarak sessiz kalın. Bir şey engellendiğinde ancak o zaman kesintiye gidin ve sürekli bildirimler yerine özetleri tercih edin.\n\nİlk kullanım için değil, dönen kullanım için tasarlayın. İlk açılış merak unsurudur. İkinci ve üçüncü açılış güven oluşturur.\n\nHızlı bir kontrol: “ikinci sefer” yolunu yazın. Birisi uygulamayı açıp bir belirgin sonraki adımı görüp bir dakika içinde bitirebiliyor ve başka bir şeyin dikkat gerektirmediğini hissedebiliyor mu?\n\nMikro metin kararları azaltmalı. “Gönder” gibi belirsiz etiketlerin yerine “Daha sonra kaydet” veya “Müşteriye gönder” gibi net ifadeler kullanın. Bir eylemden sonra ne olacağını düz ve anlaşılır biçimde söyleyin.\n\n## AI'ı kapsam patlamasına izin vermeden kullanmanın yolu\n\nAI, “sadece bir şey daha” eklemeyi kolaylaştırır çünkü modeller ekran, metin ve mantığı hızlı üretebilir. Çözüm AI'dan kaçınmak değil; sınırlar koymaktır: modelin sıkıcı kısımlarını yaptırırken önemli kararlar ve ürün sınırları sende kalsın.\n\nZaman kaybettiren ama yargı gerektirmeyen bir yerle başlayın. İyi hedefler taslak oluşturma, özetleme, biçimlendirme ve dağınık girdileri temiz bir ilk taslağa dönüştürme gibi işlerdir. Kararı kullanıcının elinde bırakın: ne gönderilecek, ne kaydedilecek, ne yok sayılacak.\n\nAI çıktısını tasmalı tutun. Açık uçlu sihir istemeyin; iş akışına uyan sabit bir format isteyin: “3 konu başlığı, 1 paragraf özet ve 5 maddelik eylem listesi” gibi. Tahmin edilebilir şablonlar güvenilmesi ve düzenlenmesi daha kolaydır.\n\nKapsam kaymasını önlemek için her AI adımını net bir kullanıcı eylemiyle bitirin: onayla ve gönder, onayla ve kaydet, düzenle ve yeniden dene, arşivle veya elle yap.\n\nKullanıcılar sonra geri döndüğünde izlenebilirlik önemlidir. Oluşturulan çıktının neden böyle göründüğünü anlamak ve tahmin etmeden düzeltmek için kaynakları (notlar, e-postalar, form girdileri) üretilen çıktı ile birlikte saklayın.\n\n## Ürünleri ağırlaştıran yaygın hatalar\n\nAğır ürünler genellikle iyi niyetle başlar. Kullanıcıları yardımcı olmak için “bir şey daha” eklersiniz; ancak ana yol daha zor görülür, tamamlamak daha zor olur ve tekrar etmek daha zor hale gelir.\n\nKlasik bir tuzak, iş akışı çalışmadan önce pano oluşturmaktır. Panolar ilerleme gibi görünür ama genellikle ürününüzün kolaylaştırmadığı işleri özetler. Kullanıcı temel işi birkaç temiz adımda tamamlayamıyorsa, grafikler ve etkinlik akışları süs haline gelir.\n\nBaşka bir ağırlık artışı rol ve izinlerin çok erken eklenmesinden gelir. “Admin vs üye” ve onay zincirleri eklemek sorumlu gibi görünür ama her ekran ve eylem ekstra sorularla uğraşmak zorunda kalır. Erken ürünlerin çoğu bir sahibi ve basit bir paylaşım adımıyla idare eder.\n\nKenar durumlar da dikkati çalar. Yüzde 3 senaryosu için günler harcadığınızda, yüzde 97 yolu kaba kalır. Kullanıcılar bunu titizlik değil sürtünme olarak deneyimler.\n\nAyarlar “iyi olur”u zorunlu hâle getiren sinsi bir yoldur. Her toggle iki dünyayı desteklemenizi gerektirir. Yeterince toggle eklerseniz ürün bir kontrol paneline dönüşür.\n\nÜrününüzün ağırlaşmakta olduğunu gösteren beş uyarı işareti:\n\n- İnsanlar “Nereden başlamalıyım?” diye soruyor, “X'i de yapabilir mi?” yerine\n- Ana ekranı geliştirmek yerine sayfalar daha hızlı ekleniyor\n- Yeni özellikler güvenli olması için yeni ayarlar gerektiriyor\n- İlk görevi tamamlamak için uzun bir onboarding gerekiyor\n- “Takım desteği” kullanıcılar temel işi tek başına bitirmeden önce geliyor\n\n## Yeni bir özelliği inşa etmeden önce hızlı kontrol listesi\n\nYeni bir özellik toplantıda küçük gelebilir. Ayarlar, izinler, onboarding, destek ve kenar durumlar dokunduğunda nadiren küçük kalır. Bir şey eklemeden önce sorun: bu ürünü sakinleştirir mi yoksa ağırlaştırır mı?\n\nKontrolü kısa tutun:\n\n- İlk kez gelen bir kullanıcı rehber okumadan ana görevi yaklaşık beş dakikada tamamlayabiliyor mu?\n- İlk ekranda belirgin bir varsayılan eylem var mı?\n- Çekirdek iş akışı üç ana ekrana veya daha azına sığabilir mi?\n- Ürünü özellikleri listelemeden bir cümlede açıklayabilir misiniz?\n- Özelliği kaldırırsanız uygulama daha mı net olur?\n\nEğer duygu, threadler ve dosya paylaşımı ilk durum güncellemesini uzatıyorsa, yeni iş ana göreve yardımcı olmuyordur.\n\nKısıt odaklı ürün tasarımı ucuz veya tembel olmakla ilgili değildir. İnsanların her gün tekrarlayacağı en küçük iş akışını korumakla ilgilidir; çünkü o iş akışı hızlı, açık ve güvenilir kalır.\n\n## Örnek: insanların geri döndüğü küçük bir uygulamanın kapsamı\n\nKüçük bir operasyon ekibini hayal edin: haftalık tedarikçi durum güncellemelerini yönetime gönderiyorlar. Bugün bu dağınık bir zincir: sohbet notları, biri bir dokümana kopyalıyor, bir yönetici yeniden yazıyor ve e-posta geç gidiyor.\n\nKısıt odaklı yaklaşım tek bir tekrarlanabilir zafer ister: haftalık güncellemeyi kolayca üretmek, onaylamak ve sonra bulmak. Başka hiçbir şey.\n\n### Kendini amorti eden en küçük iş akışı\n\nUygulamayı haftada bir gerçekleşen tek bir döngüye odaklayın: her tedarikçi için kısa notlar topla (bir metin kutusu ve basit bir durum), her seferinde aynı yapıda temiz bir taslak üret, bir tıklamayla onayla ve isteğe bağlı düzenlemeler yap, sabit bir listeye gönder ve bir kopya kaydet, sonra haftaya göre arşivle ki aranabilir olsun.\n\nEkip bunu 45 yerine 10 dakikada yapabiliyorsa, gelecek hafta geri döneceklerdir.\n\n### Neyi kestiğiniz (kasıtlı olarak)\n\nKapsam disiplini, atladığınız şeylerde görünür: panolar, derin analitik, karmaşık entegrasyonlar, karmaşık roller, özel rapor oluşturucular ve bitmek bilmeyen şablonlar. Ayrıca küçük bir CRM'e dönüşebilecek “faydalı” tedarikçi profillerinden kaçınırsınız.\n\n### Tekrarlanabilir değer nasıl görünür\n\nÇıktı öngörülebilir, ritim sabit ve çaba azalır. Uygulama her hafta aynı işi sürpriz olmadan yaptığı için güven kazanır.\n\nLansmandan sonra birkaç basit sinyal ölçün: tamamlama oranı (güncelleme gönderildi mi), ilk nottan gönderilen e-postaya kadar geçen süre ve taslak başına yapılan düzenleme sayısı (insanlar her şeyi yeniden mi yazıyor yoksa sadece cilalıyor mu). Düzenlemeler yüksekse, özellik listesini değil yapı ve istemleri sıkılaştırın.\n\n## Sonraki adımlar: en küçük iş akışını gönderin ve sakince yineleyin\n\nBugün bir sayfalık kapsam dokümanı yazın. Basit ve spesifik tutun ki yarın suçluluk duymadan “hayır” diyebilesiniz. Tekrarlanabilir değer yaratan en küçük iş akışını koruyun.\n\nDört parça ekleyin: iş (kullanıcının tek oturumda yapılmasını istediği şey), minimum sevilebilir iş akışı (başından sonuna çalışması gereken birkaç adım), çıktılar (kullanıcının yanından neler alacağı) ve non-goals (şimdilik ne inşa edilmeyecek).\n\nSonra 1–2 hafta içinde bir iş akışı gönderin. Bir platform değil. Gerçek bir kişinin sizin odada olmadan iki kez kullanabileceği bir akış.\n\nİlk kullanıcı testinden sonra bir kes-listesi incelemesi yapın: kimsenin dokunmadığı neydi, insanları ne bayağı şaşırttı ve değer ortaya çıkmadan önce hangi parçalar iş gibi hissettirdi? Yeni bir şey eklemeden önce bu parçaları kaldırın veya gizleyin.\n\nEğer bir sohbet tabanlı platformla inşa ediyorsanız, örneğin Koder.ai (koder.ai), kısıtları görünür tutun. Planning Mode'u kullanarak iş akışını ve non-goals'u kilitleyin, sonra üretmeden önce plana sadık kalın; snapshot ve rollback ile değişiklikleri güvenle geri alın.
