UX Writing İçin Agent Oluşturmak
Sektör profesyonellerini konuk yazarlar olarak ağırladığımız bu seride, ürün tasarımına ilişkin iyi uygulamaları ve tecrübelere dayanan öğrenimleri konuşuyoruz. Bu bölümde, Burcu UX Writing denklemini kolaylaştıran etkili bir agent kurmanın “nasıl”ını detaylandırıyor.
Başlarken:
Son bir yılda agent’lar neredeyse her ürün ve tasarım ekibinin gündeminde. İşin tasarım tarafında sayısız kullanım senaryosu konuşuldu ama iş içerik ve ürün dili tarafına geldiğinde aynı derinliği pek göremedik.
Tartışmalarının ilk heyecanı geçmiş olabilir ama UX Writing özelinde konuşacak çok şeyimiz var. Yapây zeka söz konusu olunca idam sehpasına çıkarılan mesleklerden birisi de hiç şüphesiz UX Writing oldu. Doğrudan neden-sonuç ilişkisi kurmak doğru olmayabilir; ancak küçülen ekipler ve azalan headcount’lar bu dönüşümün sektörde ciddi bir karşılığı olduğunu gösteriyor. Çünkü artık yapay zekâ metin yazabiliyor. Soruyoruz, yanıt veriyor. Gerçekten öyle mi?
İşin temellerini konuşarak başlayalım:
Neden Gerekli?
Amaç, ürün dilini ölçeklenebilir ve tutarlı hale getirmek. Agent geliştirmeden önce 3 temel hedef koydum:
UX metin yazım kurallarını uçtan uca tüm şirket içerisinde sürdürülebilir hale getirmek.
Yazar dahil olmayan proje / işlerde de tasarımcı veya ürün ekipleri tarafından kuralların uygulanmasını; tutarlılığı sağlamak.
UX içerik ve metin kılavuzunun ve kuralların kullanımını kolaylaştırmak, standardizasyonu artırmak.
Sadece Guideline Yeterli Mi?
İlk çıktılar teknik olarak doğruydu ama hâlâ ürünün diliyle konuşmuyordu. Bazı metinler fazla açıklayıcıydı, bazıları gereğinden fazla “AI-friendly” hissediyordu. Bazıları çok mekanikti. Guideline’a rağmen, özellikle context eksik olduğunda, agent boşlukları kendi varsayımları ile doldurmaya başladı. Bu benim için kritik bir kırılma anıydı. Sorun “ne yazacağını bilmemesi” değil, nasıl yazacağını doğru bağlamda yorumlayamamasıydı.
İşlevsel Bir Yazı Sistemi Tasarlamak
İlk çıktılardan aldığı derslerden hareketle problemi bir prompt yazma sorunu olarak değil, ürün dili sistemi tasarlama problemi olarak ele aldım. Süreci birkaç katmanda ele aldım:
Yazım Sistemini Standartlaştırmak: İlk iş prompt yazmak olmadı. Önce mevcut UX Writing guideline’larını agent’ın anlayabileceği şekilde yapılandırdım. Bunlar arasında ses ve ton, terminoloji listeleri, bileşen bazlı yazım kuralları, erişilebilirlik ilkeleri, yasaklı kullanımlar, CTA standartları yer aldı; çünkü “iyi metin” için önce organizasyonun iyi metni nasıl tanımladığını bilmesi gerekiyordu.
Yapısal Çıktı Formatını Oluşturmak: İkinci kritik adım, sadece içeriği değil, çıktının nasıl organize edildiğini kontrol etmekti. Bu yüzden agent’a başlık seviyeleri, liste ve açıklama ayrımı, okunabilirlik önceliği, UI metinleri ayrımı, kullanılmaması gereken ifadeler gibi detaylı bilgiler ekledim. Böylece, markdown sadece bir yazım formatı değil, aslında bilginin ekranda nasıl tüketileceğini belirleyen bir yapı haline geldi.
Few-Shot Examples İle Sistemi Eğitmek: Agent’a sadece kural verdiğinizde yapay zekanın o mekanik, doğru ama hissiz dili sizi karşılıyor. Agent, ürün dilini iyi örneklerden öğrendi. Kalite farkı da burada ortaya çıkıyor. Örneğin; iyi hata mesajları, kötü CTA örnekleri, yeniden yazılmış versiyonlar, ton dönüşümleri, kullanılmaması gereken kelimeler, doğru-yanlış örnekleri gibi örnekleri sisteme dahil ettim. Özellikle “neden kötü / neden iyi” mantığı sonuçları ciddi şekilde iyileştirdi.
Prompt’ları Bağlam Odaklı Tasarlamak: Sadece rol atayıp “Sen UX Writer’sın” demek yeterli değil. Context vermeden UX metni beklemek de keza yetersiz. “Button label yaz” gibi prompt’lar zayıf sonuçlar üretiyor. Onun yerine prompt’lara platform, ekran tipi, kullanım amacı, statü durumu, karakter limiti, ton beklentisi ekledim. Sistem ve image prompt’larına da öncelikle nelere bakması, kullanıcıdan soru gelince nasıl yanıtlaması gerektiğine dair örnekler ve yönergeler ekledim. Context arttıkça çıktılar da daha kullanılabilir hale geldi. Özellikle ekran görseli / context kullanımı, belirsizliği ciddi şekilde azalttı. Bu katman olmadan agent sürekli “varsayım yaparak” yazıyordu.
Ve UAT döngüsü ...
Dokümanları yükledim, örnekleri de ekledim artık tamam diye düşünmeyin. Agent’ı canlıya alana kadar -ve aldıktan sonra- turmaksızın test etmek; edge case’leri denemek gerekiyor. Bu sayede yönergeleriniz veya dokümanlarda neler eksik kaldı, neler düzeltmeye ihtiyaç duyuyor görebiliyorsunuz. UAT süreçlerinden sonra yüzde yüz mükemmel yanıtlara ulaşmayı tabii ki beklemeyin. Ama artık yayına hazır dediğiniz noktada
tebrikler, artık agent hazır.
İşin özü:
Sürecin sonunda yapay zekânın tek başına iyi UX metni üretemediğini net bir şekilde gördüm. Önce sizin organizasyon olarak “iyi UX writing”in ne olduğuna karar vermeniz; bir orkestra şefi gibi yönlendirmeniz, yol-yöntem göstermeniz gerekiyor; çünkü yapay zekâ yalnızca iyi yazıyı değil, kötü yazıyı da ölçeklendirebilir.
