Rehber

Yönetim sunumu nasıl tasarlanır?

Psikoloji araştırması, NASA'nın Columbia raporu ve erişilebilirlik kuralları ışığında karar aldıran bir yönetim sunumunun yapısı ve görsel ilkeleri.

Fratres Editör · 11 Kasım 2026

Yönetim sunumu, üst yönetimin kısıtlı bir toplantı süresinde karar vermesi için hazırlanan, ana mesajı başta söyleyen ve her slaytta tek bir fikri kanıtıyla gösteren belgedir. İyi tasarım süsle değil, yapıyla başlar: karar sorusu, öneri, gerekçe ve istenen onay. Görsel kurallar bu yapıya hizmet eder. Yazı okunur, kontrast yeterlidir, veri az ama doğrudur.

Yönetim sunumunu zorlaştıran ne?

Yönetici sunumu dinlerken aynı anda iki iş yapar: konuşmacıyı izler ve ekrandaki bilgiyi işler. İkisinin kapasitesi sınırlıdır. Kosslyn ve ekibinin Frontiers in Psychology'de yayımlanan 2012 çalışması, algı ve bellek araştırmalarından sekiz iletişim ilkesi çıkardı ve internetten seçilen 140 slayt gösterisini bu ilkelere göre puanladı. Tek bir gösteri bile kusursuz çıkmadı. Sınırlı kapasite ilkesi, yani izleyiciye aynı anda işleyebileceğinden fazla bilgi yüklememe kuralı, katı puanlamada gösterilerin tamamında ihlal edilmişti.

Aynı çalışmanın 205 katılımcılı anketinde hem en sık görülen hem de en çok rahatsız eden sorun, ana fikrin ilgisiz ayrıntılar arasında kaybolmasıydı. Konuşmacının slaytı kelimesi kelimesine okuması da en sık beş şikâyet arasındaydı. Yönetim sunumunun asıl sorunu yani estetik değil, seçimdir: Neyin slayta gireceğine karar vermek.

Bu sorunun ne kadar pahalıya mal olabileceğini en çarpıcı biçimde Columbia Kazası İnceleme Kurulu'nun Ağustos 2003 raporu gösterir. Raporda incelenen bir mühendislik slaytı, başlığında test verisinin temkinli bir tahmin sunduğunu söylüyordu. Oysa mekiğe çarpan parça, modelin dayandığı test verisinden 640 kat büyüktü, sonraki analizde bu fark 400 kat olarak hesaplandı. Kurul, bilgi hiyerarşide yukarı çıktıkça açıklamaların süzüldüğünü ve üst düzey bir yöneticinin bu slaytı okuyup hayati bir riskle karşı karşıya olduğunu fark etmeyebileceğini yazdı. Teknik raporlar yerine slaytların yaygın kullanımını da sorunlu iletişimin bir göstergesi saydı.

Sunumun omurgası nasıl kurulur?

Yönetim sunumunda sıra, araştırma raporunun tersidir. Yöntem ve veri sonra, sonuç önce gelir. Tipik bir omurga şöyle işler:

Karar sorusu: Bu toplantıda ne karara bağlanacak?
Öneri: Ekibin önerdiği seçenek, tek cümleyle.
Gerekçeler: Öneriyi taşıyan iki ya da üç kanıt.
Riskler ve seçenekler: Neden diğer seçenekler değil, neyi göze alıyoruz?
İstenen karar: Onay, bütçe, sorumlu ve tarih.

Bu omurga başlıklara yansır. "Satış performansı" bir konu başlığıdır, okura bir şey söylemez. "İkinci çeyrekteki düşüşün çoğu iki bölgedeki stok sorunundan geliyor" bir iddia başlığıdır ve slaytın geri kalanı bu cümleyi kanıtlar. Başlıkları alt alta okuduğunuzda sunumun hikâyesi çıkmalıdır. Columbia örneği, başlığın kanıtla çeliştiğinde ne kadar yanıltıcı olabileceğini de gösteriyor: Başlık, slaytın en çok okunan cümlesidir.

Bazı kurumlar bu yapıyı slayttan tamamen ayırır. Amazon'un 2017 hissedar mektubu, şirkette slayt sunumu yapılmadığını, toplantıların altı sayfalık anlatı biçimindeki bir notun sessizce okunmasıyla başladığını anlatır. Mektuba göre iyi bir not muhtemelen bir hafta veya daha uzun sürede yazılır. Her şirketin bu modele geçmesi gerekmez. Ama ayrıntılı gerekçeyi toplantıdan önce gönderilen kısa bir yazılı nota taşımak, slaytları karar akışına ayırmayı kolaylaştırır.

Yönetim sunumu adım adım nasıl hazırlanır?

Karar sorusunu tek cümleyle yazın. Yazamıyorsanız sunum henüz hazır değildir.
Dinleyiciyi tanımlayın. Kosslyn'in ilkelerinden biri, iletişimin dinleyicinin önceden bildiği kavramlara dayanmasıdır. Kurul üyelerinin hangi kısaltmaları, hangi metrikleri bildiğini not edin.
Slayt açmadan başlıkları yazın. Bir belgede yalnız iddia başlıklarını sıralayın ve kurguyu orada düzeltin.
Her başlık için tek kanıt seçin. Bir grafik, bir sayı ya da kısa bir karşılaştırma. Grafik seçiminde veri görselleştirme hataları iyi bir kontrol listesi sunar.
Ayrıntıyı eke taşıyın. Sorulursa açacağınız yöntem, kırılım ve tablolar ana akışın dışında dursun.
Görsel kuralları uygulayın. Aşağıdaki bölümdeki okunabilirlik ve kontrast sınırlarını şablona işleyin.
Ön okuma notunu gönderin. Karar sorusu, öneri ve temel rakamlar toplantıdan önce dinleyicide olsun.
Süreyle prova yapın. Sunumu ayrılan sürenin yarısında bitirecek biçimde planlayın, kalan zaman soruya kalsın.

Kurumsal şablon, grafik dili ve yönetim kurulu sunumu düzeni gibi işler sunum tasarımı kapsamında bir kez kurulursa her ekip sıfırdan başlamaz.

Slaytta hangi görsel kurallar geçerli?

Okunabilirlik. Microsoft'un PowerPoint erişilebilirlik rehberi, 18 punto veya daha büyük yazı, Arial ya da Calibri gibi tırnaksız (sans serif) yazı tipleri ve yeterli boşluk öneriyor. Tamamı büyük harfle yazılmış satırlardan ve aşırı italikten kaçınmayı söylüyor. Yazıyı sola hizalamak da aynı rehberin önerisi.

Kontrast. W3C'nin WCAG 2.2 ölçütü, metin ile arka plan arasında en az 4.5:1 kontrast oranı ister. 18 punto ve üzeri ya da 14 punto kalın yazı büyük metin sayılır ve 3:1 ile yetinir. Bu ölçüt web için yazıldı, ama slaytta da güvenilir bir alt sınırdır. Toplantı odasının ışığında ekran ekranınızdakinden soluk görünebileceği için sınırın üstünde kalın.

Renk tek başına anlam taşımasın. Microsoft, anlamı yalnız renkle vermemeyi öneriyor. Kırmızı ve yeşil çubukların yanına değeri ya da kısa bir etiket ekleyin.

Tek vurgu. Kosslyn'in belirginlik ilkesine göre dikkat en büyük farka gider. Slaytta tek bir şeyi en belirgin yapın: önerinin dayandığı rakamı veya grafikte ilgili seriyi. Bilgilendirici değişim ilkesine göre de izleyici her biçim değişikliğini yeni bir bilgi sanar. Renk, yazı tipi ve yerleşimi sunum boyunca sabit tutun.

Başlık ve okuma sırası. Microsoft her slayta benzersiz bir başlık vermeyi, görsellere alternatif metin eklemeyi ve erişilebilirlik denetleyicisini çalıştırmayı öneriyor. Sunum e-postayla dolaşacaksa bu adımlar ekran okuyucu kullanan bir yöneticinin de belgeyi izleyebilmesini sağlar.

Sık yapılan hatalar

Slaytı okumak. Yazılı metni sesli tekrarlamak dinleyiciye yeni bir şey söylemez. Slaytta kanıt, sözde yorum olsun.
Sonucu sona saklamak. Yönetici ilk beş dakikada öneriyi duymazsa soruları yönteme yönelir.
Konu başlığı kullanmak. "Pazar analizi" başlıklı bir slayt, okuru ne düşüneceğini kendi bulmaya zorlar.
Her şeyi tek slayta sığdırmak. Yazı küçülür, vurgu kaybolur. İki slayta bölmek çoğu zaman daha kısa sürer.
Ekteki ayrıntıyı ana akışa koymak. Kırılım tabloları soru gelirse açılmak üzere ekte bekler.
Her slaytta farklı biçim. Değişen renk ve yerleşim izleyiciyi yeni bilgi aramaya yöneltir.
Ekipmanı denememek. Kosslyn ekibinin anketinde katılımcıların yaklaşık %61'i, sunumların en azından bir kısmının konuşmacının ekipmanı kullanamaması yüzünden aksadığını bildirdi. Bağlantıyı, ekran oranını ve uzaktan katılımcının görüntüsünü toplantıdan önce kontrol edin.

Sunumun işe yarayıp yaramadığı nasıl ölçülür?

Yönetim sunumunun başarısı alkışla değil, kararla ölçülür. Kosslyn çalışmasının üçüncü bölümü, izleyicilerin bir slayttaki ilke ihlalini fark etmekte pek isabetli olmadığını gösterdi. Bu yüzden kendi gözünüze güvenmek yerine şu ölçüleri kullanın:

Karar alındı mı? Toplantı sonunda istenen karar ile verilen karar aynı mı, kayda geçti mi?
Soru türü: Sorular öneriye itiraz mı, yoksa "bu grafik ne gösteriyor" gibi anlama sorusu mu? İkincisi tasarım sorunudur.
Süre: Planlanan sunum süresiyle gerçekleşen arasındaki fark.
Tek cümle testi: Toplantıdan sonra bir katılımcı önerinizi tek cümleyle doğru tekrar edebiliyor mu?
Başlık testi: Projede olmayan bir meslektaş yalnız başlıkları okuyup hikâyeyi anlatabiliyor mu?
Erişilebilirlik denetimi: PowerPoint'in denetleyicisinde çözülmemiş uyarı kalmadı mı?

Bu ölçüler sunum sunum not edilirse ekibin hangi alışkanlığı değiştirmesi gerektiği birkaç toplantıda görünür hâle gelir. Raporlamayı düzenli bir yönetim aracına çevirmek isteyenler için dashboard tasarım ilkeleri aynı mantığı ekrana taşır.

Bir sonraki sunumu başlıklarla başlatın

Yarın, hazırlamakta olduğunuz sunumun bütün slayt başlıklarını boş bir belgeye alt alta kopyalayın. Konu başlıklarını iddia cümlesine çevirin, karar sorusunu en üste yazın. Sonra bu listeyi projede olmayan birine okutun. Başlıklardan öneriyi ve gerekçesini çıkaramıyorsa, tasarıma geçmeden önce kurguyu düzeltin.