Case study’nin görevi “ne kadar güzel tasarım yaptığını” tek başına göstermek değildir. Projenin bağlamını, senin gerçek rolünü, çözülen problemi, kararların arkasındaki mantığı ve sonunda üretilen gerçek sistemi kanıtlamaktır. Bu yüzden case study’yi ekran görüntüsü veya mockup sayısına göre değil, okuyucunun cevaplaması gereken sorulara göre kurmak daha güçlüdür.
1. Hero’da önce sonucu ve projenin ne olduğunu göster
Case study’nin ilk ekranı uzun süreç metniyle başlamamalı. Projenin adı, müşteri/marka, kısa scope, rol, yıl ve güçlü bir gerçek output kullanıcıya birkaç saniyede bağlam vermeli. Broadcast package ise on-air sistem; web ise çalışan arayüz; identity ise gerçek uygulama ailesi görünmeli.
| Alan | Örnek |
|---|---|
| Project | TYT Türk — Kurumsal / Broadcast Tasarım |
| Client | TYT Türk |
| Role | Creative Motion Designer / Broadcast Design |
| Year | 2025–2026 |
| Scope | Broadcast package, lower thirds, ticker, programme graphics |
| Hero media | Gerçek package çıktısı veya seçilmiş master frame/video |
2. Context: Proje neden vardı?
Context bölümü müşteri tarihçesi anlatmak için değil, tasarım problemini anlamak için gereken şartları vermek içindir. Yeni kanal lansmanı mı? Mevcut kimlik yenileniyor mu? Tek kampanya mı, sürekli kullanılacak sistem mi? Canlı yayında operatör mü kullanacak?
- İş problemi / ihtiyaç
- Hedef kullanıcı veya izleyici
- Kanal/platform/üretim ortamı
- Zaman veya teknik constraint
- Mevcut sistemden korunması gereken şeyler
Context gereksiz gizli bilgiyi ifşa etmemeli. NDA veya ticari hassasiyet varsa sadece tasarım kararını anlamaya yetecek seviyede anlat.
3. Rol ve scope’u abartmadan netleştir
Takım projesinde “ben yaptım” dili güveni zayıflatabilir. Logo başka ekipten, motion senin, web development başka kişiden geldiyse bunu ayır. Case study’nin güçlü olması için her şeyi senin yapmış olman gerekmez; senin contribution’ın açık olması gerekir.
| Belirsiz | Daha güvenilir |
|---|---|
| Creative direction & design | Broadcast motion system, KJ/ticker animation, template behaviour |
| Website project | UI design; frontend implementation by X/team |
| Branding | Visual identity extension; master logo supplied by client |
4. Challenge’i generic “modern görünmeliydi” cümlesinden çıkar
“Modern, dinamik ve kullanıcı dostu” hemen her projeye yazılabilir; bu nedenle gerçek challenge değildir. İyi challenge ölçülebilir olmasa bile spesifiktir: lower-third iki satırlı uzun görevleri bozulmadan taşımalı, TV paketi 25/50 cadence’e uyumlu çalışmalı, identity hem haber hem spor alt markasını taşımalı veya site TR/EN uzunluk farkında kırılmamalı gibi.
5. Process’i kronolojik günlük değil karar sistemi olarak anlat
Moodboard → sketch → final sırası her projede anlamlı değildir. Okuyucunun görmek istediği, hangi alternatiflerin neden elendiği ve hangi sistem kararlarının finali şekillendirdiğidir.
- Problem decomposition
İşi hangi alt problemlere böldün?
- Constraints
Hangi teknik/brand/content sınırları tasarımı etkiledi?
- System decisions
Grid, type, motion, colour, component veya template kurallarını nasıl belirledin?
- Stress tests
Long copy, responsive state, live data, print proof, alternate crop gibi hangi edge case’leri test ettin?
- Iteration reason
Revizyon yalnız “client wanted” değil, hangi problem nedeniyle yapıldı?
6. Gerçek medya bir kanıt sırası oluşturmalı
20 mockup göstermek case study’yi otomatik güçlendirmez. Medya sırası bir argüman kurmalı: önce sistemin genel görünümü, sonra kritik component’ler, sonra detay/edge case, en son gerçek kullanım veya hareketli çıktı.
| Katman | Örnek |
|---|---|
| Overview | Full broadcast package / site hero / identity family |
| System | Grid, type, component states, motion family |
| Detail | Lower-third long-name state, responsive card, print detail |
| Real use | On-air capture, live URL screenshot, delivered campaign asset |
| Motion | MP4/video where movement is part of the solution |
Video projenin gerçekten motion özelliğini gösteriyorsa kullan; statik işi sırf sayfa hareketli olsun diye autoplay video’ya çevirmek gerekmez.
7. Sonuç bölümünde sahte metrik üretme
Tasarımcıların portfolyoda en riskli alışkanlıklarından biri erişimi olmayan KPI’ları uydurmak veya “engagement %40 arttı” gibi kaynaksız başarı cümlesi yazmaktır. Gerçek veri yoksa sonuç bölümünü delivery/implementation üzerinden yazmak daha güvenilir.
| Kanıtlanabilir sonuç | Örnek |
|---|---|
| Delivered system | 12 lower-third state + ticker + corner package teslim edildi |
| Operational result | Editörün değiştirebildiği kontrollü template oluşturuldu |
| Coverage | TR/EN responsive page states tamamlandı |
| Production impact | Tek source comp’tan tekrar kullanılabilir varyant sistemi kuruldu |
| Launch status | Canlıya alındı / yayında kullanıldı — gerçekten doğruysa |
8. Credits ve tools doğru yerde kullanılmalı
Tools case study’nin ana hikâyesi değildir. After Effects, Figma veya Illustrator kullanmış olman tasarım problemini tek başına çözmez. Tools küçük metadata alanında kalabilir; ekip üyeleri ve sorumluluklar ise contribution’ın anlaşılması için credits bölümünde daha önemlidir.
- Client / brand
- Kendi rolün
- Creative/Art Director varsa
- Developer/editor/3D/sound/copy katkıları varsa
- Tools — yalnız anlamlı olanlar
- Year / duration gerekiyorsa
9. Case study SEO sayfasıysa temel publishing hygiene’i unutma
Public case study gerçek bir URL ise title/meta, canonical, TR/EN alternate, descriptive image alt, structured data ve internal links gibi temel yayın katmanı da olmalı. Ama bu SEO yüzeyini hak etmesi için sayfanın bağımsız değeri bulunmalı; iki görsel + tek paragraf için ayrı indexable URL açmak thin project page üretir.
kadirozbek.com’da büyük case study publication gate bu nedenle gerçek bilingual copy, en az birkaç substantive bölüm ve birden fazla gerçek medya kanıtı bekliyor. Küçük tekil işler ayrı thin URL yerine Works lightbox içinde kalabiliyor.
Kadir Özbek case-study framework: yayından önce son kontrol
- Outcome görünür mü?
İlk ekran projenin ne ürettiğini gösteriyor mu?
- Context spesifik mi?
Generic marka hikâyesi yerine tasarım şartları anlaşılıyor mu?
- Contribution doğru mu?
Kendi rolün ve ekip katkıları ayrılmış mı?
- Challenge kopyalanabilir mi?
Başka projeye uyuyorsa daha spesifik yaz.
- Process kararları açıklıyor mu?
Dekoratif süreç değil design reasoning var mı?
- En az iki gerçek media evidence var mı?
Kapak dışında sistemi kanıtlayan içerik bulunuyor mu?
- Result doğrulanabilir mi?
Sahte KPI veya belirsiz başarı iddiası var mı?
- Credits eksiksiz mi?
Takım katkısı doğru temsil ediliyor mu?