IB Design Technology Internal Assessment (IA), toplam notunun büyük bir kısmını taşıyan, uzun soluklu bir tasarım projesi olduğu için konuyu rastgele seçmek çoğu öğrenciyi zor durumda bırakır. IA yaklaşık yüzde 40 ağırlığa sahip, uzun saatler süren atölye çalışması, araştırma, prototip üretimi ve rapor yazımı gerektirir, yani yanlış bir başlangıç tüm süreci yorucu ve dağınık hale getirebilir.
Üstelik güncel kılavuza göre proje, gerçek dünyadaki bir problemi çözmeli, design thinking adımlarını izlemeli ve fiziksel bir prototype içermelidir, bu da “sadece fikir” olan konuları hemen zayıflatır. Kısacası, güçlü bir IB Design Technology IA konusu, hem gerçek hayatta işe yarayan hem de IB kriterlerine sıkı sıkıya bağlı bir yapı istemektedir.
Bu yazıda, sana adım adım, hem IB kriterleriyle uyumlu hem de gerçekten uygulanabilir, test edilebilir ve yüksek not potansiyeli olan bir IA konusu seçme yolunu göstereceğim. Önce güçlü bir konunun özelliklerine bakacağız, sonra sıfırdan kendi problem cümleni oluşturacak bir yol haritasına geçeceğiz, en sonda da örnekler ve kısa bir kontrol listesiyle işi netleştireceğiz.
IB, 2027 syllabus güncellemesiyle Design Technology IA’yı açıkça design thinking sürecine bağladı ve SL ile HL için ortak kriterler tanımladı. Resmi yapıya, özellikle de değerlendirme kriterlerine göz atmak için CUNY tarafından paylaşılan IB Design Technology guide pdf’ine bakmak faydalı olur. Bu kılavuz, senden beklenen derinliği ve proje yapısını netleştirir.
Bugün pek çok öğretmen hâlâ eski dille Criterion A, B, C, D diye konuşuyor, yeni belgelerde ise Empathize, Define, Ideation and modelling, Designing a solution, Presenting a solution başlıklarını görüyorsun. Hangi isim kullanılırsa kullanılsın, güçlü bir konu aynı temel özellikleri taşır: gerçek ve dar bir problem, kullanıcı odaklılık, fiziksel prototype imkânı, sınırlı sürede yapılabilirlik ve tüm kriterleri besleyen bir yapısı bulunur.
Photo by Vanessa Loring
IA konusu ne kadar “genel” olursa, yazdığın analiz bölümü o kadar yüzeysel kalır. Buna karşın konu ne kadar somut, dar ve belirli bir bağlama bağlıysa, Criterion A içinde yapacağın problem analizi o kadar güçlü görünür.
Örneğin “Telefonu daha iyi yapmak” ifadesi neredeyse hiçbir şey söylemez, milyarlarca kullanıcı, sayısız özellik, binlerce senaryo içerir. Bu kadar geniş bir alanda kullanıcıyı anlamak, ihtiyaçları sınıflandırmak ve net bir tasarım hedefi koymak neredeyse imkânsız hale gelir. Sonuçta ya çok uzun ama dağınık bir rapor çıkar, ya da çok kısa ve yüzeysel bir çalışma ortaya çıkar.
Buna karşılık “küçük eller için ergonomik bir gaming mouse tasarlamak” oldukça net bir çerçeve sunar. Belirli bir kullanıcı grubu (küçük elli oyuncular), belirli bir kullanım senaryosu (uzun süreli oyun), belirgin bir sorun (ağrı, yorgunluk, kontrol zorluğu) ve ölçülebilir hedefler kurmana izin verir. Bu yapı, araştırma yapmayı, boyut ölçmeyi, ergonomi kriterleri belirlemeyi ve sonunda kullanıcı testleri yürütmeyi çok daha kolay hale getirir.
Bu nedenle IA konunu seçerken, tek bir kullanıcı grubu, tek bir çekirdek problem ve mümkünse tek bir ana kullanım senaryosu üzerinde durman güçlü bir başlangıç olur.
Güncel IB Design Technology IA yapısında “sadece teorik” bir proje neredeyse hiç şans tanımaz; öğrenciden açık bir şekilde fiziksel bir prototype ya da fidelity model üretmesi beklenir. Yalnızca bir mobil uygulama fikri, yalnızca bir web sitesi taslağı veya sadece kavramsal bir “akıllı şehir sistemi” genelde zayıf kalır, çünkü elinde test edebileceğin somut bir ürün olmaz.
Bu, yazılım hiç kullanamazsın anlamına gelmez; örneğin akıllı bitki sulama sistemi tasarlıyorsan, elektronik devreyle birlikte basılı kasa, sensörlerin yerleştiği fiziksel düzen ve gerçek bitkiler üzerinde test içeren bir prototype seni güçlü gösterir. Burada amaç, Criterion D ya da yeni isimle “Presenting a solution” bölümünde gerçek kullanıcılarla yapılan testleri, ölçümleri ve geri bildirimleri ayrıntılı şekilde gösterebilmenidir.
Prototipin gerçek kullanıcılarla buluştuğu anda, sadece “güzel bir fikir” değil, gerçekten işe yarayan veya kusurları olan bir çözüm sunmuş olursun. IB de tam olarak bu süreci görmek ister; neyin çalıştığını, neyin çalışmadığını, neleri geliştirmek istediğini sayılarla ve gözlemlerle anlatmanı bekler.
Eski yapıda Criterion A, B, C, D; yeni kılavuzda Empathize, Define, Ideation and modelling, Designing a solution, Presenting a solution başlıklarını görüyorsun. İsimler farklı görünse de, IA konusu aynı dört beş temel adımı desteklemek zorundadır.
Konu fikrine bakarken kendine dürüstçe şu soruyu sorman iyi olur: “Bu problem için rahatça birkaç farklı tasarım fikri üretebiliyor muyum, seçtiğim çözümü detaylı planlayabiliyor muyum ve sonunda somut testler yapabiliyor muyum?” Cevap içten bir “Evet” ise, doğru yoldasın.
Teoriyi bir kenara bırakıp pratiğe geçtiğinde, elinde gerçek bir yol haritası olması huzur verir. Design thinking sürecindeki empathize, define, ideate, prototype, evaluate adımlarını, IA konusu seçerken de kullanabilirsin. Aşağıdaki adımlar, seni “hiç fikrim yok” noktasından, net ve yazılabilir bir problem cümlesine taşıyacak şekilde düzenlendi.
Amaç, önce geniş bir problem havuzu oluşturman, sonra bu havuzdan hem seni heyecanlandıran hem de IB kriterlerine uygun tek bir konuya inmen.
En sürdürülebilir IA konusu, hem seni ilgilendiren hem de çevrende gerçekten var olan bir problemden çıkar. Spor yaptığın salonu, okul çantanı, müzik ekipmanlarını, gaming set-up’ını, toplu taşımayı, mutfaktaki düzeni, hatta evcil hayvanının ihtiyaçlarını bile düşünebilirsin.
Kısa bir “problem avı” listesi hazırlamak iyi bir başlangıç olur. Bir hafta boyunca, seni ya da çevrendekileri rahatsız eden, zaman kaybettiren, konforu bozan her durumu not al. Kullanıcı olarak kendini, aileni, arkadaşlarını, öğretmenlerini ve okul topluluğunu düşün. Amacın, 10–15 satırlık kabaca yazılmış bir problem havuzu oluşturmak, bu aşamada çözüm düşünmek zorunda değilsin.
Bu listeyi ne kadar dürüst ve çeşitli yazarsan, ileride seçeceğin IA konusu o kadar doğal ve ikna edici görünür.
Design thinking’in ilk adımı olan empathize, kullanıcıyı gerçekten anlamaya çalışmaktır; IA içinde de bu adım Criterion A’ya doğrudan güç verir. Sadece kendi fikrine güvenmek yerine, küçük röportajlar, basit anketler ve gözlemler kullanarak veri toplaman beklenir.
Kullanıcıya şu tarz sorular sormak işini kolaylaştırır: “Bu ürünü kullanırken en çok ne seni rahatsız ediyor?”, “Günde kaç kere bu sorunla karşılaşıyorsun?”, “Şu an kullandığın çözüm neden işini tam olarak görmüyor?” Gözlem yaparken, kullanıcıların ürünü nasıl tuttuğunu, ne kadar süre kullandığını, nerede zorlandığını ayrıntılı not al.
Bu veriler, hem problem tanımını somutlaştırır hem de ileride yazacağın raporda gerçek alıntılar ve istatistikler kullanmana yardımcı olur.
Topladığın verilerden sonra, artık net bir problem cümlesi yazman gerekir. IB tarzına uygun, açık ve ölçülebilir bir yapı için şu İngilizce şablon çok iş görür:
For [belirli kullanıcı grubu] who [belirli ihtiyaç ya da sorun], there is a need for [ürün türü] that [ölçülebilir fayda].
Türkçe olarak bu cümlede bağlam (context), kullanıcı grubu, ihtiyaç ve kısıtlar bulunmalıdır. Örneğin: “Günde en az 4 saat bilgisayar oyunu oynayan, küçük elli lise öğrencileri için, bilek ve parmak yorgunluğunu azaltan, elde kaymayan bir gaming mouse tasarımına ihtiyaç vardır.”
Böyle bir cümle, hem sana hem öğretmenine projeyi çok net gösterir. IA raporunun giriş bölümünde bu cümleyi kullanmak, tüm tasarım döngüsünü aynı hedefe bağlamanı sağlar.
Criterion B, senden sadece “tek iyi fikir” beklemez; farklı tasarım yönlerini araştırmanı, avantaj ve dezavantajlarını karşılaştırmanı ister. Eğer seçtiğin problem yalnızca tek bir açık cevaba sahipse, IA için zayıf bir alan seçmiş olabilirsin.
Kendine küçük bir test yapabilirsin: Seçtiğin problem için 10 dakika içinde en az 3 farklı ürün fikri taslağı çizmeye çalış. Bunların hepsi mükemmel olmak zorunda değil, ancak farklı yaklaşımlar içermeli; örneğin farklı mekanizmalar, farklı form faktörleri veya farklı malzemeler. Eğer bu sayıyı bile çıkaramıyorsan, konu çok dar, yanlış tanımlanmış ya da sana ilham vermiyor olabilir.
Birden fazla fikir üretebildiğin problem alanları, hem daha yaratıcı IA’lar üretmene yardım eder hem de raporunda “design iterations” kısmını güçlendirir.
IA için önerilen süre, SL öğrencileri için yaklaşık 40 saat, HL öğrencileri içinse 60 saat civarındadır; bu süre toplam proje süresini, araştırmayı, tasarımı, prototip üretimini ve rapor yazımını içerir. Bu yüzden konu seçerken, okul atölyeni, sahip olduğun makineleri, malzemeleri, bütçeni ve öğretmen desteğini gerçekçi biçimde düşünmen gerekir.
Şu mini fizibilite kontrolünü her potansiyel konu için yapabilirsin: “Bu ürünün en az bir işlevsel prototipini gerçekten üretebilir miyim?”, “Hedef kullanıcıya test için ulaşabilir miyim?”, “Başarıyı sayılarla ölçebileceğim parametreler bulabiliyor muyum?”, “Güvenlik veya okul politikaları açısından risk var mı?” Soruların çoğuna net bir “Evet” diyebiliyorsan, konu pratik açıdan da sağlıklı görünür.
Bu noktada, IA’nın Extended Essay gibi çok uzun bir araştırma metnine dönüşmediğini, ama Grade Boundary üzerinde ciddi etkisi olan pratik bir proje olduğunu kendine hatırlatmak iyi olur.
Kendine ait bir fikir bulmak bazen soyut kalır, bu yüzden somut örnekler görmek düşünceni netleştirir. Aşağıdaki örnekler, birebir kopyalaman için değil, kendi bağlamına uyarlayabileceğin örüntüler göstermek için yazıldı. Konunu seçerken, bu örneklerle kendi fikrini karşılaştırman faydalı olur.
İstersen, yayınlanmış bir öğrenci çalışmasına bakmak için Academia.edu üzerindeki IB Design Technology SL Internal Assessment örneğini inceleyebilir, kapsam ve derinliğin nasıl dengelendiğini görebilirsin.
Örnek 1: Ergonomik solak gaming mouse
Kullanıcı: Solak, uzun süre oyun oynayan lise öğrencileri.
Problem: Piyasadaki çoğu mouse sağ ellilere göre tasarlandığı için solak kullanıcılar elde ağrı, kontrol kaybı ve düşük performans yaşıyor.
Prototip ve test: 3D printed gövde, farklı kavrama şekilleri için birkaç varyasyon, oyun sırasında performans ölçümleri ve “comfort rating” anketleriyle test edilebilir.
Örnek 2: Farklı bisiklet tiplerine uyumlu sürdürülebilir şişe taşıyıcı
Kullanıcı: Şehir içi ve off-road bisiklet kullanan üniversite öğrencileri.
Problem: Farklı kadro kalınlıklarında aynı şişe taşıyıcıyı kullanmak zor, mevcut ürünler hem sallanıyor hem de bazı bisikletlere hiç uymuyor.
Prototip ve test: Geri dönüştürülebilir malzeme kullanarak ayarlanabilir mekanizmalı bir taşıyıcı üretilebilir, farklı bisiklet tiplerinde, farklı yol koşullarında titreşim ve dayanıklılık testleri yapılabilir.
Örnek 3: Ev için otomatik bitki sulama sistemi
Kullanıcı: Yoğun programı olan, sık seyahate çıkan aileler.
Problem: Uzun süre evden uzak kalındığında saksı bitkileri düzensiz sulama nedeniyle kuruyor ya da çürüyor.
Prototip ve test: Nem sensörlü, zamanlayıcılı bir sistem, 3D printed su deposu ve hortum düzeniyle kurulabilir; farklı toprak tiplerinde nem değerleri takip edilerek sistemin başarısı sayısal olarak ölçülebilir.
Bu örneklerin ortak noktası, net bir kullanıcı grubu, gerçek bir bağlam, üretilebilir bir prototype ve uygulanabilir test senaryoları sunmalarıdır. Kendi fikrini yazarken “Benim konumda da bu dört özellik var mı?” diye sorman işe yarar.
Bazı konular kağıt üzerinde etkileyici görünse de, IA kriterleri karşısında hızla zayıflar. En sık görülen örneklerden biri “daha iyi bir telefon tasarlamak” tarzı, ucu açık ve aşırı geniş hedeflerdir. Bu tip bir konuda, hangi kullanıcıya odaklandığını, neyi ölçtüğünü ve hangi prototipi üreteceğini netleştirmek çok zor hale gelir.
Benzer şekilde, “hayali bir geleceğin arabası” gibi sadece konsept çizimlerine dayanan, gerçek kullanıcı verisi içermeyen ve fiziksel modele dönüşmeyen fikirler de risklidir. Sadece estetik değişiklikler yapmak, yani formu değiştirmek ama işlevi geliştirmemek, IB gözünde zayıf bir tasarım süreci anlamına gelir.
Yaygın hataları şöyle özetleyebiliriz:
Eğer fikrini anlatırken sürekli “ileride”, “gelecekte”, “teorik olarak” demek zorunda kalıyorsan, muhtemelen IA için fazla soyut bir alandasın ve konunu gerçek dünyaya daha sıkı bağlaman gerekir.
Konu fikrini neredeyse seçmiş durumda olabilirsin, ancak son bir filtre uygulamak çoğu hatayı erken fark etmeni sağlar. Bu bölümdeki soruları hızlıca taramak, hem IB kriterleri hem de pratik uygulanabilirlik açısından sana net bir “go/no-go” sinyali verir.
Aşağıdaki her soruya içtenlikle “Evet” diyebiliyorsan, konun büyük ihtimalle sağlamdır:
En azından bu soruların büyük çoğunluğuna net bir “Evet” veremiyorsan, konunu biraz daha daraltman, yeniden tanımlaman ya da tamamen farklı bir problem alanına yönelmen daha güvenli olabilir.
Konuya sen alıştıkça, bazı zayıflıkları görmez hale gelebilirsin; bu yüzden IA konunu kilitlemeden önce kısa bir “pitch” hazırlamak işe yarar. Design Technology öğretmenine ve hedef kullanıcı grubundan bir iki kişiye, 2–3 cümleyle şu üç noktayı anlatmayı dene: Problem ne, kim etkileniyor, sen ne tür bir ürün tasarlamayı planlıyorsun.
Bu küçük egzersiz, hem kafandaki boşlukları ortaya çıkarır hem de rapor yazarken giriş kısmını çok daha hızlı yazmana yardım eder. Ayrıca öğretmenin yorumları, konunun Grade Boundary açısından ne kadar güvenli olduğunu anlaman için de değerli olur.
Güçlü bir IB Design Technology IA konusu, sihirli bir ilham anından çok, bilinçli bir seçim ve iyi yapılandırılmış bir düşünme sürecinin sonucudur. Gerçek ve dar bir problem, kullanıcı odaklılık, fiziksel prototype üretme ve test edebilme, zaman ve malzeme sınırlıklarıyla uyum ve IB kriterlerine net bağlantılar, başarılı bir projenin temel taşlarını oluşturur.
Başlangıçta konu seçmeye biraz daha zaman ayırmak, IA sürecinin geri kalanını çok daha akıcı ve kontrollü hale getirir; bu da hem stresi azaltır hem de yüksek not potansiyelini artırır. Daha fazla örnek görmek veya kriterleri yorumlama konusunda derinleşmek istersen, kendi okulunun Design Technology öğretmeninin önerdiği kaynaklara ve güvenilir .edu alan adlı akademik sitelere bakman iyi bir sonraki adım olur.
Kendi problem cümleni kurup içten bir “Bu proje hem bana hem kullanıcılara gerçekten fayda sağlayacak” diyebildiğin anda, IA sürecine sağlam bir başlangıç yapmış olursun.
Bir ormanın kesilmesine “evet” ya da “hayır” demek kolay görünebilir, ama IB Environmental Systems and Societies (ESS) içinde önemli olan kararın kendisi değil, neden o
Bir nehri kirleten fabrikanın bacası sadece duman mı çıkarır, yoksa görünmeyen bir fatura da mı üretir? IB ESS’de environmental economics, tam olarak bu görünmeyen faturayı
Bir nehre atılan atık, bir gecede balıkları öldürebilir, ama o atığın durması çoğu zaman aylar, hatta yıllar alır. Çünkü çevre sorunları sadece “bilim” sorusu değil,
Şehirde yürürken burnuna egzoz kokusu geliyor, ufuk çizgisi gri bir perdeyle kapanıyor, bazen de gözlerin yanıyor; bunların hepsi urban air pollution dediğimiz konunun günlük hayattaki
Şehir dediğimiz yer, sadece binalar ve yollardan ibaret değil, büyük bir canlı organizma gibi sürekli besleniyor, büyüyor, ısınıyor, kirleniyor, bazen de kendini onarmaya çalışıyor. IB
IB ESS Topic 8.1 Human populations, insan nüfusunun nasıl değiştiğini, bu değişimin nedenlerini ve çevre üzerindeki etkilerini net bir sistem mantığıyla açıklar. Nüfusu bir “depo”
Bir gün marketten eve dönüyorsun, mutfak tezgahına koyduğun paketli ürünlerin çoğu, aslında üründen çok ambalaj gibi görünüyor. Üstüne bir de dolabın arkasında unutulan yoğurt, birkaç
Evde ışığı açtığında, kışın kombiyi çalıştırdığında ya da otobüse bindiğinde aslında aynı soruyla karşılaşıyorsun, bu enerjiyi hangi kaynaktan üretiyoruz ve bunun bedelini kim ödüyor? IB
Bir musluğu açtığında akan su, markette aldığın ekmek, kışın ısınmak için yaktığın yakıt, hatta telefonunun içindeki metal parçalar; hepsi natural resources (doğal kaynaklar) denen büyük
Gökyüzüne baktığında tek bir “hava” var gibi görünür, ama aslında atmosfer kat kat bir yapı gibidir ve her katın görevi farklıdır. IB Environmental Systems and