Brew içindeki marka bağlamını neden katı bir veri nesnesinden, kesin değerlerin yanında tasarım tercihlerini de açıklayan düzenlenebilir bir belgeye taşıdık?
Bir hex kodu, e-posta ajanına hangi maviyi kullanacağını söyler. Ama bir markanın neden her başlığın üstüne küçük, eş aralıklı (monospace) bir etiket koyduğunu ya da ayırıcılarının neden kutu değil de ince çizgi olduğunu söylemez.
Brew için kurduğumuz ilk marka modelinin sorunu da buydu. Pek çok değeri kaydediyorduk ama bir markayı tanınır kılan ayrıntıları yine de kaçırıyorduk.
Başladığımızda bir marka, yapılandırılmış veri gibi görünüyordu. Renkleri, tipografiyi, varlıkları ve kapsamlı bir stil özellikleri koleksiyonunu modelledik. Bir site tarayıcısı (crawler) alanları dolduruyor, ardından üretim süreci bunları birleştirip e-posta ajanı için bağlama dönüştürüyordu.
Sonuç doğru renge ve yazı tipine sahip olup yine de sıradan görünebiliyordu. Her yeni marka, şemanın öngörmediği bir ayrıntı getiriyordu. Alan eklemeye devam edebilirdik, ama asıl faydalı soru şuydu: Bir tasarımcı aynı markayı başka birine nasıl anlatırdı?
Bir tasarımcı bir rehber yazardı: önemli oldukları yerde kesin değerler, işe yaradıkları yerde örnekler ve aradaki kararları açıklayan düz metin.
Biz de marka analizi ajanından ne üretmesini istediğimizi değiştirdik.
Ona email-design.md diyoruz. Belirli bir markanın e-postada nasıl görünmesi gerektiğini anlatan, düzenlenebilir bir Markdown belgesi.
Kurgusal ve kısaltılmış bir örnek:
# Acme email design
## Voice
Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.
## Signature details
- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.
## Assets
Use the approved logo URL from the asset list.
Do not invent product images or customer logos.Belge, kesin renk değerinin yanında “vurgu rengini her e-postada tek bir öğede kullan” gibi bir kural da barındırabilir. Böylece ajana, tek tek öngörmediğimiz durumlar için de bir talimat verir.
Marka talimatları görünür durumda. Yapılan bir düzeltme, bir sonraki briefin parçası olur.
Markdown burada işe yarıyor, çünkü insanlar onu özel bir form gerekmeden okuyup düzenleyebiliyor. Başlıklar belgeye yapı kazandırıyor ve yeni bir tasarım kuralı eklemek yeni bir veritabanı alanı gerektirmiyor. Bu, pratik bir format tercihi. Markdown kullanmanın her zaman JSON’dan daha az token harcadığı ya da her modelin ağırlıklı olarak Markdown ile eğitildiği iddiasında değiliz.
Web sitesiyle e-postanın görüntülenme kısıtları farklıdır. Yazı tipi, düzen ve karanlık mod desteği e-posta istemcilerine göre değişir. Tarayıcı önizlemesinde doğru görünen bir tasarımın da gelen kutusunda test edilmesi gerekir.
Bu yüzden marka belgesi e-postaya özgü yönergeler de içerir: yedek yazı tipleri, kapsayıcı genişlikleri, tablo yapısıyla uyumlu düzen tarifleri ve açık ile koyu arka planlar için tercihler. Bu talimatlar ajanın uygun kararlar vermesine yardımcı olur; ancak her istemcide birebir aynı görüntüyü garanti etmez.
Görsellerin gereksinimleri farklı olduğu için Brew, görsel yönergeleri için ayrıca image-style.md dosyasını kullanır. Bu iki konuyu açıkça ayırmak, tek bir token listesinin her ortamı tarif etmesini beklemekten daha kolaydır.
Yayındaki bir web sitesi faydalı bir kanıttır, ama her zaman son söz onda değildir. Sitede eski bir kampanya ya da marka ekibinin artık kullanmadığı bir stil denemesi bulunabilir.
Brew, alan adının yanında sağladığınız marka rehberlerini, logoları, görselleri ve diğer referans materyallerini de kullanabilir. Yüklenen marka yönergeleri, çeliştiklerinde web sitesinden elde edilen bilgilerin önüne geçer. Ortaya çıkan belgeyi, özellikle kaynak materyalin eksik ya da tutarsız olduğu yerlerde gözden geçirin.
Alan adı ve onaylı dosyalar, marka analizi sürecine farklı türde kanıtlar sunar.
Butonun şekli yanlışsa talimatı değiştirin. Ses tonu fazla resmîyse belirsiz sıfatı bir örnek cümleyle değiştirin. Böyle bir düzeltmeyi konuşmak, kimsenin düzenlemek istemediği alanlarla dolu büyük bir nesne üzerine konuşmaktan çok daha kolaydır.
Belge; onaylı varlıkların konumlarını, ürün adlarını ve tasarım kararlarını doğrudan üretim bağlamına yerleştirir. Bu, modelin aksi hâlde tahmin etmek zorunda kalacağı boşlukları azaltır. Ama hatalı çıktıyı tamamen ortadan kaldırmaz.
Bu çalışma sırasında e-posta ajanının başka bölümlerini de değiştirdik. Kontrollü bir karşılaştırma olmadan, genel kalitedeki artışı yalnızca dosya formatına bağlamam doğru olmaz. Söyleyebileceğim şey daha sınırlı: Marka briefini incelemek, düzeltmek ve yeniden kullanmak artık daha kolay.
Üretilen bir e-postanın bilgiler ve görünüm açısından yine de gözden geçirilmesi gerekir. İddiaları briefe göre kontrol edin, bağlantıları test edin ve gelen kutusundaki sonucu inceleyin. E-posta ajanına brief verme rehberi bu devir teslimi anlatıyor.
Brew MCP sunucusu artık kullanılabilir. Uyumlu bir asistan, uygulamayla aynı marka bağlamını kullanarak belgelenmiş araçlar üzerinden Brew ile çalışabilir. Bağlantıyı MCP duyurusu ve kurulum dokümantasyonu anlatıyor.
Marka talimatlarının belli bir yerinin olmasını seviyorum. Bir e-posta içimize sinmediğinde bir cümleyi gösterebiliyor, onu değiştirip yeniden deneyebiliyoruz. Bu, modelden bir kez daha “markamıza daha uygun hâle getir” istemekten çok daha verimli bir konuşma.
