Bir 3D Projeyi Case Study'ye Nasıl Dönüştürüyorum?

Proje sayfası ile case study farkı

Bir proje sayfası ile case study arasında fark var. Proje sayfası ne yaptığını gösterebilir: birkaç iyi render, kısa bir başlık, belki kullanılan araçların listesi. Case study ise neden yaptığını ve nasıl yaptığını anlatır. İlki vitrindir, ikincisi ise bir çalışma masasının üstüne eğilip bakmak gibi.

Bu ayrım 3D işlerde özellikle belirgin, çünkü 3D'nin çıktısı çoğu zaman tek bir görsele sığıyor ama o görselin arkasında onlarca küçük karar var. Hangi referanslara bakıldı, model neden o kadar ayrıntılı ya da o kadar sade tutuldu, malzeme hangi mantıkla kuruldu, ışık neden o yönden geliyor, dosya hangi formatta teslim edildi. Bunların hiçbiri tek bir render karesinden okunamaz. Okuyucu yalnızca sonucu görürse işi yapanın ne kadar düşündüğünü bilemez; sadece "güzel görünüyor" der ve geçer.

Case study'nin işi tam burada başlıyor: görünmeyen düşünce işini görünür kılmak. Bu yazıda bir 3D projeyi proje sayfasından case study'ye taşırken izlediğim soruları, kurduğum yapıyı ve sık yapılan hataları anlatıyorum.

Case study kimin için yazılır?

Yazmaya başlamadan önce kimin okuyacağını belirlemek metnin tonunu ve derinliğini değiştirir. Üç tipik okuyucu düşünüyorum.

• Potansiyel müşteri: Teknik ayrıntıdan çok, işin hangi probleme çözüm olduğunu ve süreçte neyle karşılaşacağını anlamak ister. Teslim edilen şeyin ne olduğu, kimin neyi karar verdiği ve işin nasıl ilerlediği onun için önemlidir.
• Meslektaş ya da işe alım yapan kişi: Karar verme biçimine bakar. Hangi alternatifler değerlendirildi, neden biri seçildi, hata nerede yapıldı ve nasıl düzeltildi?
• Öğrenmeye çalışan biri: Yöntemin tekrar edilebilir olup olmadığına bakar. Adımlar ve gerekçeler yeterince açık mı?

Hepsini aynı anda tatmin etmeye çalışan bir metin genelde kimseye tam hitap etmez. Ben ana okuyucuyu müşteri ya da işe alım yapan kişi olarak seçip teknik detayı kısa, açılır bölümlerde ya da ayrı paragraflarda tutmayı tercih ediyorum. Böylece üst düzey hikâye akıcı kalıyor, merak eden detaya inebiliyor. Portfolyonun genel olarak neden önemli olduğu sorusu için freelance çalışırken portfolyo yazısına bakabilirsin.

Başlamadan önce topladığım malzeme

Case study'nin en büyük düşmanı, proje bittikten aylar sonra hafızadan yazmaya çalışmak. Süreçte ne yaptığını unutursun, kararların gerekçeleri silinir ve geriye sadece "güzel çıktı" kalır. Bu yüzden proje sürerken küçük bir süreç arşivi tutmak mantıklı.

Arşive neleri koyduğumu şöyle sıralayabilirim:

• Başlangıçtaki brief ya da ihtiyaç notları, özellikle kısıtlar (teslim formatı, hedef platform, zaman).
• Toplanan referanslar ve hangisinin neden seçildiği.
• İlk taslaklar: kaba blokout, wireframe, ilk malzeme denemesi.
• Dönüm noktası olan anların ekran görüntüleri; örneğin bir kararın değiştiği, bir sorunun çözüldüğü an.
• Beklenmedik sorunların kısa notları: ne oldu, neye bağlandı, nasıl çözüldü.
• Teslim edilen dosyaların listesi ve nerede kullanıldığı.

Bunlar için özel bir sistem gerekmiyor; proje klasöründe bir not dosyası ve "süreç" adlı bir alt klasör yeterli. Önemli olan, o an kısaca yazmak. Bir sorunu çözdüğün gün yazdığın iki satır, aylar sonra yazılan iki paragraftan çok daha dürüst ve ayrıntılı olur.

Sorduğum sorular

Ben bir projeyi case study yaparken problemi anlatmanın önemli olduğunu düşünüyorum. Çünkü çözüm, problem anlaşılmadan anlamlı olmaz. Kendime şu soruları soruyorum:

• Ne gerekiyordu?
• Model nerede kullanılacaktı?
• Hangi kısımlar zordu?
• Hangi yöntemi seçtim?
• Neyi değiştirdim?
• Sonuç ne oldu?

Bu altı soru ilk bakışta basit görünüyor ama her biri ayrı bir tuzağı işaret ediyor. "Ne gerekiyordu?" sorusu, işi yapma sebebini sorar; "güzel bir 3D model" bir ihtiyaç değil, bir çıktıdır. İhtiyaç, bir ürünün web sitesinde döndürülebilir biçimde gösterilmesi ya da bir ürün ailesinin tutarlı katalog görselleriyle sunulması gibi bir cümle olabilir. "Model nerede kullanılacaktı?" sorusu kısıtları ortaya çıkarır; web için hazırlanan bir model ile baskı kalitesinde bir render için hazırlanan model farklı kararlar gerektirir. Bu fark için 3D modelleme ile görselleştirme arasındaki fark yazısı faydalı olabilir.

"Hangi kısımlar zordu?" sorusu dürüstlük testidir. Her şeyin sorunsuz geçtiği bir hikâye hem inandırıcı değil hem de öğretici değil. "Hangi yöntemi seçtim?" ve "Neyi değiştirdim?" soruları ise karar mantığını gösterir; değiştirdiğin şey, ilk yaklaşımın neden yetmediğini de anlatır. "Sonuç ne oldu?" sorusunda ise abartıdan kaçınmak gerekiyor; bu konuya aşağıda ayrıca değineceğim.

Yapı önerisi

Bu soruları kabaca dört parçaya yerleştiriyorum: ihtiyaç ve kısıtlar, yaklaşım ve kararlar, zorluklar ve çözümler, sonuç ve öğrenilenler. Her bölümde bir görsel ya da kısa bir süreç çıktısı (wireframe, materyal denemesi, öncesi-sonrası) olması metni destekliyor. Böylece okuyucu sadece iddiayı değil kanıtı da görüyor.

Bu dört parçayı biraz açayım:

• İhtiyaç ve kısıtlar: Proje neydi, kim için ve nerede kullanılacaktı? Teslim formatı, hedef cihaz, ürün çeşitliliği, referans malzemenin kalitesi gibi sınırlar burada yazılır.
• Yaklaşım ve kararlar: Hangi iş akışını seçtin? Modelleme, malzeme, ışık ve teslim konusunda hangi alternatifler vardı ve neden birini seçtin?
• Zorluklar ve çözümler: Planın tutmadığı yerler. Sorunun ne olduğu, neden olduğu ve nasıl aşıldığı.
• Sonuç ve öğrenilenler: Ne teslim edildi, ne işe yaradı, bir sonraki projede neyi farklı yapardın?

Bu iskelet katı bir kalıp değil. Küçük bir proje için dört kısa paragraf yeterli olabilir; büyük bir projede her bölüm alt başlıklara bölünebilir. Ama sırayı korumak okuyucunun zihninde "problem, karar, engel, sonuç" zincirini kurar ve hikâyeyi takip etmeyi kolaylaştırır.

İhtiyaç ve kısıtlar bölümü nasıl yazılır?

Bu bölüm çoğu zaman en zayıf yazılan bölümdür, çünkü "belli olan" şeyleri yazmak gereksiz görünür. Oysa okuyucu senin bildiğin bağlamı bilmiyor. İyi bir ihtiyaç bölümü üç şeyi net söyler: ne yapılacaktı, nerede kullanılacaktı ve hangi sınırlar vardı.

Varsayımsal bir örnekle düşünelim: bir ürün için web sitesinde döndürülebilir 3D model gerekiyor. Bu cümle tek başına bile birçok kısıt taşır. Model web'de açılacağı için dosya boyutu sınırlı olmalı, mobil cihazlarda akıcı çalışmalı, malzemeler gerçek zamanlı motorda doğru görünmeli. Bunlar yazılmazsa, okuyucu neden düşük poligonlu bir model seçildiğini ya da neden belirli bir doku boyutunda durulduğunu anlamaz. Teknik tarafı merak ediyorsan web için poligon sayısı yazısı bu kısıtları ayrıntılı ele alıyor.

Bu bölümde dikkat edeceğim bir şey daha var: müşterinin ya da kendi hedefin ile fiili kısıtı ayırmak. "Gerçekçi görünmeli" bir hedeftir; "ürünün tüm renk seçenekleri aynı ışıkta tutarlı görünmeli" ise ölçülebilir bir kısıttır. İkincisi sonraki kararları daha iyi açıklar.

Kararları anlatmak

Yaklaşım ve kararlar bölümü case study'nin kalbi. Burada yapılan iş "şunu kullandım, bunu yaptım" listesi olmamalı. Liste, araçları anlatır; karar ise gerekçeyi. Fark şu: "Blender'da modelledim" bilgidir, "ürünün yüzeyleri sert kenarlı olduğu için bevel ağırlığını modelleme aşamasında kurdum, çünkü kenar parlaması render'da gerçekçiliğin büyük kısmını taşıyordu" ise karardır.

Kararları anlatırken şu kalıbı faydalı buluyorum:

• Seçenekler nelerdi? (En az iki.)
• Hangisini seçtim?
• Neden? (Kısıtlara bağla.)
• Bedeli neydi? (Her seçimin bir vazgeçtiği şey var.)

Bedeli yazmak, metni inandırıcı kılan en güçlü unsurlardan biri. "Bu yöntem hızlıydı ama ince bir ayrıntıyı feda ettim" cümlesi, okuyucuya yaptığın seçimin bilinçli olduğunu gösterir. Uygulamadaki yöntem seçimleri için, örneğin render motoru kararında, Eevee mi Cycles mı yazısındaki mantık bu kalıba iyi oturuyor.

Zorluklar ve çözümler

Her projede planın tutmadığı bir an vardır. Case study'de bu anı saklamak yerine öne çıkarmak, metni hem daha insani hem daha öğretici yapar. Ama burada da bir denge var: zorluğu dramatize etmek ya da sorunu olduğundan büyük göstermek yerine, ne olduğunu sakin ve net anlatmak daha güvenilir.

Bir zorluğu anlatırken şu sırayı kullanıyorum: belirti, neden, denenen çözümler, işe yarayan çözüm. Belirti, gözle görülen şeydir; örneğin bir malzeme beklediğinden mat ya da düz görünüyor. Neden, sorunun kaynağıdır ve çoğu zaman belirtinin hemen yanında değildir. Denenen çözümler bölümünde işe yaramayanları da kısaca yazmak değerlidir, çünkü okuyucu aynı yolda vakit kaybetmez. Son olarak işe yarayan çözümü, mümkünse bir öncesi-sonrası görselle birlikte gösteriyorum.

Bu bölümde "ders" cümlesini zorlamamak da önemli. Her sorundan evrensel bir hayat dersi çıkarmak gerekmez; bazen sadece "bu ayarı şu nedenle bu şekilde kurdum" demek yeterli.

Görsel kanıt seçimi

Case study'de görsel, süs değil kanıttır. Her bölümde şu soruyu soruyorum: bu görsel yazdığım cümleyi destekliyor mu? Destekliyorsa kalır, desteklemiyorsa güzel olsa bile çıkar.

İşe yarayan görsel türleri şunlar:

• Referans ile sonuç yan yana: Modelin neye benzemesi gerektiğini ve neye vardığını gösterir.
• Wireframe ya da topoloji görünümü: Modelin teknik temizliğini gösterir; özellikle web için optimize edilen işlerde anlamlıdır.
• Malzeme denemeleri: Aynı yüzeyin farklı ayarlarla nasıl göründüğü, karar sürecini somutlaştırır.
• Öncesi-sonrası: Bir sorunun çözüldüğü anı tek bakışta anlatır.
• Kısa süreç çıktısı: Ekran kaydından bir kare, bir node düzeni ya da sahne kurulumu.

Görsellerin altına kısa, açıklayıcı alt yazılar koymak da faydalı. "Soldaki ilk deneme, sağdaki son hali" gibi bir cümle bile görselin neden orada olduğunu söyler. Ayrıca erişilebilirlik için her görsele anlamlı bir alternatif metin yazmak hem ekran okuyucu kullananlara hem de arama motorlarına yardımcı olur.

Sonuç ve öğrenilenler bölümünde dürüst kalmak

Case study'nin sonunda en çok cazip gelen şey, sonucu büyütmek: "satışları artırdı", "müşteri çok memnun kaldı" gibi cümleler. Bunları ancak gerçekten ölçtüysen ve kanıtlayabiliyorsan yazmalısın. Kanıtlayamıyorsan, sonuç bölümünü yapılabilecek en dürüst biçimde kur: ne teslim edildi, nerede kullanılıyor, hangi ihtiyaç karşılandı, hangi kısıt aşıldı.

Örneğin Aura Reformer çalışmasında teslim edilenin 6 ürün ve 57 renk seçeneğinden oluşan, tutarlı bir görsel sistem olduğunu söylemek somut ve doğrulanabilir bir sonuçtur. Bunun arkasındaki yöntemi ise renk seçici yazısında ayrıca anlattım. Böyle bir sonuç cümlesi, "çok başarılı bir proje oldu" demekten çok daha fazla bilgi veriyor.

"Öğrenilenler" kısmında ise genel bir moral cümlesi yerine bir sonraki projede somut olarak neyi değiştireceğini yaz. Örneğin bir kontrol listesine ekleyeceğin bir madde, daha erken alacağın bir karar ya da baştan isteyeceğin bir girdi. Bu, hem okuyucuya değer katar hem de senin için gerçek bir iyileştirme kaydı olur.

Üretim hikâyesi

Bunlar anlatıldığında proje sadece güzel bir görsel olmaktan çıkıyor. Bir üretim hikâyesine dönüşüyor. Bu da benim için daha değerli. Çünkü hikâye, tek bir render'ın aksine tekrar kullanılabilir: aynı süreçten bir blog yazısı, bir sosyal medya anlatısı, bir kısa video ya da bir teklif görüşmesinde gösterilecek örnek çıkarılabilir. Bir projeden birçok farklı içerik çıkarma yaklaşımımı ayrı yazıda anlattım; örnek bir proje için Aura Reformer sayfasına bakabilirsin.

Hikâyenin bir başka faydası, potansiyel müşteriyle konuşmayı kolaylaştırması. Bir müşteri "siz nasıl çalışıyorsunuz?" diye sorduğunda, süreci soyut anlatmak yerine gerçek bir projenin kararlarını gösterebilirsin. Süreç aşamalarının genel çerçevesi için brief'ten teslime 8 aşama yazısına, hizmetin kapsamı için 3D ürün modelleme sayfasına göz atabilirsin.

Çünkü yaptığım işin arkasındaki düşünme süreci görünür hale geliyor.

Yaygın hatalar

Case study yazarken sık gördüğüm hataları kısaca toparlayayım:

• Sadece araç listesi yazmak: "Blender, Substance, Photoshop kullandım" tek başına bir hikâye değil.
• Problemi atlamak: Doğrudan çözüme girmek, çözümün değerini görünmez yapar.
• Her şeyi anlatmak: Okuyucunun dikkati sınırlı. En önemli üç dört kararı seçip derinleştirmek, yirmi kararı yüzeysel geçmekten iyidir.
• Kanıtsız iddia: "Çok daha hızlı oldu" gibi ölçülmemiş ifadeler güveni azaltır.
• Müşteri bilgilerini dikkatsiz kullanmak: İzin almadan marka adı, ürün detayı ya da yayınlanmamış görsel paylaşmak hem etik hem hukuki sorun yaratabilir.
• Metinsiz görsel yığını: Görsel galerisi bir proje sayfasıdır, case study değil.
• Sonu belirsiz bırakmak: Okuyucu "peki sonra ne oldu?" diye kalmamalı.

Yayınlamadan önce kontrol listesi

Bir case study'yi yayına almadan önce şu listeden geçiyorum:

• Problem ilk bir iki paragrafta anlaşılıyor mu?
• Kısıtlar açıkça yazılmış mı?
• En az üç karar, seçenekleri ve gerekçesiyle anlatılmış mı?
• Bir zorluk ve çözümü var mı, sorun net tarif edilmiş mi?
• Her bölümde en az bir görsel ya da süreç çıktısı var mı ve her görselin bir amacı var mı?
• Sonuç bölümünde kanıtlayamayacağım bir iddia kalmış mı?
• Müşteri ya da marka kaynaklı paylaşım izinleri tamam mı?
• İlgili diğer içeriklere ve hizmet sayfasına bağlantı verilmiş mi?
• Okuyucu sonunda ne yapacağını biliyor mu? (İletişim, teklif ya da başka bir yazı.)

Son maddeyi önemsiyorum: iyi bir case study okuyucuyu yalnızca ikna etmekle kalmaz, bir sonraki adımı da gösterir. Bir proje için konuşmak istiyorsan teklif sayfası bu adımın doğal yeri olabilir.

Sık sorulan sorular

Sonuç

Proje sayfası işin ne olduğunu gösterir, case study ise neden ve nasıl yapıldığını. Problemi net koymak, kararları gerekçeleriyle anlatmak, zorluğu sakin ve dürüst aktarmak ve her iddiayı görselle desteklemek bir projeyi üretim hikâyesine çeviriyor. Süreç arşivini proje sürerken tutmak bu işi çok kolaylaştırıyor. Sonunda ortaya çıkan metin hem portfolyoda hem de müşteri görüşmelerinde işe yarayan, tekrar tekrar kullanılabilir bir varlık oluyor.

İlgili çalışmaAura ReformerÜrün Modelleme · Müşteri Çalışması · Blender · EEVEE · 6 ürün