Bu durumlar neden hızla karışır\n\nYükleme, hata ve boş durumlar, uygulama beklerken, bir şey başarısız olduğunda veya gösterilecek hiçbir şey olmadığında görülen ekranlar (veya küçük UI blokları)dır. Bunlar normaldir: ağlar yavaş olabilir, izinler reddedilebilir ve yeni hesaplar sıfır veriyle başlar.\n\nKarışmalarının nedeni genellikle sonradan ve hızlı eklenmeleridir. Takımlar önce mutlu yolu (happy path) inşa eder, sonra spinner, kırmızı bir mesaj ve UI bozulduğunda her yere bir “öğe yok” yerleştirir. Bu onlarca ekran boyunca yapılırsa ortaya bir dizi teferruat çözüm çıkar.\n\nHızlı yineleme durumu daha da kötüleştirir. UI hızlı üretilirken (AI tarafından oluşturulan UI dahil), ana düzen dakikalar içinde görünebilir ama bu durumları atlamak kolaydır. Her yeni ekran farklı bir spinner stili, farklı ifadeler (“Tekrar Dene” vs “Retry”) ve farklı düğme yerleşimiyle gelir. İlk kazandığınız hız, lansmana yakın bir zamanda cilalama işine dönüşür.\n\nUyumsuz durumlar kullanıcıyı kafa karıştırır ve takımlara zaman kaybettirir. İnsanlar boş bir listenin “sonuç yok”, “henüz yüklenmedi” veya “erişiminiz yok” anlamına gelip gelmediğini anlayamaz. QA küçük varyasyonların uzun listesini test etmek zorunda kalır ve hatalar web ile mobil arasında davranış farkı olduğu için gözden kaçar.\n\n“Karışık” genellikle şöyle görünür:\n\n- Yükleme bir ekranda eylemleri gizlerken diğerinde gizlemiyor.\n- Hatalar bazen sayfayı bloke eder, bazen küçük bir metin olarak görünür.\n- Boş durumlar farklı ton, ikon ve sonraki adımlar kullanır.\n- Web ve mobil aynı eylem için farklı etiketler kullanır.\n\nHedef basit: web ve mobil arasında paylaşılan bir yaklaşım. Eğer takımınız özellikleri hızlı üretiyorsa (örneğin Koder.ai gibi bir platform kullanarak), paylaşılan bir durum deseni her yeni ekranın varsayılan olarak tutarlı başlamasını sağlar.\n\n## Öncelikle standartlaştırılmaya değer 5 durum türü\n\nÇoğu uygulama aynı baskı noktalarını tekrarlar: listeler, detay sayfaları, formlar, panolar. Burada spinner'lar, banner'lar ve “hiçbir şey yok” mesajları çoğalır.\n\nÖnce beş durum türünü adlandırıp standartlaştırın:\n\n- İlk yükleme: bir ekran ilk açıldığında, henüz hiçbir veriniz yokken.\n- Yenileme / güncelleme: ekranın zaten verisi var ama daha yeni veriler çekiyorsunuz.\n- Temel boş durum: gerçekten henüz hiçbir şey yok (yeni hesap, yeni çalışma alanı, oluşturulmuş öğe yok).\n- Sıfır sonuç: veri var ama filtreler veya arama hiç sonuç döndürmüyor.\n- Hata: istekler başarısız oluyor, izinler erişimi engelliyor veya bir şey bozuldu.\n\nİki özel durum kendi kurallarını hak eder çünkü farklı davranırlar:\n\n- Çevrimdışı: mümkünse önbelleğe alınmış içeriği gösterin ve açıkça “Çevrimdışısınız” deyin.\n- Yavaş ağ: hızlı hata flaşlarından kaçının; kısa bir gecikmeden sonra “Hala yükleniyor…” tarzı bir mesaja geçin.\n\nEkranlar ve platformlar arasında yapıyı tutarlı tutun: durumun nerede göründüğü, ikon stili, ton ve varsayılan eylemler (Tekrar Dene, Yenile, Filtreleri Temizle, Oluştur) aynı olsun. Değişebilecek şey bağlamdır: ekran adı ve kullanıcının sözlerini kullanan bir cümle.\n\nÖrnek: hem web hem mobil için “Projeler” listesi üretiyorsanız, aynı sıfır-sonuç desenini paylaşmalıdırlar. Eylem etiketi platforma uyacak şekilde değişebilir (“Filtreleri Temizle” vs “Sıfırla”).\n\n## Tekil çözümler yerine küçük bir durum kiti oluşturun\n\nHer ekran kendi spinner'ını, hata kartını ve boş mesajını icat ederse, sonunda bir düzine hafif farklı versiyon olur. En hızlı çözüm, herhangi bir özelliğin kolayca ekleyebileceği küçük bir “state kit”tir.\n\nHer yerde çalışan üç yeniden kullanılabilir bileşenle başlayın: Loading, Error ve Empty. Bilerek sıkıcı yapın. Kolay tanınır olmalı ve ana UI ile rekabet etmemeli.\n\nBileşenleri öngörülebilir kılmak için küçük bir girdi seti tanımlayın:\n\n- Başlık (kısa ve spesifik)\n- Mesaj (bir veya iki cümle)\n- Birincil eylem etiketi\n- Birincil eylem yöneticisi (retry, refresh veya sonraki adım)\n- İsteğe bağlı ayrıntılar (hata kodu, ikincil eylem)\n\nSonra görünümü kilitleyin. Boşluk, tipografi, ikon boyutu ve düğme stilinde bir kez karar verin ve bunu bir kural gibi ele alın. İkon boyutu ve düğme tipi aynı kaldığında, kullanıcılar durum UI'sını fark etmeyi bırakır ve ona güvenmeye başlar.\n\nVaryantları sınırlı tutun ki kit ikinci bir tasarım sistemine dönüşmesin. Üç boyut genellikle yeterlidir: küçük (satır içi), varsayılan (bölüm) ve tam sayfa (engelleyici).\n\nEğer ekranları Koder.ai içinde üretiyorsanız, “yükleme/hata/boş için app StateKit'i kullan ve varsayılan varyantı uygula” gibi basit bir talimat sürmeyi önler. Bu aynı zamanda React web ve Flutter mobil arasında son döngü temizliğini azaltır.\n\n## Tutarlı kalan durum metinleri yazın\n\nMetin sistemi parçasıdır, dekore edilen şey değil. Düzen tutarlı olsa bile rastgele ifadeler ekranları farklı hissettirebilir.\n\nPaylaşılan bir ses seçin: kısa, spesifik, sakin. Ne olduğunu sade bir dille söyleyin, sonra kullanıcıya bir sonraki adımı söyleyin. Çoğu ekran sadece bir net başlık, kısa bir açıklama ve açık bir eylem gerektirir.\n\n### Ekiplerin doğaçlama yapmasını engellemek için şablonlar kullanın\n\nBirkaç mesaj deseni çoğu durumu kapsar. Küçük ekranlara sığacak kadar kısa tutun:\n\n- Ağ: “Bağlantı kurulamadı” + “İnternetinizi kontrol edip tekrar deneyin.” + Eylem: “Tekrar Dene”\n- Zaman aşımı: “Beklenenden uzun sürüyor” + “İstek zaman aşımına uğradı.” + Eylem: “Tekrar Dene”\n- İzin: “İzin gerekli” + “Devam etmek için erişim verin.” + Eylem: “Ayarları Aç”\n- Bulunamadı: “Burada hiçbir şey yok” + “Bu öğe kaldırılmış olabilir.” + Eylem: “Geri”\n- Doğrulama: “Bir şeyi düzeltin” + “Geçerli bir e-posta adresi ekleyin.” + Eylem: “Kaydet”\n\nTek başına “Bir şeyler yanlış gitti” gibi belirsiz metinlerden kaçının. Gerçekten nedeni bilmiyorsanız, bildiklerinizi ve kullanıcının şimdi ne yapabileceğini söyleyin. “Projeleriniz yüklenemedi” demek “Hata” demekten daha iyidir.\n\n### Sonraki eylemi öngörülebilir yapın\n\nBir kural koyun: her hata ve boş durum bir sonraki adımı sunsun.\n\n- Kullanıcı kurtarabiliyorsa, “Tekrar Dene” veya “Yenile” sunun.\n- Boşluk filtrelerden kaynaklanıyorsa, “Filtreleri Temizle” önerin.\n- Kullanıcı engellenmişse (izin), tam olarak nereden değiştireceğini söyleyin.\n\nBu, ekranların hızlı göründüğü AI tarafından oluşturulmuş UI'da daha da önemlidir. Şablonlar kopyayı tutarlı tutar ki son cilalamada düzinelerce tekil mesajı yeniden yazmayın.\n\n## Eylemleri öngörülebilir yapın: tekrar dene, yenile ve sonraki adımlar\n\nDurum ekranları farklı sayfalarda farklı eylemler önerdiğinde kullanıcılar tereddüt eder. Takımlar sonra lansmandan hemen önce düğmeleri ve metinleri değiştirir.\n\nHangi eylemin her durumun ait olduğunu belirleyin ve yerleşim ile etiketi tutarlı tutun. Çoğu ekran bir birincil eyleme sahip olmalı. İkincil eklerseniz, ana yolun destekçisi olmalı, onunla rekabet etmemeli.\n\n### Ölçeklenen küçük bir eylem haritası\n\nİzin verilen eylemleri sıkı tutun:\n\n- Yükleme: genelde eylem yok (uzun, kullanıcı tarafından başlatılan görevlerde isteğe bağlı “İptal”).\n- Boş: kullanıcı bir şey ekleyebiliyorsa “Oluştur”; filtreler boşluğa neden olduysa “Filtreleri Ayarla”.\n- Hata: geçici hatalar için “Tekrar Dene”; eski veriler için “Yenile”; engellenmiş iş akışları için yalnızca “Destekle İletişime Geç” gibi seçenekler.\n- Başarı ama veri değişmedi: “Geri” veya “Tamam”.\n\nSıkıcı düğmeler bir özelliktir. Bu düğmeler UI'yı tanıdık yapar ve oluşturulan ekranların tutarlı kalmasına yardımcı olur.\n\n### Tekrar dene ve hata ayrıntıları kuralları\n\n“Tekrar Dene”yi yalnızca tekrarın gerçekçi şekilde işe yarayabileceği durumlarda gösterin (zaman aşımı, dalgalı ağ, 5xx). Tekrarlı dokunuşların istekleri spamlamaması için kısa bir debounce ekleyin ve yeniden denerken düğmeyi yükleme durumuna geçirin.\n\nTekrarlanan başarısızlıktan sonra, aynı birincil düğmeyi koruyun ve ikincil yardımı iyileştirin (ör. “Bağlantınızı kontrol edin” ipucu veya “Daha sonra tekrar deneyin”). Bir şey iki kez başarısız oldu diye tüm düzeni değiştirmekten kaçının.\n\nHata ayrıntıları için kullanıcıların hareket edebileceği sade nedenler gösterin (“Oturumunuz sona erdi. Yeniden giriş yapın.”). Teknik ayrıntıları varsayılan olarak gizleyin; gerekiyorsa tutarlı bir “Ayrıntılar” gösteriminde saklayın.\n\nÖrnek: bir “Projeler” listesi mobilde yüklenemez. Her iki platform da aynı birincil “Tekrar Dene” eylemini gösterir, tekrarlarken devre dışı bırakır ve iki başarısızlıktan sonra tüm düğme düzenini değiştirmek yerine küçük bir bağlantı ipucu ekler.\n\n## Takımları yavaşlatmadan sistemi kullanıma alın\n\nDurum tutarlılığını küçük bir ürün değişikliği olarak ele alın, yeniden tasarım gibi değil. Kademeli ilerleyin ve benimsemeyi kolaylaştırın.\n\nÖnce hızla elinizdekilerin anlık görüntüsünü alın. Mükemmellik hedeflemeyin. Yaygın varyasyonları yakalayın: skeleton vs spinner, tam sayfa hata vs banner, farklı tonlara sahip “sonuç yok” ekranları.\n\nPratik bir yayılma planı:\n\n- Web ve mobilde 15–30 kilit ekranın envanterini çıkarın ve en sık görülen desenleri gruplayın.\n- Önce destekleyeceğiniz 3–4 kanonik yerleşimi seçin (tam sayfa, bölüm, satır içi, toast).\n- Web ve mobil için aynı props ve adları paylaşan eşleşen bileşenler oluşturun.\n- Yeni ekranların kitten seçim yapması için kısa kullanım kuralları yazın.\n- Ürünün bir alanını birer birer değiştirin (arama, gelen kutusu, faturalama) ki sürümler güvenli kalsın.\n\nBileşenler hazır olduktan sonra gerçek zaman kazandıran kural seti, sayfanın tamamını mı yoksa sadece bir kartı mı engellediği ve hangi eylemlerin zorunlu olduğu gibi tartışmaları ortadan kaldırır.\n\nKuralları kısa tutun:\n\n- Her hata bir net sonraki adım gösterir (tekrar dene, yenile veya destekle iletişime geç).\n- Boş durumlar bir birincil eylem sunar (oluştur, içe aktar veya keşfet).\n- Yükleme durumları veri geldiğinde düzeni zıplatmaz.\n\nEğer bir AI UI üreteci kullanıyorsanız (Koder.ai gibi), bu kurallar hızlı geri dönüş sağlar. “State kit bileşenlerini kullan” diye istemde bulunursanız, React web ve Flutter mobilde sisteminize uyan ekranlar daha az temizleme gerektirir.\n\n## Geç kalan cilalama işine yol açan yaygın hatalar\n\nGeç kalan cilalama genelde durum yönetiminin tekil çözümler halinde oluşturulmasından kaynaklanır. Bir ekran “çalışır”, ama deneyim her seferinde farklı hissettirir.\n\n### Sıkışmış gibi hissettiren yükleme\n\nSkeleton'lar yardımcıdır, ama onları çok uzun süre ekranda bırakmak insanların uygulamanın donduğunu düşünmesine neden olur. Yaygın bir neden, sinyal olmayan yavaş bir çağrıda tam bir skeleton göstermek.\n\nZaman kutusu koyun: kısa bir gecikmeden sonra daha hafif bir “Hala yükleniyor…” mesajına geçin veya mümkünse ilerleme gösterin.\n\n### Ekranlar arası metin kayması\n\nTakımlar genellikle durumu her seferinde yeni bir metin yazarak çözer. “Bir şeyler yanlış gitti”, “Alınamadı” ve “Ağ hatası” aynı durumu tanımlıyor olabilir ama tutarsız görünür ve desteği zorlaştırır.\n\nHer hata türü için bir etiket seçin ve web ile mobilde aynı ton ve ayrıntı düzeyiyle tekrar kullanın.\n\n### Boş vs hata vs henüz yüklenmedi ayrımı\n\nBaşka klasik hata, veri bitmeden önce boş durumu göstermek veya gerçek sorun başarısız bir istekken “Öğe yok” göstermek. Kullanıcı yanlış eylemi yapar (ör. içerik eklemek yerine tekrar denemelidir).\n\nKarar sırasını açık hale getirin: önce yükleme, sonra başarısızsa hata, ve istek başarılı olup veri yoksa boş.\n\n### Eksik veya aşırı yüklü eylemler\n\nBir hatada kurtarma eylemi yoksa çıkmaz oluşturur. Tersi de yaygındır: dikkat çeken üç düğme.\n\nSıkı tutun:\n\n- Hatalar için varsayılan bir birincil eylem (genelde “Tekrar Dene”).\n- Boş durumlar için bir net sonraki adım.\n- İkincil eylemleri gerçekten gerekliyse kullanın.\n\n### Platformlar arası görsel uyumsuzluklar\n\nKüçük farklılıklar birikir: ikon stilleri, padding, düğme şekilleri. AI tarafından üretilen UI, istemler ekrandan ekrana değişirse buradan sapabilir.\n\nDurum bileşenleri için boşluk, ikon seti ve düzeni kilitleyin ki her yeni ekran aynı yapıyı miras alsın.\n\n## Yükleme davranışı ve erişilebilirlik için pratik kurallar\n\nWeb ve mobil arasında tutarlı durum yönetimi istiyorsanız “sıkıcı” kuralları açık hale getirin. Geç kalan cilalamanın çoğu her ekranın kendi yükleme davranışını, zaman aşımını ve etiketleri icat etmesinden kaynaklanır.\n\n### Hızlı hisseden yükleme kuralları (gerçekte yavaş olsa bile)\n\nTam sayfa yüklemeleri için bir varsayılan seçin: içerik ağırlıklı ekranlar (listeler, kartlar, panolar) için skeleton, düzen bilinmiyorsa kısa beklemeler için spinner.\n\nUI'nın sessizce takılıp kalmaması için bir zaman aşımı eşiği ekleyin. Yükleme yaklaşık 8–10 saniyeyi geçerse, net bir mesaja ve görünür bir eyleme (“Tekrar Dene”) geçin.\n\nKısmi yüklemelerde ekranı boş bırakmayın. Mevcut içeriği görünür tutun ve güncellenen bölümün yakınında küçük bir ilerleme göstergesi gösterin (ör. başlıkta ince bir bar veya satır içi spinner).\n\nÖnbelleğe alınmış veriler için “eskimiş ama kullanılabilir” tercih edin. Önbelleğe alınmış içeriği hemen gösterin ve veri değişebileceğini belirtmek için ince bir “Yenileniyor…” göstergesi ekleyin.\n\nÇevrimdışı kendi başına bir durumdur. Açıkça söyleyin ve nelerin hâlâ çalıştığını belirtin. Örnek: “Çevrimdışısınız. Kaydedilmiş projeleri görüntüleyebilirsiniz, ancak senkronizasyon duraklatıldı.” Tek bir sonraki adım sunun: “Tekrar Dene” veya “Kaydedilmişleri Aç”.\n\n### Her yerde uygulayabileceğiniz erişilebilirlik temelleri\n\nBunları platformlar arasında tutarlı tutun:\n\n- Odak sırası: durum görünce odağı mesaj ve birincil eyleme kaydırın.\n- Ekran okuyucu etiketleri: yükleme ve hataları kısa, net metinle duyurun.\n- Dokunma hedefleri: mobilde düğmeleri kolay vurulabilir yapın, küçük satır içi linklerden kaçının.\n- Hareket: spinner'ları hafif tutun ve yalnızca animasyona güvenmeyin.\n- Renk: durumu sadece renkle iletmeyin; metin ve ikonla destekleyin.\n\nKoder.ai gibi bir araçla UI üretiyorsanız, bu kuralları paylaşılan bir state kit'e yerleştirmek her yeni ekranın varsayılan olarak tutarlı olmasını sağlar.\n\n## Örnek: bir özellik, üç durum, iki platform\n\nBasit bir CRM'de Contacts listesi ve Contact detay sayfasını hayal edin. Yükleme, hata ve boş durumları tekil çözümler olarak ele alırsanız web ve mobil hızla farklılaşır. Küçük bir sistem, UI hızla üretilse bile her şeyi hizalı tutar.\n\nİlk kez boş durum (Contacts listesi): kullanıcı Contacts'i açar ve henüz hiçbir şey yok. Hem web hem mobilde başlık aynı kalır (“Contacts”), boş mesaj nedenini açıklar (“Henüz kişi yok”) ve bir net sonraki adım sunulur (“İlk kişi ekle”). Kurulum gerekiyorsa (ör. bir posta kutusu bağlama veya CSV içe aktarma), boş durum tam olarak o adıma işaret eder.\n\nYavaş ağ yüklemesi: kullanıcı Contact detay sayfasını açar. Her iki platform da son sayfa yapısıyla eşleşen öngörülebilir bir skeleton düzeni gösterir (başlık, ana alanlar, notlar). Geri düğmesi çalışmaya devam eder, sayfa başlığı görünür ve farklı yerlere rastgele spinner koymaktan kaçınırsınız.\n\nSunucu hatası: detay isteği başarısız olur. Web ve mobilde aynı desen: kısa bir başlık, bir cümle ve birincil eylem (“Tekrar Dene”). Tekrar deneme başarısız olursa, kullanıcıyı takılı bırakmamak için “Contacts'a geri dön” gibi ikinci bir seçenek sunun.\n\nSabit kalanlar basit: mesajın içerikteki yeri, eylemlerin bariz bir noktada olması, metnin aynı tonu ve düğme etiketleri (Tekrar Dene, Kişi Ekle) ve yükleme tetiklerinin aynı kuralları. Ayrıca kopya yüklemeler sırasında çoğaltılmayı engeller.\n\n## Yayınlamadan önce hızlı kontrol listesi\n\nBir sürüm “tamam” gibi görünebilir ama birisi yavaş bağlantı, yeni hesap veya dalgalı API ile karşılaştığında fark edilir. Bu kontrol listesi son adım boşluklarını bulmanıza yardımcı olur.\n\n### UI tutarlılık kontrolleri\n\nÖncelikle liste ekranlarıyla başlayın, çünkü bunlar çoğalır. Üç ortak liste seçin (arama sonuçları, kaydedilmiş öğeler, son etkinlik) ve hepsinin aynı boş durum yapısını kullandığından emin olun: net bir başlık, bir yardımcı cümle ve bir birincil eylem.\n\nBoş durumların veri hâlâ yüklenirken asla görünmediğinden emin olun. Eğer “Burada hiçbir şey yok” kısa bir anlık görünme yapıp sonra içerikle değişiyorsa, güven hızla düşer.\n\nYükleme göstergelerini tutarlı kontrol edin: boyut, yerleşim ve mantıklı bir minimum süre ki titreşmesinler. Eğer web üstte bir bar spinner gösterirken mobil aynı ekranda tam sayfa skeleton gösteriyorsa, iki farklı ürün hissi verir.\n\n### Hata ve QA kontrolleri\n\nHatalar her zaman “şimdi ne yapmalı?” sorusuna cevap vermeli. Her hata ekranında bir sonraki adım olmalı: tekrar dene, yenile, filtreleri değiştir, yeniden giriş yap veya destekle iletişime geç.\n\nYayın işaretini vermeden önce kısa bir kontrol turu:\n\n- Boş durumlar: liste ekranlarında aynı düzen, ikon stili ve ton.\n- Yükleme: boş durum çok erken gösterilmesin; göstergeler web ve mobilde eşleşsin.\n- Hatalar: her hata ekranında bir net birincil eylem veya toast.\n- Metin kuralları: platformlar arasında başlık, noktalama ve düğme fiil kullanımında tutarlılık.\n- QA senaryosu: yükleme, boş ve hata durumlarını tetikleyen kısa, tekrarlanabilir adımlar.\n\nEğer Koder.ai gibi bir AI oluşturucu kullanıyorsanız, bu kontroller daha da önemli çünkü ekranlar hızlı üretilir ama tutarlılık hâlâ paylaşılan kit ve kopya kurallarına bağlıdır.\n\n## Uygulama büyüdükçe tutarlılığı korumak için sonraki adımlar\n\nTutarlılık günlük işe dahil olduğunda en kolaydır, tek seferlik bir temizlik değil. Her yeni ekran aynı kalıpları otomatik kullanmalı; “uyuşması için hatırlatma” gerekmemeli.\n\nDurum davranışını bitiş tanımınızın parçası yapın. Bir ekran, yükleme durumu, boş durum (uygunsa) ve açık bir eylemi olan bir hata durumu olmadan tamamlanmış sayılmasın.\n\nKuralları hafif tutun ama yazılı hale getirin. Birkaç ekran görüntüsü ve istediğiniz kesin kopya kalıpları içeren kısa bir doküman genellikle yeterlidir. Yeni varyantları istisna olarak ele alın. Birisi yeni bir durum tasarımı önerdiğinde, bunun gerçekten yeni bir durum mu yoksa kitle uyuyor mu diye sorun.\n\nBirçok ekranı yeniden düzenliyorsanız riski azaltmak için kontrollü adımlarla ilerleyin: bir akışı güncelleyin, web ve mobilde doğrulayın, sonra devam edin. Koder.ai'de snapshot ve geri alma büyük değişiklikleri daha güvenli hale getirebilir; planning mode ise paylaşılan state kit'in tanımlanmasına yardımcı olur ki yeni oluşturulan ekranlar baştan varsayılanlarınıza uysun.\n\n### İlerlemenin somut bir yolu\n\nBu hafta durum sorunlarının gecikmeyle düzeltilmesine yol açtığı bir alan seçin (çoğunlukla arama sonuçları, onboarding veya etkinlik akışı olur). Sonra:\n\n- O alana kabul kontrol listesine durum gereksinimleri ekleyin.\n- Tekil durumları paylaşılan bileşenlerle değiştirin.\n- Dokümana 2–3 örnek (iyi ve kötü) kaydedin.\n- Hızlı bir çapraz platform incelemesi yapın (aynı anlam, aynı eylemler, benzer düzen).\n- Bir sonraki sprintte kaç tane UI cilalama bileti açtığınızı takip edin ve karşılaştırın.\n\nİşlerin yolunda gittiğinin somut işareti: “tekrar dene ekle”, “boş durum garip görünüyor” veya “yükleme spinner'ı sayfayı engelliyor” gibi küçük bilet sayısının azalmasıdır.\n\n### Sahipliği net tutun\n\nDurum standartları için tek bir sahip atayın (tasarımcı, teknik lider veya her ikisi). Her şeyi onaylamaları gerekmez, ama kitin yavaş yavaş yeni varyantlara bölünmesini engellemeliler—benzer görünen ama farklı davranan ve sonradan zaman kaybettiren varyantlar.\n\n
