Yapay Zekaya Hangi Tasarım İşi Devredilir, Hangisi Devredilmez

Yapay zekanın tasarım işine etkisi çoğu zaman iki uç arasında tartışılıyor: ya her şeyi devralacak ya da hiçbir şeyi. İşe yarayan soru bu değil. Hangi işin devredilebileceğini belirleyen iki somut ölçüt var, onlar belli olunca geri kalan tartışma kendiliğinden küçülüyor.

Devretme kararı için iki ölçüt

Bir işi araca bırakıp bırakmayacağınızı iki soru belirliyor. Birincisi, işin çıktısı tanımlı mı: ortaya ne çıkması gerektiğini önceden cümleyle yazabiliyor musunuz? İkincisi, çıktının doğru olup olmadığını ne kadar ucuz anlıyorsunuz: bakar bakmaz mı, yoksa kullanıcıya götürmeden emin olamıyor musunuz?

Bu iki soruyu birlikte sorduğunuzda dört durum çıkıyor ve her biri farklı davranış gerektiriyor.

	Doğrulaması ucuz	Doğrulaması pahalı
Çıktı tanımlı	Devret: ikon varyantları, bileşen dokümantasyonu, ölçü tablosu üretimi	Devret ama örnekleme yaparak kontrol et: arayüz metinleri, boş durum ve hata mesajları
Çıktı tanımsız	Fikir üretimi için kullan, seçimi kendin yap	Devretme: problem tanımı, araştırma sorusu, kabul ölçütü

Üretim ucuzladı, doğrulama ucuzlamadı

Bir akışın üç varyantını üretmek artık bir öğleden sonra almıyor. Üç varyantı karşılaştırmak ise aynı maliyette duruyor. Moderasyonlu bir oturumda üç varyant göstermek ya oturumu uzatıyor ya da katılımcı sayısını artırmayı gerektiriyor, ikisi de doğrudan takvime yazılıyor.

Sonuç şu: üretim on kat hızlanınca darboğaz doğrulamaya kayıyor ve toplam süre beklendiği kadar kısalmıyor. Varyant sayısını üretim kapasitenize göre değil, test kapasitenize göre belirleyin. Test edemeyeceğiniz varyant bir karar değil, yalnızca seçenek yığını.

Üretilen bileşende ilk eksilen şey erişilebilirlik

Üretken araçlar veride en sık rastlanan kalıpları yeniden üretiyor. Bu, ortalamaya çekmek demek; erişilebilirlik gereksinimleri o veri içinde azınlıkta kaldığı için ilk düşen kısım da orası oluyor. Üretilen bileşenlerde tekrar tekrar aynı boşluklar çıkıyor:

• Odak göstergesi ya hiç tanımlanmamış ya da görünürlüğü kaldırılmış oluyor.
• Klavye sırası görsel sırayla uyuşmuyor.
• Açılır menü ile onu tetikleyen düğme arasında ilişki kurulmamış oluyor, ekran okuyucu menünün açıldığını duyurmuyor.
• Metin ile arka plan arasındaki kontrast sınırın altında kalıyor.

Bunu yakalamanın yolu kodu okumak değil. Fareyi bırakıp sekme tuşuyla arayüzün başından sonuna gitmek bir dakika sürüyor ve listedeki ilk üç maddeyi anında görünür kılıyor. Kontrast için ayrı bir ölçüm gerekiyor, onu da tarayıcının denetim araçları veriyor.

Kullanıcı adına hareket eden yazılımlar

Yakın dönemde arayüzlerle yalnızca insanların değil, onlar adına hareket eden yazılımların da etkileşime gireceği sık söyleniyor. Buradan çıkarılan sonuç genelde "bir de ajanlar için tasarlayın" oluyor; ben bunu ikinci bir arayüz tasarlayarak değil, mevcut işlemleri sunucu tarafında adı belli ve kararlı uç noktalara bağlayarak çözerim, çünkü ekranı iki kez tasarlamak gerekmiyor.

Aradaki farkı bir randevu akışı üzerinden görmek kolay. İnsan tarafı için akış tasarlanır: uygun saatler, onay, iptal. Makine tarafı içinse aynı işlemlerin görsel katmandan bağımsız bir karşılığı olması yeter. Bir düğmenin metnini değiştirmek entegrasyonu bozuyorsa, o entegrasyon arayüzün görünen yüzüne bağlanmış demektir ve orası her sprintte değişiyor.

Tasarım tarafında atılacak ilk adım daha mütevazı: içeriği anlamlı işaretlemek, durumları görselin yanında metinle de ifade etmek, aynı işlemi klavyeyle yapılabilir bırakmak. Bunlar zaten erişilebilirlik için yapılan işler, ikinci bir bütçe kalemi değil.

Tasarımcının değeri nereye kayıyor

Devredilebilir işlerin ortak yönü belli: çıktısı tanımlı olanlar gidiyor, tanımı yapan kalıyor. Araçlar yaygınlaştıkça kıymetlenen beceri üretmek değil, kabul ölçütü yazmak oluyor. Bu ekran ne zaman doğru sayılır, hangi kullanıcı hangi işi kaç adımda bitirebilmeli, hangi sonuç çıkarsa geri döneriz. Bu cümleleri yazabilen ekipte yapay zeka hız üretiyor, yazamayan ekipte yalnızca daha fazla seçenek üretiyor.