--- title: "Prototip nedir?" author: Androverse author_url: https://androverse.com.tr/yazar/androverse publisher: Androverse updated_at: 2026-10-15 url: https://androverse.com.tr/sozluk/prototip language: tr --- # Prototip nedir? Prototip, bir ürün fikrinin akışını veya etkileşimini gerçek ürün tamamlanmadan denemeye yarayan temsildir. Diğer adlar: Prototype. ## Nerede işine yarar? Amaç, her özelliği geliştirmekten önce bir kararın kullanıcı açısından nasıl çalıştığını görmektir. Kapsam, test sorusuna göre seçilir. Tıklanabilir tasarım ile kodla çalışan örnek farklı ayrıntıları ortaya çıkarır; hangisinin gerektiği araştırılacak soruya bağlıdır. ## Bir cümlede uygulaması Bir rezervasyon akışında tarih seçimi ve hata mesajını tıklanabilir örnekle test etmek. ## Neyle karıştırılmamalı? Prototip yayına hazır ürün değildir; test ettiği varsayım ve içermediği özellikler açık olmalıdır. ## Üretmeden önce bir soruyu deneyelim Bir mobil uygulamada kişi günlük durumunu kaydedip önceki kayıtlarına bakacak. Ekranları çizmek, bu akışın anlaşılır olduğunu göstermeye yetmez. Seçimin nasıl yapıldığı, kaydın hangi anda tamamlandığı ve geçmişe nasıl dönüldüğü birlikte denenmelidir. Prototip, bu davranışı bütün ürünü geliştirmeden görünür kılan bir temsil olabilir. Temsilin ayrıntısı, cevaplamak istediğimiz soruya göre seçilir. Örneğin temel akışı konuşmak için birbirine bağlı birkaç tasarım ekranı yeterli olabilir. Klavye davranışını, gerçek metin girişini veya tarayıcı performansını değerlendirmek istiyorsak çalışan bir kod örneği gerekebilir. Her durumda prototipin neyi temsil ettiğini ve neyi temsil etmediğini açık söylemek gerekir. Tıklanabilir görünen her yüzeyin gerçek veri işlediğini varsaymak, paydaşlarda yanlış bir tamamlanmışlık hissi yaratabilir. Bu senaryoda önce yalnız bir kayıt oluşturma görevini ele alırız. Kişiden hangi ekrana basacağını söylemeden ilerlemesini ister, duraksadığı noktaları kaydederiz. Aynı denemede hem bütün görsel dili hem bütün ürün stratejisini değerlendirmeye çalışmayız. Prototip bir gösteri videosu değil, karar vermek için kullanılan çalışma nesnesidir. Değiştirmesi kolay olması, gerektiğinde fikri terk edebilmemizi de sağlar. Bir prototipin teknik olarak çok sınırlı olması, denemenin değersiz olduğu anlamına gelmez. Önemli olan sınırların öğrenme sorusunu çarpıtmamasıdır. Gerçek uygulamada otomatik doldurulacak alan prototipte elle giriliyorsa katılımcının zorlanması başka bir soruna işaret ediyor olabilir. Benzer biçimde ağ gecikmesi taklit edilmiyorsa hızlı geçiş, ürünün gerçek performansını kanıtlamaz. Gözlem notlarında temsilin bu sınırlarını açık tut. Tasarımın anlaşılmasıyla teknik yanıt süresini aynı sonuç gibi yorumlamadan, her birini uygun yöntemle ele al. Prototipte mümkün olmayan inceleme için sonraki aşamaya ayrı bir soru bırak. Prototip paylaşıldığında yönlendiren sunum metni yerine kısa bir kullanım bağlamı eklemek yararlıdır. Görüntüyü izleyen kişi hangi rolü üstleneceğini ve ne yapmak istediğini bilmeli, fakat çözümün yolunu baştan öğrenmemelidir. Deneme sonrasında yalnız tercih ettiği ekranı sormak yerine kararını hangi bilginin etkilediğini konuş. Bazen kişi arayüzü beğenir ama önemli bir koşulu hiç fark etmemiştir. Bu ayrımı görmek, final tasarımın hangi bilgiye daha fazla alan ayırması gerektiğini gösterir. Prototipin başarısı, herkesin onay vermesi değil, önemli belirsizliklerin daha açık hale gelmesidir. Gerekirse seçilen fikir de bu öğrenmeyle değişir. ### Soru Prototipi açmadan önce neyi öğrenmek istediğini yaz. Kullanıcı seçimi anlıyor mu, geri dönüş yolunu buluyor mu veya yeni durumun oluştuğunu görüyor mu? Belirsiz bir 'nasıl olmuş' sorusu çok dağınık geri bildirim üretir. Denemenin amacı, temsilin kapsamını ve ayrıntısını belirlemelidir. ### Gerçeklik seviyesi Yalnız görsel geçiş gösteren prototiple gerçek veri kullanan uygulama aynı şey değildir. Hangi alanların çalıştığını, hangi sonuçların örnek olduğunu ve nelerin henüz bulunmadığını belirt. Bu açıklama özellikle sunumlarda gereklidir; görsel bitmişlik, geliştirme işinin bittiği izlenimini vermemelidir. ### Öğrenme kaydı Denemeden sonra yalnız beğenilen ekranları kaydetme. Hangi varsayımın desteklendiğini, hangi sorunun açık kaldığını ve hangi değişikliğin önerildiğini yaz. Bir sonraki sürümün neden değiştiği anlaşılmalı. Prototip arşivi, gerekçesi kaybolmuş dosya sürümleri yığınına dönüşmemelidir. ## Prototip ile ilk ürün sürümü ### Bir davranışın temsili Prototip belirli bir fikri veya akışı anlamak için hazırlanır. Veri, güvenlik, bakım ve bütün uç durumlar gerçek üründeki gibi çözülmemiş olabilir. Deneme için yeterli olan temsil, yayın için yeterli değildir. Hangi sınırların bulunduğu açıkça yazıldığında ekip yanlış beklenti oluşturmadan hızlı öğrenebilir. ### Gerçek kullanımın sorumluluğu Yayımlanan ürün gerçek veriler, hatalar, farklı cihazlar ve kullanıcının beklentileriyle karşılaşır. Prototipte öğrenilen kararların uygulamaya taşınması gerekir; bu taşıma yalnız ekranları kopyalamak değildir. İş kuralları, erişilebilirlik, performans ve geri dönüş davranışları üretim kapsamına dahil edilir. Prototip bu işi azaltabilir, fakat bütünüyle ortadan kaldırmaz. ## Prototipin doğrulayacağı soruyu seçmek Prototip üretmeden önce hangi belirsizliği azaltacağını belirlemek gerekir. Menü bulunabiliyor mu, bir geçiş anlaşılıyor mu, ödeme akışı tamamlanabiliyor mu? Bir prototip her şeyi gerçekçi göstermek zorunda değildir; test edilen davranışı yeterince doğru temsil etmesi önemlidir. - Denenecek senaryo ve görevleri yaz. - Gerçek olmayan veri veya davranışları not et. - Gözlemleri üretim kararlarına dönüştür. ## Prototip hazırsa uygulama da hazır mı? Hayır. Prototipte veri güvenliği, kalıcı kayıt, gerçek servis bağlantısı ve hata yönetimi bulunmayabilir. Üretime geçişte hangi parçaların yeniden geliştirileceği ve hangi davranışların korunacağı açıkça ayrılmalıdır. ## Bu karar, işinin neresinde? Prototip kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. [Mobil uygulama](https://androverse.com.tr/hizmetler/mobil-uygulama-tasarim) ## Karar masası ### En ayrıntılı prototip her zaman daha iyi mi? Ayrıntı öğrenmek istediğin soruya hizmet etmiyorsa gereksiz emek yaratabilir. Basit bir akış kararını konuşmak için gerçekçi gölgeler ve uzun animasyonlar gerekmez. Buna karşılık hareketin anlamını veya giriş davranışını incelemek için daha gerçekçi bir temsil yararlı olabilir. Ayrıntı seviyesini kalite yarışı gibi düşünme. Soruyu cevaplayacak kadar gerçek, değiştirmeyi zorlaştırmayacak kadar esnek bir çalışma kurmaya çalış. ### Prototipte kullanıcıya ne söylenir? Görevi ve gerekli bağlamı anlat, çözüm yolunu tarif etme. Örneğin 'mavi düğmeye bas' yerine kişinin yapmak istediği işi söyle. Prototipin eksik veya örnek alanları varsa bunları baştan açıkla; eksik teknik davranışı tasarım hatası gibi yorumlama. Gözlem sırasında yönlendiren ipuçları vermekten kaçın. Kişi zorlandığında hemen kurtarmak yerine nerede ve neden durduğunu anlamaya alan bırak. ### Deneme sonucu bütün kullanıcılar için geçerli mi? Katılımcıların kim olduğu, kullanılan görevler ve prototipin sınırları sonucu etkiler. Küçük bir deneme yararlı sorunlar ortaya çıkarabilir, fakat evrensel başarı yüzdesi üretmez. Bulguları gözlem koşullarıyla birlikte aktar. Bir katılımcının tercihini doğrudan ürün kuralına çevirmeden başka kanıtlarla karşılaştır. Çelişkili geri bildirimler varsa hepsini aynı ekrana eklemek yerine, farklı kullanım ihtiyaçlarını ayırmaya çalış. ## Prototipe bir sınır çiz Ürünündeki tek bir akışı seç ve henüz emin olmadığın bir soruyu yaz. Prototipi bu soruyu cevaplayacak kadar kur. Bütün ürünü taklit etmek yerine neyi öğrenmek istediğini görünür tut. - [ ] Görevin başlangıç ve bitiş durumunu tanımla. Aradaki ekranların yalnız gerekli olanlarını ekle. Ana soruyla ilişkisi bulunmayan ayrıntıları kapsam dışında not et. Böylece eksik görünen her şeyi tamamlamaya çalışırken denemenin amacını kaybetmezsin. - [ ] Gerçekçi içerik ve anlaşılır kontrol adları kullan. Uydurma kısa metinler gerçek kullanım yükünü saklayabilir. Sonuç ekranında neyin değiştiğini göster; yalnız geçiş animasyonu ile işlemin tamamlandığını ima etme. Kişinin hangi bilgiyi taşıması gerektiğini düşün. - [ ] Görevi birine verip izlediği yolu kaydet. İdeal yolundan farklı bir yolu seçmesi mutlaka hata değildir. Kullanıcının beklentisi ile prototipin sunduğu ilişkileri karşılaştır. Nerede geri döndüğünü ve hangi bilgiyi tekrar aradığını özellikle not al. - [ ] Bulguları değişiklik kararına bağla. Her notu aynı anda uygulamak yerine ana soruya etkisine göre sırala. Yeni sürümde hangi varsayımın değiştiğini belirt ve gereken noktada tekrar dene. Tasarımın görsel olarak bitmiş görünmesi, denemenin sonucundan daha önemli olmamalı. Prototip, bitmiş ürün sözü vermeden öğrenme alanı açar. Gücü ne kadar gerçekçi göründüğünde değil, hangi belirsizliği ne kadar açık biçimde tartışılabilir hale getirdiğindedir. ## Bağlantılı kavramlar - [Wireframe](https://androverse.com.tr/sozluk/wireframe) — Wireframe, bir ekranın içerik ve işlev yerleşimini görsel ayrıntıları geri planda tutarak gösteren iskelet tasarımdır. - [Kullanılabilirlik](https://androverse.com.tr/sozluk/kullanilabilirlik) — Kullanılabilirlik, belirli kullanıcıların belirli görevleri bir ürünle ne kadar rahat ve anlaşılır biçimde tamamlayabildiğini ele alır. - [Mikro etkileşim](https://androverse.com.tr/sozluk/mikro-etkilesim) — Mikro etkileşim, belirli bir küçük eyleme veya durum değişimine verilen odaklı arayüz davranışıdır. ## Konuyu uygulamaya taşı - [Mobil uygulama](https://androverse.com.tr/hizmetler/mobil-uygulama-tasarim) — Prototip kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. - [“Biraz daha wow” kaç piksel?](https://androverse.com.tr/blog/biraz-daha-wow-kac-piksel) — Prototip ile ilgili tasarım kararını Androverse’nin uygulama örnekleri ve değerlendirme sorularıyla birlikte düşün. [Androverse profili](https://androverse.com.tr/yazar/androverse) · [Yayın ilkeleri](https://androverse.com.tr/yayin-ilkeleri)