Yapay Zeka, Dağınık Fikirleri Ekranlara, Mantığa ve Akışlara Nasıl Dönüştürüyor
Yapay zekanın dağınık beyin fırtınalarını düzenleyip uygulama ekranları, kullanıcı akışları ve basit mantık taslaklarına nasıl dönüştürebileceğini öğrenin — fikrinizden net bir plana daha hızlı geçmenize yardımcı olur.
“Ekranlar, mantık ve akışlar” gerçekte ne demek\n\nİnsanlar “fikri ekranlara, mantığa ve akışlara dönüştür” dediğinde, ürün planını somutlaştırmanın birbirine bağlı üç yolunu anlatıyorlar.\n\n### Ekranlar: kullanıcının gördüğü şey\n\nEkranlar kullanıcının etkileştiği sayfalar veya görünümlerdir: bir kayıt sayfası, pano, ayarlar sayfası, “görev oluştur” formu. Bir ekran sadece başlıktan ibaret değildir—üzerinde ne olduğunu (alanlar, düğmeler, mesajlar) ve ne amaçla kullanıldığını (o ekranda kullanıcının niyeti) içerir.\n\n### Akışlar: bir hedefe giden yol\n\nAkışlar kullanıcının bir şeyi tamamlamak için ekranlar arasında nasıl ilerlediğini tarif eder. Akışları rehber bir rota olarak düşünün: önce ne oluyor, sonra ne oluyor ve kullanıcı nereye varıyor. Bir akış genelde bir “mutlu yol” (her şey sorunsuz gider) ve varyasyonlar (şifre unutuldu, hata durumu, geri dönen kullanıcı vb.) içerir.\n\n### Mantık: kurallar, kararlar ve sistem davranışı\n\nMantık ekran arkasında (çoğu zaman ekranda da açıklanan) sistemin karar verdiği veya zorunlu kıldığı her şeydir:\n\n- Kurallar (şifre gereksinimleri, plan sınırları)\n- Kararlar (kullanıcıyı onboarding’e yönlendir veya atla)\n- Durumlar (oturum açık vs kapalı, deneme vs ücretli)\n- Kenar durumlar (kopya e-posta, zayıf bağlantı, boş veri)\n\n### Ürün planında nasıl bir araya geliyorlar\n\nPratik bir ürün planı bu üçünü birbirine bağlar:\n\n- Ekranlar yapı taşlarını tanımlar.\n- Akışlar bu taşların kullanıcı hedeflerini gerçekleştirmek için nasıl bağlandığını tanımlar.\n- Mantık neyin izinli olduğunu, koşullara göre neyin değiştiğini ve işler beklendiği gibi gitmediğinde kullanıcıya ne gösterileceğini tanımlar.\n\nAI burada işe yarar çünkü dağınık notları (özellikler, istekler, kısıtlar) alıp bu üç katmanın ilk taslağını önerebilir—böylece siz üzerinde tepki verip, düzeltip, rafine edebilirsiniz.\n\n### Küçük örnek: kayıt → onboarding → ilk görev\n\nBasit bir görev uygulaması hayal edin:\n\n- Ekranlar: Kayıt, E-posta Doğrulama, Onboarding Soruları, İlk Görevi Oluştur, Görev Listesi.\n- Akış (mutlu yol): Kayıt → E-posta Doğrulama → Onboarding → İlk Görevi Oluştur → Görev Listesi.\n- Mantık: E-posta zaten kullanımdaysa “hesap mevcut” göster ve giriş seçeneği sun; doğrulama atlanırsa erişimi kısıtla; onboarding tamamlanmadıysa daha sonra hatırlat; ilk görev oluşturulduktan sonra onay durumu göster ve ardından Görev Listesini göster.\n\nBunun özeti: kullanıcıların ne gördüğü, nasıl ilerledikleri ve deneyimi hangi kuralların yönettiği.\n\n## Ham fikirlerin neden plana dönüşmeden takıldığı\n\nHam ürün fikirleri nadiren düzenli bir belge olarak gelir. Genelde dağınık parçalar halinde ulaşır: telefondaki notlar, uzun sohbet dizileri, toplantı notları, kağıt üzerindeki hızlı eskizler, ses kayıtları, destek talepleri ve son dakikada eklenen “bir şey daha” fikirleri. Her parça değerli olabilir, ama birlikte net bir plana dönüştürülmesi zordur.\n\n### Dağınık orta: tekrarlar, çelişkiler ve boşluklar\n\nHer şeyi bir araya getirdiğinizde desenler görünür—ve problemler de:\n\n- Aynı fikir beş farklı şekilde tanımlanmış (“kaydedilen öğeler ekle”, “istek listesi”, “favoriler”, “yer imi”).\n- Gereksinimler çelişiyor (“misafir ödeme” vs “güvenlik için giriş gerekli”).\n- Önemli adımlar eksik (“Ödeme başarısız olursa ne olur?” “Kullanıcı geçmiş faturaları nerede görür?”).\n\nBu sorunlar ekibin yanlış yaptığı anlamına gelmez. Farklı kişilerden, farklı zamanlarda, farklı varsayımlarla gelen girdilerde normaldir.\n\n### Belirsiz hedefler akışları karıştırır\n\n“Niçin” net değilse fikirler takılır. Hedef bulanıksa (“onboardingi iyileştir”), akış ekran karmasaya dönüşür: ekstra adımlar, isteğe bağlı sapmalar ve belirsiz karar noktaları.\n\nBunu şu hedefle karşılaştırın: “Yeni kullanıcının hesabını bağlamasına ve iki dakika içinde bir başarılı işlem gerçekleştirmesine yardımcı ol.” Şimdi ekip her adımı şu kriterle değerlendirebilir: bu adım kullanıcıyı o sonuca götürüyor mu yoksa sadece gürültü mü?\n\nNet hedefler yoksa ekipler ekranlar yerine sonuçlar üzerinde tartışır—ve akışlar birden fazla amaca hizmet etmeye çalışırken karmaşıklaşır.\n\n### Gizli maliyet: sonradan yeniden çalışma\n\nYapı eksikse kararlar ertelenir. Başta hızlı gelir (“tasarımda hallederiz”), ama acıyı genelde daha ileri taşır:\n\nBir tasarımcı tel çerçeveler oluşturur ve eksik durumları ortaya çıkarır. Geliştiriciler kenar durumları ister. QA çelişkiler bulur. Paydaşlar özelliğin ne yapması gerektiği konusunda anlaşamaz. Sonra herkes geri gider—mantığı yeniden yazar, ekranları tekrar yapar, yeniden test eder.\n\nYeniden çalışma pahalıdır çünkü birçok parça zaten bağlı hale gelmiştir.\n\n### “Daha fazla fikir” = “düzenli fikir” değil\n\nBeyin fırtınası miktar üretir. Planlama ise şekil gerektirir.\n\nDüzenlenmiş fikirlerin özellikleri:\n\n- net bir hedef ve başarı kriterleri\n- küçük bir kullanıcı görev seti\n- tutarlı bir sözlük (her kavram için tek bir terim)\n- açık adımlar, kararlar ve sonuçlar\n\nAI, fikirlerin takıldığı bu noktada en yararlıdır—ama amaç daha fazla öneri üretmek değil, girdiler yığınını takımın üzerine inşa edebileceği yapılandırılmış bir başlangıca dönüştürmektir.\n\n## AI girdilerinizi nasıl yakalar, temizler ve kümeler\n\nErken ürün notlarının çoğu yarım cümleler, ekran görüntüleri, ses kayıtları ve araçlar arasında dağılmış “unutma” notlarının karışımıdır. AI bu karmaşayı tartışılabilir bir şeye dönüştürebildiği için faydalıdır.\n\n### Adım 1: Dağınık notları özetle ve normalleştir\n\nÖnce, AI ham girdileri net, tutarlı maddelere dönüştürebilir—niyeti değiştirmeden. Genellikle şunları yapar:\n\n- kısaltmaları tam cümlelere çevirir (örn. “kaydet sonra” → “Kullanıcılar öğeleri daha sonra incelemek üzere kaydedebilir”)\n- terimleri standartlaştırır (örn. “müşteri/ kullanıcı” → birini seçip her yerde uygular)\n- dolgu ifadelerini kararlar, sorular ve gereksinimlerden ayırır\n\nBu temizlik önemlidir çünkü on farklı stil uygursa fikirleri iyi gruplayamazsınız.\n\n### Adım 2: Fikirleri adlandırılmış gruplara kümeler\n\nSonra AI benzer notları temalara ayırabilir. Bunu yapışkan notları otomatik sıralamak gibi düşünün—ve sonra her yığma etiket önermesini.\n\nÖrneğin, “Onboarding”, “Arama ve Filtreler”, “Bildirimler” veya “Faturalandırma” gibi kümeler oluşturabilir. İyi kümeleme yalnızca anahtar kelime eşleşmesi yapmaz; ilişkileri ("bu maddelerin hepsi ödeme sürecini etkiliyor") da vurgular.\n\n### Adım 3: Kopyaları ve yakındaki tekrarları tespit et\n\nBeyin fırtınasında aynı gereksinim sık sık küçük varyasyonlarla tekrar eder. AI şunları işaretleyebilir:\n\n- aynı olanlar (kopyala/yapıştır tekrarları)\n- near-duplicate (aynı fikir, farklı ifade)\n- örtüşen kapsam (“e-posta uyarıları” vs “bildirim ayarları”)\n\nHiçbir şeyi silmek yerine orijinal ifadeyi koruyun ve birleştirilmiş bir sürüm önerin, böylece hangisinin doğru olduğunu seçebilirsiniz.\n\n### Adım 4: Daha sonra tekrar kullanacağınız ana varlıkları çıkar\n\nEkranlar ve akışlar için hazırlık olarak AI şu varlıkları çekebilir:\n\n- kullanıcılar ve roller (admin, misafir, alıcı)\n- eylemler (oluştur, onayla, dışa aktar)\n- ekranlar (ayarlar, profil, sepet)\n- veri alanları (e-posta, adres, plan türü)\n\n### İnsan incelemesi hâlâ gerekli\n\nKümelenme bir başlangıçtır, karar değil. Grup isimlerini gözden geçirmeniz, kapsam içi/dışı olanları onaylamanız ve yanlış birleştirmeleri düzeltmeniz gerekir—çünkü burada yapılan bir yanlış varsayım daha sonra ekranlara ve kullanıcı akışlarına yansır.\n\n## Kümelerden ilk ekran haritasına (bilgi mimarisi)\n\nKümeleriniz hazır olduğunda (ör. “içerik bulma”, “kaydetme”, “hesap”, “ödeme”), bir sonraki adım bu kümeleri ürünün ilk geçiş haritasına dönüştürmektir. Bu bilgi mimarisi (IA): neyin nerede durduğuna ve insanların nasıl dolaştığına dair pratik bir taslaktır.\n\n### Kümeleri uygulama bölümlerine dönüştür\n\nAI her kümeyi alıp kullanıcılara doğal gelen bir üst düzey bölüm seti önerebilir—genellikle sekme çubuğunda veya ana menüde göreceğiniz türden şeyler. Örneğin, “keşfet” kümesi Ana Sayfa veya Keşfet olabilir; “kimlik + tercihler” Profil olabilir.\n\nAmaç kusursuzluk değil; kafa karışıklığını azaltan ve sonraki akış işini kolaylaştıran sabit “kova”lar seçmektir.\n\n### İlk geçiş ekran envanterini oluştur\n\nBu bölümlerden AI düz bir dilde ekran listesi üretebilir. Genellikle şunları alırsınız:\n\n- Temel ekranlar (örn. Ana akış, Arama sonuçları, Öğenin detayları, Profil)\n- Destekleyici ekranlar (Filtreler, Bildirimler, Kaydedilen öğeler)\n- Yardımcı ekranlar (Giriş yap, Şifre unutuldu, İzin istemleri)\n\nBu ekran envanteri kapsamı erken ortaya koyar: kimse tel çerçeve çizmeden önce neyin üründe olduğunu görebilirsiniz.\n\n### İnsan terimleriyle navigasyon yapısını öner\n\nAI ayrıca navigasyonun nasıl çalışabileceğini çok tasarımcılaşmadan önerebilir:\n\n- Sekmeler sık ziyaret edilen hedefler için (Ana Sayfa, Ara, Kaydedilenler, Profil)\n- Nadiren kullanılan öğeler için bir menü (Ayarlar, Yardım, Hukuki)\n- Doğrudan giriş noktaları için derin bağlantılar (bir e-postadan belirli öğeyi açma)\n\nBu önerileri kullanıcı önceliklerine göre değil, UI trendlerine göre değil, gözden geçirebilirsiniz.\n\n### Daha sonra ihtiyaç duyacağınız eksik ekranları belirle\n\nAI sık unutulan ekranları işaretleyebilir: boş durumlar (sonuç yok, hiçbir şey kaydedilmedi), hata durumları (çevrimdışı, ödeme başarısız), Ayarlar, Yardım/Destek ve onay ekranları.\n\n### İteratif tutun\n\nGeniş başlayın: az sayıda bölüm ve kısa bir ekran listesi seçin. Sonra sınırları rafine edin—"Ana Sayfa"yı "Ana Sayfa" ve "Keşfet" olarak bölün veya "Bildirimler"i Profil altına taşıyın—ta ki harita gerçek kullanıcı beklentileri ve ürün hedefleriyle eşleşene kadar.\n\n## AI’nın hedefler ve görevlerden kullanıcı akışları önermesi\n\nYararlı bir kullanıcı akışı niyetle başlar, ekranlarla değil. Eğer AI'ya dağınık bir beyin fırtınası veriyorsanız, önce AI'dan kullanıcı hedeflerini çıkarmasını isteyin—kişinin ne yapmak istediğini ve hedefe ulaşmak için hangi görevleri yapacağını. Bu, konuşmayı “ne inşa etmeliyiz?” yerine “kullanıcının başarılı olması için ne olmalı?” sorusuna çevirir.\n\n### 1) Hedeflerden başla, sonra bir akış seç\n\nAI'dan belirli bir kullanıcı türü için en iyi 3–5 hedefi listelemesini isteyin (yeni kullanıcı, dönen kullanıcı, admin vb.). Sonra bir hedef seçin ve dar kapsamlı bir akış isteyin (tek sonuç, tek bağlam). Bu, kimsenin uygulayamayacağı "her şey akıyor" akışlarını önler.\n\n### 2) Temiz bir mutlu yol üret\n\nSonra AI'dan mutlu yolu adım adım üretmesini isteyin: her şey yolunda giderken en basit sıra. Çıktı numaralandırılmış adımlar gibi okunmalı (örn. "Kullanıcı plan seçer → ödeme bilgilerini girer → onaylar → başarı ekranı görür").\n\n### 3) Gerçeklikte olan dalları ekle\n\nMutlu yol stabil olunca, yaygın alternatiflere dallar ekleyin:\n\n- Atla (onboarding, isteğe bağlı adımlar)\n- Düzenle (onaylamadan önce değişiklik yapma)\n- İptal et (yolda çıkış)\n- Tekrar dene (ödeme başarısız, zayıf bağlantı)\n\nAI'dan hangi adımların kullanıcı seçimi (düğmeler, seçimler, onaylar) ve hangi adımların otomatik (doğrulama, kaydetme, senkronizasyon) olduğunu etiketlemesini isteyin. Bu ayrım ekiplerin neye UI gerektiğine, neyin mesajlaşma gerektirdiğine ve neyin arka plan mantığı olduğuna karar vermesine yardımcı olur.\n\n### 4) Paylaşılabilir bir diyagram açıklamasına dönüştür\n\nSon olarak, akışı ekibinizin dokümanlara veya ticket’lara yapıştırabileceği basit bir diyagram açıklamasına çevirin:\n\n\nStart: Goal selected\n1. Screen: Choose option\n2. Screen: Enter details\n3. System: Validate\n - If invalid -> Screen: Error + Fix\n4. Screen: Review & Confirm\n5. System: Submit\n - If fail -> Screen: Retry / Cancel\n6. Screen: Success\nEnd\n\n\nBu, Figma açılmadan veya gereksinimler yazılmadan önce konuşmaları hizalı tutar.\n\n## Akışları net mantığa dönüştürmek: kurallar, durumlar ve kenar durumlar\n\nBir kullanıcı akışı birinin nereye gidebileceğini gösterir. Mantık ise neden gidebildiğini (veya gidemediğini) ve bir şeyler ters gittiğinde ürünün ne yapması gerektiğini açıklar. Ekipler burada sık vakit kaybeder: akışlar "tamamlanmış" görünür, ama kararlar, durumlar ve hata yönetimi hâlâ örtük kalır.\n\nAI, görsel veya yazılı bir akışı teknik olmayan paydaşların tasarım ve geliştirmeden önce gözden geçirebileceği düz bir dilde bir “mantık katmanına” dönüştürebildiği için faydalıdır.\n\n### Adımları kurallar ve izinlere çevir\n\nHer adımı küçük if/then kurallar ve izin kontrolleri olarak yeniden yazmakla başlayın. Amaç açıklıktır, tamlık değil.\n\nAkışı değiştiren ana karar örnekleri:\n\n- Oturum açık vs kapalı: Oturum kapalıysa Giriş ekranına yönlendir; başarı sonrası orijinal adıma geri döndür.\n- Rol/izin: Kullanıcı “görüntüleyici” ise Düzenle eylemlerini gizle; “admin” ise düzenleme ve onaylara izin ver.\n- Uygunluk: Hesap gecikmedeyse ödeme engelle ve faturalandırma ekranı göster.\n\nAI bu kuralları taslaklarken insan-dostu isimler verin (örn. “R3: Kaydetmek için oturum açılmalı”). Bu, inceleme toplantılarında tartışmayı kolaylaştırır.\n\n### Durumları tanımla: yükleniyor, boş, hata (ve “başarı”)\n\nAkıştaki her ekranın açık durumları olmalı. Her ekran için bir kontrol listesi isteyin:\n\n- Yükleniyor: kullanıcı ne görüyor, eylemler devre dışı mı, ne “yüklenmiş” durumunu tetikler?\n- Boş: “henüz veri yok” ne anlama gelir ve birincil sonraki adım nedir?\n- Hata: mesaj tonu, tekrar deneme davranışı ve hataların engelleyici mi yoksa engellemeyen mi olduğu\n\n### Veri gereksinimlerini erkenden yakala\n\nAkışlar veri belirtilmeden gerçeğe dönüşmez. AI ilk taslağı şu şekilde çıkarabilir:\n\n- Ne kaydedilmeli (taslak vs son), nerede (cihaz, sunucu, her ikisi)
SSS
Bir ürün planında “ekran” tam olarak ne sayılır?
Ekranlar bir kullanıcının etkileşime geçtiği bireysel görünümlerdir (sayfalar, modal pencereler, formlar). Kullanışlı bir ekran tanımı şunları içerir:
O ekranda kullanıcının amacı
Önemli UI öğeleri (alanlar, düğmeler, mesajlar)
Ele alması gereken durumlar (yükleniyor/boş/hata/başarı)
Ekranda kullanıcının ne yapmaya çalıştığını açıklayamıyorsanız, genellikle gerçek bir ekran değil—sadece bir etiket olur.
Ekran ile akış arasındaki fark nedir?
Bir akış, kullanıcının bir hedefe ulaşmak için izlediği adım adım yoldur; genellikle birden fazla ekranı kapsar. Şununla başlayın:
Bir kullanıcı türü (yeni kullanıcı, dönen kullanıcı, yönetici)
Bir net sonuç ("ilk görevi oluştur", "faturayı öde", "şifreyi sıfırla")
Sonra numaralandırılmış bir mutlu yol yazın ve yalnızca ondan sonra dalları (atla, düzenle, iptal et, tekrar dene) ekleyin.
Ekranlar ve akışlar bağlamında “mantık” ne demektir?
Mantık sistemin neye izin verdiğini ve kullanıcıya ne gösterildiğini belirleyen kurallar ve kararlardır. Yaygın kategoriler:
Kurallar: gereksinimler ve sınırlar (şifre uzunluğu, plan sınırları)
Kararlar: yönlendirme (onboarding göster veya atla)
Durumlar: oturum kapalı vs oturum açık; deneme vs ücretli
Kenar durumlar: çift kayıt e-posta, çevrimdışı, kısmi veri
Ham ürün fikirleri neden genellikle plana dönüşmeden takılıyor?
Çünkü erken girdiler genellikle dağınık ve tutarsızdır—notlar, sohbetler, eskizler, son dakika fikirleri—bu yüzden şunları içerir:
Yinelemeler ("wishlist" vs "favorites")
Çelişkiler ("misafir ödeme" vs "güvenlik için giriş gerekli")
Eksik adımlar ("ödeme başarısız olursa ne olur?")
Yapı yoksa ekipler kararları tasarım/gelistirme aşamasına erteleyip, boşluklar ortaya çıkınca yeniden iş yapmak zorunda kalır.
AI, anlamı değiştirmeden dağınık notları nasıl temizleyebilir?
Evet—AI özellikle ilk “temizleme geçişi” için uygundur:
Kısaltmaları net maddelere çevirir
Terminolojiyi standartlaştırır (her kavram için bir terim seçer)
Gereksinimleri, kararları ve açık soruları ayırır
En iyi uygulama: orijinal notları saklayın ve AI versiyonunu düzenlenebilir bir taslak olarak gözden geçirip düzeltin.
AI fikirleri nasıl “kümeleyip” gruplar ve nelere dikkat etmeliyim?
AI benzer öğeleri temalara ayırabilir (yapışkan notları sıralamak gibi) ve size yardımcı olur:
Her küme için isim (örn. "Onboarding", "Faturalandırma", "Bildirimler")
Yakın eşlemeleri ve örtüşmeleri işaretleme
Hangi fikirlerin aynı ekran/adım üzerine etkisi olduğunu vurgulama
İnsan incelemesi önemlidir: ekip onaylamadan öğeleri otomatik olarak birleştirmeyin.
Kümelerden ilk ekran haritasına (IA) nasıl geçilir?
Kümeleri alıp şu soruları sorarak bir taslak bilgi mimarisi (IA) oluşturun:
Üst düzey bölümler (sekme/menü kategorileri)
Ekran envanteri (çekirdek, destekleyici, yardımcı ekranlar)
Navigasyon varsayımları (sekme vs menü vs derin bağlantılar)
İyi bir IA taslağı kapsamı erken ortaya koyar ve unutulan ekranları (boş durumlar, hata durumları, ayarlar, yardım) yüzeye çıkarır.
AI’dan uygulanabilir kullanıcı akışları (bulanık diyagramlar değil) nasıl alırsınız?
Bir hedef-öncelikli istem kullanın:
AI'dan bir kullanıcı türü için 3–5 hedef çıkarmasını isteyin.
Bir hedef seçin ve tek, dar kapsamlı bir akış oluşturun.
AI'dan adımları kullanıcı seçimi vs otomatik sistem adımı olarak etiketlemesini isteyin.
Ortak dalları ekleyin (atla, düzenle, iptal et, tekrar dene).
Bu, uygulanabilir akışlar üretir ve "her şey akış" sorununu önler.
Bir akışı net kurallar, durumlar ve kenar durumlarına nasıl dönüştürürsünüz?
Akışı gözden geçirilebilir mantığa çevirmek için şunları isteyin:
If/then kuralları ve izin kontrolleri (R1, R2 gibi etiketlerle)
Ekran başına durum kontrol listeleri (yükleniyor/boş/hata/başarı)
Veri ihtiyaçları (ne kaydedilmeli, doğrulanmalı, eşlenmeli)
Olumsuz yollar (zaman aşımı, süresi dolmuş link, çift gönderim)
Bunu “Karar → Sonuç” formatında sunmak, teknik olmayan paydaşlar için okunabilirliği korur.
Ekipler AI ile nasıl işbirliği yapmalı, uyum ve versiyon kontrolü kaybedilmeden?
AI'yı aynı ana planın farklı “görünümlerini” üretmek için kullanın, ancak tek bir gerçek kaynağı koruyun:
Ana belgeyi (PRD/spesifikasyon) muhafaza edin ve görevlerden ona referans verin.
Rol-özgü çıktılar üretin (yönetici özeti, ekip planı, tasarım/dev teslim notları) ve ana belgeyi referans gösterin.
Geri bildirimi eylem maddelerine ve karar günlüğüne dönüştürmesi için AI'yı kullanın.
Her yinelemede kısa bir değişiklik günlüğü ekleyin (neler değişti, neden, etki).
Bu, farklı kişilerin farklı AI versiyonlarını takip edip sapmasına engel olur.
Yapay Zeka, Dağınık Fikirleri Ekranlara, Mantığa ve Akışlara Nasıl Dönüştürüyor | Koder.ai
Ne doğrulanmalı (formatlar, zorunlu alanlar, benzersizlik)
Ne senkronize edilmeli ve çakışmalar nasıl ele alınmalı\n\n### Kenar durumları açıkça yaz (insanları korkutmadan)\n\nOlumsuz yolları düz dilde listeleyin:\n\n- Çevrimdışı modu, zaman aşımı, tekrar denemeler\n- Çift gönderimler (çift tıklama), idempotentlik notları\n- Geçersiz giriş, süresi dolmuş bağlantılar, eski oturumlar\n\nMantığı teknik olmayan paydaşlar için okunabilir tutmak adına bunu kısa “Karar + Sonuç” formatında sunun ve jargon kullanmaktan kaçının. Aynı yapı hafif bir şablon olarak özellikler arasında tekrar kullanılırsa incelemeler tutarlı kalır.\n\n## Ekranları tutarlı kılmak: bileşenler, kalıplar ve metin\n\nTaslak bir ekran haritası ve birkaç kullanıcı akışı hazır olduğunda, bir sonraki risk “her ekran kendi başına icat edilmiş gibi görünmesi.” AI bir tutarlılık denetleyicisi gibi çalışabilir: aynı eylemin üç farklı isimle anıldığını, benzer ekranların farklı düzenler kullandığını veya mikrometin tonunun değiştiğini fark edebilir.\n\n### Amaç bazlı yeniden kullanılabilir bileşenler\n\nAkışlarınızda tekrarlanan öğelere dayanarak küçük bir bileşen seti önerin. Ekran başına tasarım yapmak yerine yapı taşlarını standartlaştırın:\n\n- Düğmeler: birincil vs ikincil vs yıkıcı (örn. “Kaydet”, “İptal”, “Hesabı sil”).\n- Kartlar/liste öğeleri: başlık, meta veri, durum ve eylemler için tutarlı yapı.\n- Formlar: etiket yerleşimi, zorunlu işaretleri, satır içi doğrulama ve yardımcı metin.\n- Boş durumlar: henüz veri yokken ne gösterilir (net bir sonraki adımla).\n\nBu yaklaşım tel çerçeveleri ve sonraki UI işini hızlandırır—ve aynı bileşen aynı kuralları kullandığı için mantık hatalarını azaltır.\n\n### Ekran ve eylemler için tutarlı adlandırma\n\nSözlüğünüzü basit bir adlandırma sistemiyle normalleştirin:\n\n- Ekran adları: Fiil + Nesne (“Proje oluştur”, “Profil düzenle”, “Siparişi incele”).\n- Eylemler: tek tercih edilmiş terim (“Giriş yap” vs “Oturum aç”) her yerde kullanılsın.\n\nBir sözlük oluşturun ve ekranlar ile akışlar arasında uyumsuzlukları işaretleyin.\n\n### Akışı destekleyen mikrometin\n\nErken aşamada bile temel mikrometni taslaklayın:\n\n- Etiketler ve yardımcı metin (“Şifre en az 12 karakter olmalı”).\n- Hata mesajları ne olduğunu ve nasıl düzeltileceğini açıklamalı (“Kart reddedildi—başka bir ödeme yöntemi deneyin”).\n- Onay ve başarı durumları (“Proje oluşturuldu. Takım arkadaşlarını davet et?”).\n\n### Erişilebilirlik ve marka kalıbı hatırlatmaları\n\nBileşen başına hatırlatmalar ekleyin: klavye odak durumları, açık dil, kontrast gereksinimleri. Ayrıca hangi kalıpların mevcut marka yönergeleriyle eşleşmesi gerektiğini işaretleyin (terminoloji, ton, düğme hiyerarşisi) ki yeni ekranlar kullanıcıların zaten tanıdığı şeylerden uzaklaşmasın.\n\n## İşbirliği ve yineleme: AI’yı hizayı kaybetmeden kullanmak\n\nAI ancak herkes aynı “mevcut gerçekle” bakıyorsa işbirliğini hızlandırır. Amaç modelin öne geçmesine izin vermek değil—onu yapınızı okunabilir tutan yapılandırılmış bir editör gibi kullanmaktır; böylece daha fazla kişi fikir sundukça plana uyum devam eder.\n\n### Farklı kitleler için aynı planı biçimlendir\n\nBir ana belgede başlayın, sonra her grup için farklı görünümler üretin ama temel kararları değiştirmeyin:\n\n- Yönetici özeti: problem, hedef kullanıcı, beklenen sonuçlar, ana riskler, zamanlama varsayımları.\n- Ekip planı: ekran haritası, birincil kullanıcı akışları, mantık kuralları, açık sorular, bağımlılıklar.\n- Tasarım/geliştirici teslim notları: durumlar, kenar durumları, API varsayımları, içerik gereksinimleri.\n\nBelirli bölümlere referans verin (örn. “Aşağıdaki ‘Akış A’ ve ‘Kurallar’ temelinde bir yönetici özeti yaz”) ki çıktılar bağlantılı kalsın.\n\n### Geri bildirimi eylem maddelerine çevir ve kararları kaydet\n\nGeri bildirim dağınık formlarda (Slack dizileri, toplantı notları) geldiğinde, yapıştırın ve şunları üretin:\n\n- bir liste eylem maddesi (sahip, teslim tarihi, etkilenen ekranlar/akışlar)\n- bir karar günlüğü (karar, gerekçe, tarih, kim onayladı)
bir liste açık sorular bir sonraki yinelemeden önce cevaplanması gerekenler
\nBu, klasik “konuştuk ama hiçbir şey değişmedi” boşluğunu azaltır.\n\n### Versiyonlama: ne değişti ve neden\n\nHer yineleme kısa bir değişiklik kaydı içermeli. Fark stilinde bir özet üretin:\n\n- Ne değişti: eklenen/kaldırılan ekranlar, adımların yeniden sıralanması, yeni kurallar veya kısıtlar\n- Neden: kullanıcı geri bildirimi, iş gereksinimi, teknik sınırlama\n- Etkisi: hangi akışlar veya ekranların yeniden gözden geçirilmesi gerekir\n\n### AI sapmasını önlemek için inceleme noktaları\n\nEkran haritası, ana akışlar, mantık/kenar durumları sonrası insan onayı gereken açık kontrol noktaları belirleyin. Kontroller arasında AI'ya yalnızca önermekle yetinmesini söyleyin, sonuçlandırmasını değil.\n\n### Tek bir gerçek kaynağı paylaşın\n\nAna belgeyi bir yerde yayınlayın (ör. /docs/product-brief-v1) ve görevlerden ona bağlanın. AI tarafından üretilen varyasyonları “görünümler” olarak değerlendirin; ana belge herkesin hizalanacağı referans olmaya devam etsin.\n\n## Tasarım ve geliştirmeden önce akışları nasıl doğrularsınız\n\nDoğrulama, "güzel görünen akış çizelgeleri"ni güvenilir bir şeye dönüştürür. Figma açılmadan veya inşa başlamadan önce akışı gerçek kullanıcıların yapacağı gibi test edin.\n\n### 1) Hızlı senaryolar oluştur (3–5 gerçekçi görev)\n\nHedefinize ve kitlenize uygun kısa, inandırıcı görevler oluşturun (biri “dağınık” görev olsun). Örneğin:\n\n- “Dönen bir kullanıcı ödeme yapmadan hemen önce gönderim adresini güncelliyor.”\n- “Yeni bir kullanıcı aynı görevi hiç kayıtlı veri olmadan tamamlamaya çalışıyor.”\n- “Bir kullanıcı hata yapıyor (yanlış kod, eksik alan) ve tekrar deniyor.”\n\nHer senaryoyu önerilen kullanıcı akışı boyunca adım adım çalıştırın. Tahmin etmeden anlatamıyorsanız, akış hazır değil demektir.\n\n### 2) Ekran başına kontrol listesi kullanın (girdiler, çıktılar, hata durumları)\n\nHer ekran için bir kontrol listesi hazırlayın:\n\n- Girdiler: kullanıcı ne yazabilir/seçebilir/yükleyebilir\n- Çıktılar: sistem ne gösterir/değiştirir/kaydeder\n- Sistem durumları: yükleniyor, boş, başarı, kısmi başarı\n- Hata durumları: doğrulama hataları, ağ hatası, izin sorunları\n\nBu, QA sırasında ortaya çıkan eksik gereksinimleri yüzeye çıkarır.\n\n### 3) Kör uçları ve belirsiz kararları bul\n\nAkışı tarayın ve şunları arayın:\n\n- sonraki adımı olmayan ekranlar\n- kriteri olmayan kararlar (örn. “uygun ise” ama uygunluğu ne tanımlar?)\n- onay, geri bildirim veya kurtarma atlayan geçişler\n\n### 4) Hedefle doğrula: daha az adım, daha az sürpriz\n\n“En kısa yol” önerin ve bunu mevcut akışla karşılaştırın. Ek adımlara ihtiyacınız varsa, onların neden var olduğunu açıkça belirtin (hangi riski azaltıyorlar).\n\n### 5) Mülakatlar ve paydaş incelemeleri için sorular hazırla\n\nHedefe yönelik sorular üretin, örneğin:\n\n- “X’i nerede bulmayı beklersiniz?”\n- “Bu hatayı görseydiniz ne yapardınız?”\n- “Devam etmeden önce hangi bilgiye ihtiyacınız olurdu?”\n\nBu soruları inceleme belgenize ekleyin veya bir sonraki bölümdeki prompt şablonlarına bağlayın (see /blog/prompt-templates-turning-brainstorms-into-screens-and-flows).\n\n## Prompt şablonları: beyin fırtınasını ekranlara ve akışlara dönüştürme\n\nİyi bir prompt “zeki olmaktan” çok, AI'ya bir ekip arkadaşına verdiğiniz aynı bağlamı vermekle ilgilidir: ne bildiğiniz, ne bilmediğiniz ve sonraki hangi kararlara ihtiyacınız olduğu.\n\n### Şablon 1: Temiz özet + ortak sözlük\n\nAtölye, çağrı veya beyaz tahta notlarınız dağınıksa bunu kullanın.\n\n\nYou are my product analyst.\nInput notes (raw):\n[PASTE NOTES]\n\nTask:\n1) Rewrite as a clean, structured summary in plain English.\n2) Extract key terms and define them (e.g., “account”, “workspace”, “project”).\n3) List any contradictions or duplicates.\n\nConstraints:\n- Platform: [iOS/Android/Web]\n- Timeline: [date or weeks]\n- Must-haves: [list]\n- Non-goals: [list]\nOutput format: headings + short bullets.\n\n\n### Şablon 2: Maddeleri temalara ayır (etiketli varsayımlarla)\n\nBu, “söylediğimiz her şeyi” ekranlara dönüştürülebilecek kovalar haline getirir.\n\n\nCluster the items below into 5–8 themes.\nFor each theme: name it, include the items, and propose a goal statement.\n\nImportant:\n- If you infer anything, put it under “Assumptions (AI)” and label each A1, A2...\n- Also output “Open Questions” we must answer to confirm/deny assumptions.\n\nItems:\n[PASTE LIST]\n\n\n### Şablon 3: Taslak ekran haritası + akışlar (birden çok seçenek)\n\nPaydaşların karmaşıklık seçenekleri arasından seçim yapabilmesi için en az iki seviye isteyin.\n\n\nBased on these themes and goals:\n[PASTE THEMES/GOALS]\n\nCreate:\n1) An initial screen list grouped by area (IA draft).\n2) Two user flow options:\n - Option A: simplest viable flow\n - Option B: advanced flow with power-user paths\n3) For each option: entry points, success end state, and failure/edge paths.\n4) Output an “Open Questions” list for the next meeting.\n\nConstraints:\nPlatform: [ ]\nMust-haves: [ ]\nCompliance/permissions: [ ]\n\n\nAynı şablonları tekrar kullandıkça ekip girdileri tutarlı biçimde üretir—bu da AI çıktılarının karşılaştırılmasını ve yinelemeyi kolaylaştırır.\n\n## Koder.ai gibi bir platformun nereye uyduğuna dair\n\nAmacınız sadece planlama değil, gönderimse, bu eserleri (ekranlar, akışlar, mantık) uygulamaya bağlamak faydalıdır. Koder.ai, yapılandırılmış bir planı alıp sohbet yoluyla “taslak akışlardan” çalışan web, backend veya mobil uygulamalara geçmenize yardımcı olabilen bir vibe-coding platformudur—özellikle AI çıktısını önce gözden geçirilebilir bir spes olarak ele alıp sonra kademeli üretirken. Planlama modu, anlık görüntüler ve geri alma gibi özellikler akışlar ve mantık üzerinde yineleme yaparken değişiklik geçmişini tutmanızı kolaylaştırır.\n\n## Sınırlar ve en iyi uygulamalar: çıktıyı kontrol altında tutmak\n\nAI, yapıyı hızlandırmada mükemmeldir—dağınık notları taslak ekranlara, kurallara ve akışlara dönüştürmede. Ancak eksik bilgi olduğunda AI boşlukları kendinden emin bir şekilde doldurabilir. En güvenli zihniyet basit: AI önerir, takım karar verir.\n\n### Yaygın riskleri bilin\n\nÇoğu problem gizli varsayımlardan gelir. AI şunları yapabilir:\n\n- ifade edilmeyen kullanıcı hedeflerini varsaymak veya işiniz için önemli kenar durumları kaçırmak\n- önyargılı girdileri aynalamak (örneğin varsayılan olarak "güç kullanıcısı" perspektifine kaymak ve erişilebilirlik ihtiyaçlarını göz ardı etmek)\n- gerçek kısıtları (hukuk, fiyatlandırma, izinler, veri kullanılabilirliği) basitleştirip inşa edilemeyen akışlar oluşturmak\n\nHer çıktıyı bir hipotez olarak ele alın—özellikle “Kullanıcılar yapacak…” veya “Sistem şöyle olmalı…” gibi gereksinim gibi görünen ifadelerde.\n\n### Gizlilik ve hassas verilerle başa çıkma\n\nAI ile beyin fırtınası yaparken yapıştırmayın:\n\n- müşteri adları, e-postalar, telefon numaraları, adresler, hesap kimlikleri\n- dahili finansallar, sözleşmeler, yayınlanmamış yol haritası detayları\n- destek görüşmeleri veya satış çağrılarını açık onay olmadan\n\nBunları anonimleştirip özetleyin (“Kullanıcı A”, “Kurumsal müşteri”, “İade senaryosu”) ve hassas bağlamı ekip belgelerinde tutun.\n\n### İnsan sahipliğini koruyun (ve tek bir gerçek kaynağı)\n\nAkış ve mantık için net bir sahip atayın (çoğunlukla PM veya tasarımcı). AI taslaklarını yazmayı hızlandırmak için kullanın ama kararları kanonik yerde (PRD, spes veya ticket sistemi) saklayın. İsterseniz destekleyici belgeleri göreli bağlantılarla ilişkilendirin.\n\n### İlerlemeden önce kalite kapıları ekleyin\n\nHafif bir kontrol listesi “güzel ama yanlış” çıktıları engeller:\n\n1. Gereksinimler incelemesi: Hedefler, kısıtlar ve aktörler açıkça belirtilmiş mi?\n2. Akış yürütmesi: Her yol birisi tarafından tahmin etmeden takip edilebilir mi?\n3. Metin incelemesi: Etiketler ürün dilinizle örtüşüyor ve belirsizliği azaltıyor mu?\n\n### AI çıktısı için başarı kriterlerini tanımlayın\n\nAI destekli iyi bir akış şunlardır:\n\n- Açık: başka biri bunu geri anlatabilir.\n- Test edilebilir: kabul kriterleri çıkarılabilir.\n- Handoffa düşük sürtünme: ürün, tasarım ve mühendislik arasında daha az boşluk olur.\n\nBunları sağlamıyorsa, düzeltmelerinizi yeni girdi olarak kullanıp tekrar isteyin.
Eğer bir akış nerede kullanıcıların gideceğini söylüyorsa, mantık neden ve başarısız olduğunda ne olacağını açıklar.