AI ile Tasarım Tutarlılığı: Skills ve UX Süreçleri Nedir?

Evet, Arda'dan. Bir şey daha sorabilirim ben. Bu Chat.jp'deki ve Gemini'deki mesela özel gem mantığı ya da proje giriş promptları mantığından tam olarak ayrıştığı nokta kafamda oturmadı benim. Çünkü ayrı bir halini almış bu Skills adı altında. Bunlardan farkı nedir tam olarak? Güzel bir soru. Benim de aslında sunumdan önce bunu anlatmam gereken bir soru olarak bunu yazmıştım. Hemen sana şu şekilde anlatayım. Aslında CloudMD ya da Gemini'nde farklı farklı şeyler var. Bu CloudMD dosyası her promptta gelip bakılan bir Yani projenin genel bilgisi. Sen CloudMD'ye bütün Design Guideline yazdığın zaman aslında her seferinde kontekst olarak o prompta bütün projenle alakalı bilgiyi de yüklüyorsun. Spesifik olarak yapmak istediğim bir task, spesifik olarak yapmak istediğim bir kısım varsa Skills daha Token Efficient bir yöntem olduğu için aslında o hayata geçti. Günün sonunda ama tabii ki Cloud gibi ya da diğer şeyler gibi mesela her Prompt'ta, her Frontend Task'ında Bu skill'i çağır dememe gerek kalmıyor artık. Başlangıç noktasında o şeyi vermekte, o projeyi inişiyet etmekte, tutarlılığını sağlamakta ya da birli başlı tasları redesign etmekte O skili çağırmak gerekiyor ama her seferinde çağırmaya gerek yok. Ama işte o proje genelindeki o CloudMV dosyaları ya da Cursor için de benzer bir şey vardı. Bunlar aslında her promptta çağrıldığı için Token Efficiency'si daha yüksek ve konteksti daha hızlı dolduran bir yöntem. Aradaki fark Benim anladığım ve araştırdığım kadarıyla böyle ama farklı bir şey varsa da yine daha sonrasında şey yapmak, sana follow up edelim. Ama ilk izlenimim, anladığım bu yani. Arasındaki fark. Anladım.

Ya da daha önce 8... Evet, Arda. Merhaba, sesim geliyor mu? Geliyor, geliyor. Bundan birazdan bahsedecek de olabilirsiniz bu arada Cursor tarafında ama öyleyse tabii orada konuşabiliriz. Bu kısmını oluştururken, burayı beslerken mesela şöyle komutlar mı veriyoruz? Atıyorum, UX Design Award sitesini incele ve burada en çok tutan projelerdeki fontları kullan sadece gibi. Yani bu şekilde bir kaynağı tespit edip Oradaki kural dizisinden yararlanma gibi bir yaklaşım mı var? Aynen onu birazdan bahsedeceğim o konuda. Ama benzer şey... Burada yine şunu söylemek istiyorum. En başında söylediğim gibi burada hani... Aslında AI konusunda ya da AI kullanımıyla alakalı şu an herkes bir şeyler söylüyor. Şu an ben bir şeyler söylüyorum. Ama burada bir sınır yok. Aslında benim yapmaya çalıştığım şey de birazcık şunu teşvik etmek. Yani şöyle mi yapıyorsunuz dediğiniz şey aslında gerçekten muhtemelen işe yarıyor. O yüzden bir şeyi yapmanın yöntemi aklınıza geliyorsa muhtemelen doğru oluyor günün sonunda AI'da. Ama evet, o şekilde de yapabilirsiniz. Benim biraz sonra vereceğim örnek aslında biraz daha... hali hazırdaki dizayn sistemimizi ya da hali hazırdaki kullandığımız tasarım kurallarını nasıl artiküle edebileceğimizi sağlamak. Ama senin bahsettiğin gibi şu da yapılabilir. Onunla alakalı bir kaynak var. Örnek veriyorum. İşte... Facebook tasarım dilini... Anlayıp bunu bir skill'e dönüştürebilen kaynaklar da çıkmaya başladı. Bu şekilde kullanılabilir. Biraz daha detaylı anlatabilirim onu. Tamam teşekkür ederim.

Buraya kadar bir sorusu olan var mı? Bu arada hani hızlı gidiyorsam lütfen beni durdurabilirsiniz. Öbür tarafa geçmeden hızlı bir soru cevap yapabiliriz isterseniz. Bu skill ve skilleri kullanmadan önceki ve sonrası kendi ekibinizle karşılaştırma yaptınız mı? Aslında skill kullanmadan önceki sonuçlar ve bu aynı prompt aynı şeyler. Aslında mesela bunu mu sormak istemiştin? Yoksa bir organizasyon içerisindeki kullanımdan bahsediyorsun? Yok herhangi bir geliştirme prompta ya da işte Cloud Code'da şeyde. Tam olarak bu işte. Aslında belki yan yana koysam daha iyi olurdu. Mesela yan yana koyayım. Şöyle. Şunları silelim. Aynı prompt, aynı model. Sağ tarafta aslında frontend design skillini kullanarak oluşan sonuç. Sol taraftaki jenerik bir sonuç. Sorduğun soru bu muydu acaba Seyda? Evet, evet. Yani... Dizayn olarak baktığın şeyi tam öyle bakmışsın ama ben genelde kafada kod olarak düşündüğüm için. Kod olarak, kod yapısı ayrı bir tarafta ama tasarımsal olarak farklılığı böyle.

Hemen sana şu şekilde anlatayım. Aslında CloudMD ya da Gemini'nde farklı farklı şeyler var. Bu CloudMD dosyası her promptta gelip bakılan bir Yani projenin genel bilgisi. Sen CloudMD'ye bütün Design Guideline yazdığın zaman aslında her seferinde kontekst olarak o prompta bütün projenle alakalı bilgiyi de yüklüyorsun. Spesifik olarak yapmak istediğim bir task, spesifik olarak yapmak istediğim bir kısım varsa Skills daha Token Efficient bir yöntem olduğu için aslında o hayata geçti. Günün sonunda ama tabii ki Cloud gibi ya da diğer şeyler gibi mesela her Prompt'ta, her Frontend Task'ında Bu skill'i çağır dememe gerek kalmıyor artık. Başlangıç noktasında o şeyi vermekte, o projeyi inişiyet etmekte, tutarlılığını sağlamakta ya da birli başlı tasları redesign etmekte O skili çağırmak gerekiyor ama her seferinde çağırmaya gerek yok. Ama işte o proje genelindeki o CloudMV dosyaları ya da Cursor için de benzer bir şey vardı. Bunlar aslında her promptta çağrıldığı için Token Efficiency'si daha yüksek ve konteksti daha hızlı dolduran bir yöntem.

Benim bir tane UX Review Skill'im var mesela. Örnek veriyorum. Yaptığım bir tasarım mesela Figma'da böyle bir şey varken diyorum ki mesela Bu UX Reviewer skilli, Accessibility anlamında, Spacing anlamında ya da bu ekranın çözmesi gereken problem bu. Sence, diyorum ki mesela sence UX Reviewer, buna bak, bu problem, bu akış, mesela Figma MCP2 olarak birden fazla ekranı da besleyebiliyorsun. Bunu yaparak, diyorum ki bu flow, bu probleme sence çözüm oluyor mu? Bu noktada gerçekten güzel insightler çıkabiliyor. Ben bunu şirket içerisinde kullanıyorum. Hatta şirket içerisinde ben birisiyle tasarımımı paylaşmadan, ben böyle bir sonuç ürettim, bir soluşun ürettim demeden önce... bir nabız yoklama açısından daha iyi bir fikir olabilir mi? Burada bu flowda eksik var mı? şeklinde kullandığım şeylerden bir tanesi.

Burada ben variable'lı Jason adlı bir plugin kullandım. Bunu kullanabilirsiniz. Eğer variables kullanıyorsanız Figma'da... ...direkt olarak bunların hepsini bir JSON formatına dönüştürüyor. Siz de aslında... Biraz sonra yine Angel Delta'nın Frontend Design Skills'ini göstereceğim. Aslında kontekst olarak, yine bağlam olarak... ...AI'ye diyorsunuz ki... Bir renk kullanımı için karar vermek gerektiği zaman... ...bu dosyadaki renklere bak. Bu dosyadaki renk tanımlarına bak. Ve... kullanmanın için en uygun olan rengi seçip direkt olarak burada kullan. O yüzden aslında bir, tasarım felsefemizi implemente ettik, artiküle ettik. İki, buna destek olacak, bu kurallara destek olacak tokenlarımızı, aldığımız Figma'daki belli kararları eksport edip yine bir kontekst olarak AI'a veriyoruz. Aynı şekilde, tasarım felsefemiz var, figma tokenlarımız var.

Figma MCP ile Cursor Cloud'u bağlayarak direkt olarak Figma linkini pastedip diyebilirsiniz ki bu benim Figma projem. Git buradaki boşlukları, buradaki font sizeleri, buradaki design system elementlerini anla. Bunları bana bir... felsefik ve skilze dönüştür. Unutmayın ki burada yine detay çok önemli. Yine en başta izlediğimiz peanut butter and jelly videosuna atıfta bulunuyorum. Oradaki gibi... kullandığınız, kullanmadığınız, gidilmesi gereken ya da gidilmemesi gereken şeyleri çok net ifade etmelisiniz ki... günün sonunda çıkan sonuç sizin... ürününüzle, ya da figma tasarımlarınızla, ya da tasarım felsefenizle ortak bir şey konuşsun. İkinci, benim kullandığım yöntem figma tokenlarınızı, variable'lılarınızı eksport edebilirsiniz.

Aslında izlediğim yöntem şuydu... Projemin felsefesini yazmam lazım. Tasarım felsefesini yazmam lazım. Bu yazıldığı kadar kolay gelmediğinin farkındayım. Ama yine de biraz önce söylediğim gibi. Bu sıkıştığım noktada yine bana AI destek oldu. Ben aslında çok basit bir şekilde biliyorum ki Ejdelta sade, bilgi yoğunluğu yüksek, nötr renk kullanımı, düz ve modern bir tasarım diline sahip. Ama bunu yazmak her zaman söylediğim kadar kolay olmuyor. Bunun kolay yolu şu. Üründen 1-2 ekran görüntüsü alıp Cloud'a ya da Cursor'a atıp, ben Ejdelta tasarımcısıyım. Benim ürünümün tasarımları. Bunlar birkaç ekran. Aslında bana bir tasarım felsefesini tanımla dediğimiz zaman... Yapay zeka bunları algılayıp artiküle etmek konusunda bana çok fayda sağladı. O yüzden siz de bu şekilde yapabilirsiniz. Aynı zamanda Figma MCP de kullanabilirsiniz.

Vibe Coding dediğimiz şeyle. Ancak üretilen Vibe Coding prototiplerinde çıkan bazı elementler bizim tasarım sistemimize uymuyor. Örnek veriyorum bir şeyi açma yöntemi model ile olabilir ya da driver ile olabilir. Tasarımcı olarak bizim kullandığımız belli dil ve patenler vardır. Bunların tutarlılığı aslında bizim için önemlidir. Yani bir tasarımcı olarak, tasarım ekibi olarak... ...bunların bir şekilde tutarlılığını sağlamak da bizim sorumluluğumuz. Ama AI ile üretilen şeylerde böyle bir tutarlılık olmadığı için de... ...günün sonunda şöyle bir eğilim oluyor. Gerçek çözüm işte hani prototipte ben işte Drawer ile açıldığını görüyorum ama... Biz de model kullanıyoruz yani belli bir disk aşına gidiyor. O tartışmalar, o konuşmalarda çok fazla zaman kaybetmemek için aslında benim aramaya çalıştığım çözüm Skills gibi bir ortak kütüphane ve tasarım sistemi nasıl birleşirdi?

...bahsetmek gereken şey, bir skills dosyasında, tasarım için aslında yaptığım bir skills dosyasında... ...bahsettiğimiz gereken şeyler var. Foundation'lar, bizim tokenlarımız ne? Hangi tokenları kullanacak? Layout'la alakalı aldığımız kararlar, komponentlerle aldığımız kararlar. Bunların hepsini verdiğimizde Skiz dosyası sizin için ortak kullanılan bir bilgi yoğunluğu olacak. Öncesinde ne yapıyorduk Skiz öncesindeki hayatımızda? Promptumuzu yazıyorduk. Bir çıktı geliyordu ve bu çıktı da... ...bakıyorduk ki yanlış navigasyon patenleri kullanılmış. Hayır bunu lnav'e çevir. Ya da primary color aslında navy blue idi.

...yeni dosyaya paslıyorsunuz. Sürekli kopyalayıp işte yeni projelere yapıştırıyorsunuz. Bu aslında hem scale edilebilir bir yöntem değil... ...hem de tutarlı bir yöntem değil. Bir şeyler değiştiğinde her zaman bunu maintain etmek daha da zorlaşacaktır. O yüzden aslında Skills dediğimiz şeyin ortak bir, yani Figma için Component Library neyse, AI içinde Skills'ı öyle hayal ederseniz aslında mentalit olarak ne işe yaradığını belki biraz daha kafanızda daha iyi canlandırabilirsiniz. Her tasarım framework'ünde ya da design system framework'ın olduğu gibi... ...skills framework gibi bir şey de hazırladım ben. Burada...

O yüzden de yine Cloud ekibinin yaptığı, hayatımıza kattığı bir terminoloji var. Skills. Skills dediğimiz şey, bu beklediğimiz görevin, bu çıktığının konteksisini daraltmak ve belli bir rotaya sokmak için yapılan çok basit bir şekilde bir markdown dosyası. Sağ tarafta benim Ejderha için yaptığım frontend skillini görüyorsunuz. Çok basit, yine instruction olarak nasıl yapılıyorsa. Ben Ejderha Frontend Design Skill'ine diyorum ki, Sen Frontend Design Skill olarak şunları yapmalısın, şu sayfalara bakmalısın, bu tipografik kuralları uygulamalısın, ya da bunları uygulamamalısın gibi belli bir instruction diyoruz. Şöyle düşünün. Bir skil dosyası, figma dosyasını nasıl...

Aesthetics Prompt aslında buna benziyor. Yine peanut butter jelly örneğinden geliyorum. En baştaki gibi, eğer siz verdiğiniz... ...instruction'da ne yapılması ya da ne yapılmaması gerektiğini... ...AI'ye söylemezseniz, aslında AI'da... ...yanlış yapabilir ya da en standart çözümü üretebilir. Cloud ekibinin yaptığı şey şu. Aslında diyor ki... ...AI, sen bunu yaparken tipografik olarak bunları yap. Tema olarak bunları yap. Ya da şu fontları kullanma. belli layout tercihlerini ya da belli layout kararlarını verirken aslında Frontend Aesthetics Promptu ile birlikte güçlendiriyor. Şimdi peki şöyle bir problem geliyor. Biz iş yaparken sürekli bu Promptu kopyalayıp yapıştıracak mıyız? Hayır.

Bu yüzden de AI Slope dediğimiz bir kavram türeti. Yani bütün tasarımlar, AI ile üretilen bütün tasarımlar birbirine benziyor. İşte bunlar AI ile üretilmiş demeye başladık. Ben bu sesyondan önce Cursor kullanarak aslında bir prompt verdim. Kullandığım prompt bu ve 3 farklı modeli aslında eş zamanlı olarak çalıştırdım. Ve çıkan sonuçlar bu. Artık anlıyoruz ki zaten bu çıktılar. Modeller gelişiyor. Daha iyi yorumluyor. Ama yine de... Günün sonunda çıkan sonuçlar her zaman bizi tatmin etmeyebilir. Ya da karakterden birazcık daha yoksun olabilir. Örnek veriyorum. Sol taraftaki renkler, kullanımlar bizim markamız için ya da projemiz için uygun olmayabilir. Ya da kullanılan tasarım dili... bir kullanıcının sorununa, o hedef kullanıcının sorununa çare olmayabilir.

Bu değişimlerden bir tanesi de Prompting diye aslında biz kullanıcının derdini bir şekilde farklı şekillerde çözmeye başladık. Artık daha çok yazarak bu tool'u kullanmaya çalışıyoruz. Bu yazma performansı da aslında günün sonunda oluşan, çıktığı belirliyor. Şimdi düşünelim ki bir tasarımcı olarak yine, zaten çalıştığımız organizasyon olabilir, kendi tecrübelerimiz olabilir, zihnimizde... Olan birçok şeyi biz zaten tasarım yaparken uyguluyoruz. Örneğin diyoruz ki tamam bunun boşluğu böyledir. Ben hiç more kullanmayacağım. Çünkü bu şirketin more kullanma ile alakalı bir şey yok. Hani Brand Guideline'ında bu yok. Ya da ben biliyorum ki işte tipografik olarak bizim organizasyonumuzda kullanılması gereken tipografik kurallar bunlardır. Bunların çoğu aslında yazılı kurallar değil.

Merhabalar. Şeyi sormak istiyorum aslında. Burada genelde skills konusunu konuşurken yaptığın yaklaşımla ilgili bir soru soracağım. Ama kısaca kendimi de tanıtayım. 2015'te UX camp'a katılmıştım. 10 yıldır da. UX Designer olarak ya da ürün tasarımcısı olarak çalışıyorum. Şu anda da Google Snitch'i çok aktif kullanıyorum. Cloud'u aktif kullanıyorum. Diğer birçok aracı da hani böyle deniyorum. Hatta Cloud sadece chat bölümünde bile böyle arayüz yani UI çıktıları... ...vermeye başladı hani kendi kendine. Ben aslında sormadan hani nasıl yapsam falan diye düşünürken... Bana direkt UI oluşturup vermeye başladı. O da çok ilginç bir yere gidiyoruz.