Generative UI ve Sonuç Odaklı Tasarımın Sınırları

Üretken arayüz (generative UI) tartışması tek bir vaade sıkışıyor: her kullanıcı kendine uygun arayüzü görsün. Vaat makul, fakat bir arayüz çalışma anında üretildiğinde yalnızca tasarım kararı değişmiyor; o kararın doğru olup olmadığını ölçme imkânı da değişiyor. Kişiselleştirmenin getirisiyle ölçülebilirliğin kaybı aynı anahtara bağlı.

Üretken arayüz tam olarak neyi üretiyor?

Aynı ad altında üç ayrı şey konuşuluyor ve zorluk da risk de hepsinde aynı değil. Ayırmak işe yarıyor:

1. Sıralama: bileşenler sabit, öncelikleri kullanıcıya göre değişir. Filtrelerin dizilişi, öneri listesinin ilk üç satırı.
2. Seçim: önceden tasarlanmış bir kümeden hangi bileşenin gösterileceğine karar verilir. Tablo mu kart listesi mi, tek sayfalık form mu çok adımlı sihirbaz mı.
3. Üretim: bileşenin kendisi, yerleşimi, bazen teması o an oluşturulur. Tasarım dosyasında karşılığı olmayan bir ekran ortaya çıkar.

İlk ikisi yeni değil. İçerik hedefleme adıyla yıllardır yapılıyor, ölçmesi de kolay, çünkü ortaya çıkabilecek görünümler sayılabilir. Yeni olan üçüncüsü. "Her kullanıcıya özel font, renk ve yerleşim" cümlesi kurulduğunda kastedilen o, ve bu yazıdaki sorunların tamamı o katmanda birikiyor.

Sonuç odaklı tasarım ekranı değil varış noktasını tanımlar

Sonuç odaklı yaklaşımda tasarımcı ekran çizmek yerine iki şeyi yazıya döküyor: kullanıcının ulaşmak istediği durum ve bu yolda ihlal edilemeyecek kısıtlar. Yolu sistem kuruyor. Bilet almak, fatura ödemek, iade başlatmak gibi bitiş durumu net olan işlerde bu mantıklı; kullanıcı arayüzü gezmek için açmıyor, işini bitirip çıkmak istiyor.

Bitiş durumu olmayan işlerde aynı mantık ters çalışıyor. Bir koleksiyonda dolaşmak, fikir almak, neyi istediğini ararken keşfetmek gibi durumlarda "hedefe giden en kısa yol" diye bir şey yok, çünkü hedef henüz belli değil. Sistem kısa yolu kendisi varsayarsa kullanıcının görmek isteyebileceği şeyi daha gösterilmeden eliyor. Kısıtları yazmak da sanıldığı kadar kolay değil: zorunlu adımları listelemek basit, "kullanıcı şu bilgiyi vermeden ilerletilemez" türünden kuralları eksiksiz çıkarmak zor, ve eksik bırakılan her kısıt üretken katmanın serbestçe dolaşabileceği bir boşluk anlamına geliyor.

Üretilen arayüzün test edilebilirliği

Regresyon testi, hata raporu ve A/B karşılaştırması aynı varsayımı paylaşıyor: arayüz sabit. Üçüncü katmanda bu varsayım düşüyor. Seçiciye bağlanan bir test, her oturumda farklı üretilen bir yerleşimde tutunacak yer bulamıyor. "İndirme düğmesi yoktu" diyen destek kaydı, o görünümü üreten girdi saklanmadıysa tekrar üretilemiyor; elinizde yalnızca kullanıcının tarifi kalıyor.

Varyant sayısı da hızlı büyüyor. Birbirinden bağımsız 10 ikili kişiselleştirme anahtarı 2 üzeri 10, yani 1024 farklı arayüz demek. Bu sayıyı elle gözden geçiremezsiniz, dolayısıyla test edilecek şey çıktı değil üreticinin kendisi olmak zorunda: hangi girdide hangi kararı verdiği, hangi kısıtı asla ihlal etmediği. Çıktıyı denetlemek istiyorsanız da üretim girdisini (model sürümü, profil anlık görüntüsü, varsa tohum değeri) oturum kaydına yazmanız gerekiyor, yoksa görünüm geri getirilemez.

Çalışma anında arayüz üreten bir sistemle, önceden tasarlanmış sonlu bir varyant kümesinden kurala göre seçen sistemi karşılaştırınca ikincisini belirgin biçimde daha güvenilir buluyorum. Varyant sayısı bilindiği için her birini gerçekten test edebiliyorsunuz, hata raporu tekrar üretilebilir kalıyor, ve kullanıcı aynı yeri iki kez aynı yerde buluyor. Yerleşimin oturumdan oturuma kayması kişiselleştirme gibi görünse de kullanıcının kas hafızasını siliyor; arayüzün nerede ne olduğunu öğrenmek de bir yatırımdır ve her ziyarette sıfırlanması bedava değil.

Erişilebilirlikte kişiselleştirme en çok işe yarıyor

Metin boyutu, kontrast, hareketin azaltılması, odak göstergesinin belirginliği. Burada kişiselleştirmenin değeri tartışmasız, ama bunun için kullanıcıyı davranışından tahmin etmeye gerek yok: tarayıcı zaten kullanıcının beyan ettiği tercihi taşıyor. prefers-reduced-motion ve prefers-contrast gibi sorgular, bir modelin "bu kullanıcı okumakta zorlanıyor olabilir" çıkarımından daha kesin bilgi veriyor, çünkü beyan tahmin değil. Davranıştan çıkarılan erişilebilirlik ihtiyacı yanlış olduğunda kullanıcı bunu düzeltemiyor da; ayarı açıkça sunmak hem daha doğru hem geri alınabilir.

Pratikte nereden başlanır

Sıralama ve seçim katmanlarında kalın, buradaki kazanç gerçek ve maliyeti ölçülebilir. Yerleşimi sabit tutup içeriği değiştirin, tersini değil. Üretken katmana geçeceğiniz yerde ilk iş testi değil kaydı kurmak: hangi girdinin hangi görünümü ürettiği saklanmıyorsa, sistemi daha yayına almadan hata ayıklama imkânınızı kaybetmiş olursunuz.