Tasarım Onay Süreci: 6 Aşama, Talep Kontrol Listesi ve Şablon

Son güncelleme: 1 Ekim 2026

"Şunu hemen bir yapabilir misin" yaratıcı işlerdeki en pahalı cümledir. Arkasından gelen şey genellikle gerçek bir talep ve gerçek bir son tarihtir. Ama talep olarak değil mesaj olarak gelmiştir. Yani yalnızca biri hatırladığı sürece var olur.

Bunu altı talep sahibiyle çarpın, kuyruk kuyruk olmaktan çıkar. Herkesin sırada kendisinin bir sonraki olduğuna inandığı, özel anlaşmalardan oluşan bir yığına dönüşür.

Tasarım onay sürecinin tekrara da dayanması gerekir. Bir sözleşme bir kez imzalanır. Aynı çizim ise her biri farklı bir sürümü görmüş insanlar tarafından üç dört kez karara bağlanır.

Süreç, kimsenin yapılandırmadığı iki yerde bozulur: bir talebin nasıl geldiği ve ilk inceleme ile dördüncü inceleme arasında olanlar.

Tasarım onay süreci neden tasarım başlamadan bozulur?

Süreç talep girişinde bozulur: mesaj olarak gelen talebin bir durumu yoktur, bu yüzden ait olduğu kuyruk görünmezdir. Bir mesaj beklemede olamaz, kabul edilmiş olamaz, sırada üçüncü olamaz. Yalnızca okunmuş ya da okunmamış olur.

Bu yüzden en yüksek sesle konuşan kazanır, çünkü elde başka sinyal yoktur. Tasarımcı da sessizce kuyruğun kendisi olur. Daha kötüsü, öncelik tartışılamaz hale gelir: "bu acil" hiçbir şeyle doğrulanamaz.

Bu sonuncusunu düzeltmek ucuzdur. Neredeyse her talebin bir tarihi vardır, neredeyse hiçbirinin nedeni yoktur.

Nedeni talebe ayrı bir alan olarak ekleyin, iki tür kendiliğinden ayrışır. "Matbaa kapanışı 16 Tem, esneme yok" bir son tarihtir. "Kesin tarih yok, mevcut şablon mobilde bozuluyor" değildir. İkisi de gerçek iştir. Ama yalnızca biri öne geçer.

Quire'da kapı triyajdadır: o alandaki bir talep sahibi ve neden olmadan hiçbir şey intake listesinden çıkmaz. "Bu acil" ifadesini kontrol edilebilir bir şeye çeviren de budur.

Çok kişi yorum yapabildiğinde ama kimse karar vermediğinde de tasarım kuyrukları tıkanır. RACI, DACI ve RAPID karşılaştırması, aşağıdaki her şeyin altında yatan kimin karar verip kimin danıştığı katmanıdır.

Bir tasarım talebi, iş başlamadan önce neleri söylemeli?

Altı yanıt. Altısını da taşıyan bir talep bugün başlatılabilir. İkisi eksik olan talep ise yapılması üç gün sürecek bir sohbettir.

• Ne olduğu, tek satırda. "Beş slaytlık Instagram carousel", "lansman için bir şey"den iyidir.
• Nerede görüneceği, hangi boyutta. Site banner'ı, 32px uygulama ikonu ve iki metrelik fuar paneli, tek kelimenin ardındaki üç ayrı iştir.
• Kimin için olduğu. İç paydaşın değil, hedef kitlenin.
• Ne zaman ve neden o tarih. Neden, tarihten daha çok bilgi taşır.
• Kimin onaylayacağı. Tek bir isim.
• Elde ne olduğu. Brief, metin, önceki sürüm. Eksik her girdi bir soruya dönüşür ve üç günü iki haftaya çıkaran şey sorulardır.

Proje yöneticileri bunun bir rakamını koymuş durumda.

PMI'ın gereksinimler üzerine Pulse of the Profession araştırması, başarısız projelerin yaklaşık yarısının (%47) hedeflerini hatalı gereksinim yönetimi yüzünden kaçırdığını buldu. Bir tasarım talebi minyatür bir gereksinimdir ve belirsiz olanı aynı şekilde, yalnızca daha hızlı başarısız olur.

Altısından biri kendi alanını hak eder, çünkü alan bir yanıtı sıralanabilir kılar: tarihin arkasındaki neden Why this date olur.

Yanında iki alan daha durur: isteyen kişi için Requested by ve işin kaç kez geri geldiği için Review round.

Gerisi görev açıklaması için düz yazıdır. Şablon altısını da insanlara gösterebileceğiniz bir How to request design work belgesi olarak sunar.

On dakikada deneyin. Ücretsiz bir Quire projesi başlatın ya da yürüttüğünüz birini açın, Why this date adlı bir metin alanı ekleyin ve en eski beş açık talebinizde doldurun. İkisinin hiç nedeni olmayacağı neredeyse kesin. Tartışma da orada bitmiş olur.

Bir tasarım onay sürecinin altı aşaması nedir?

Altı aşama Requested, In Design, Internal Review, Awaiting Approval, Changes Requested ve Delivered'dır. Bu altısı işin nerede olduğunu izler. Kararın ise kendi kaydı vardır: görevin üzerindeki bir onay. İkisini ayrı tutmak işin büyük kısmıdır.

Design Pipeline şablonunda her aşama şöyle işler:

Internal Review ekiplerin atladığı ve kendini amorti eden aşamadır. Onaylayıcıyla yapılan ilk turun köşe yuvarlaklıklarına değil fikre harcanması demektir.

Changes Requested geriye doğru işleyen tek aşamadır, bu yüzden sayılmaya değer olan odur. Aşağıda bunun üzerinde duruyoruz.

O tablodaki her aşama iki ekip arasında bir devir teslimdir: isteyen ekip ve tasarlayan ekip. Fonksiyonlar arası proje yönetimi rehberi, bunun altındaki sahiplik ve devir katmanlarını anlatır.

Quire'ın Design Pipeline şablonuyla neler geliyor?

Çalışan bir tasarım kuyruğu: yukarıdaki altı aşama, üç özel alan, iki alt liste, bir Creative sign-off onay kategorisi, iki belge ve bir Kontrol Paneli. Quire'ın Design Pipeline şablonunu açın, Intake: not triaged alt listesine girin. Tüm argüman üç satırda durur.

Recruiting posters, Why this date alanında "Careers fair is 16 Aug" yazar. Bir hafta önce teslim edilecek Partner co-brand kit ise "Partner launch has no date yet" yazar. Aynı kuyruk, aynı alan. Yalnızca biri gerçek bir son tarihtir.

Bu satırları mümkün kılanlar:

• Üç alan ve türleri önemli. Requested by bir kullanıcı alanıdır, böylece kuyruk kimin istediğine göre filtrelenir. Why this date metindir. Review round ondalıksız bir sayıdır, böylece sıralanır. Bu üçünü herhangi bir yerde yeniden kurarsanız değerin çoğunu elde edersiniz.
• Yüzey için etiketler: web, brand, social, print, email, video ve gerçekten öyle olanlar için rush.
• Intake: not triaged, henüz kabul edilmemiş, boyutlandırılmamış veya planlanmamış taleplerin alt listesi. Uzunluğu kapasite sinyalinizdir. Triyaj kuralı ise asıl kapıdır, çünkü her öğenin bir talep sahibi, bir nedeni ve bir slotu ya da bir hayırı olmalıdır.
• Waiting on a decision, bir onaylayıcıda bekleyen biten işlerin alt listesi. Uzunluğuna değil yaşına göre okuyun.
• Hazır bir Creative sign-off onay kategorisi, böylece biten iş kayıtlı bir evet ya da değişiklik listesi için adı belli bir kişiye gider.
• İki belge: talep sahipleri için altı yanıtlı kontrol listesi olan How to request design work ve beş adımlı kurulum rehberi How to use this template.
• Engellenen Görevler widget'ı ve altı durum dağılımı olan bir Creative Ops Kontrol Paneli.

Kopyalamak yaklaşık bir dakika sürer. Şablonun adının yanındaki açılır menüyü açın, Daha fazla bölümüne gidin, Çoğalt seçeneğini seçin ve kopyanızın yaşayacağı organizasyonu belirleyin.

Örnekler size ait gibi görünmeye başlamadan silin ve iki kez bir şey ters gitmeden dördüncü bir alana direnin. Üç alan doldurulur, altı alan yok sayılır. Yok sayılan alan hiç olmamasından kötüdür, çünkü hâlâ veri gibi görünür.

Design Pipeline, Quire kütüphanesindeki aşamalı iş hattı seçeneğidir. Proje yönetimi şablonları derlemesi geri kalanları sonlu, tekrarlayan ve aşamalı iş olarak ayırır, böylece ihtiyaç duyacağınız bir sonraki şablonu bulmak kolaylaşır.

Tasarım talepleri neden sohbette değil görev yönetimi yazılımında durmalı?

Çünkü talepler görev olunca, mesaj dizisinin yapamadığı işi pipeline aşaması yapar. Örnek veride herkes projeyi açıp dört işin bir onaylayıcıda, üç işin triyajsız olduğunu, bir tasarımcıdan sayıp dökmesini istemeden görebilir.

Yaratıcı işlerde görev yönetimi yazılımının işi tam olarak budur: her talebin bir aşaması, bir sahibi ve sırada bir yeri vardır. Sohbet akışı bunu hiç başaramadı.

Bunun büyük kısmını iki alt liste taşır. Alt liste, ana listenin yanında projenin kaydedilmiş bir dilimidir. İkisi de herkese görünür. Onay sütunu açıldığında her satırdaki karar da görünür.

Waiting on a decision içinde üç gün geçiyorsa, genellikle biri bundan kaçınıyordur.

Bir ayrım nereye bakacağınızı belirler.

Awaiting Approval aşaması paylaşılan kuyruktur. Sıralanır ve Pazartesi günü inceleyeceğiniz şeydir.

Onaylar ve Talepler widget'ı sizin kendi gelen kutunuzdur. Sizi bekleyen onayları ve gönderdiğiniz talepleri sayar, bu yüzden ikisinden de olmayan biri için sıfır gösterir. Bir ekip sorusunu yalnızca ilki yanıtlar.

Dosyaları zaten özel bir araçta, çizimin üzerine iğneler koyarak mı kontrol ediyorsunuz? O aracı işaretleme için tutun ve kontrol linkini talebe yapıştırın. Kuyruk, tur sayısı ve imza görevde kalır, tüm ekip de görebilir.

Dış incelemeciler tasarımdan çok hesap oluşturmada takılır. Yalnızca bakması gereken müşteri, isterseniz tek bir alt listeyle sınırlandırılmış, hesapsız bir linki açabilir: bir projeyi müşterilerle kayıt olmadan paylaşmanın yolu burada.

Tasarım incelemesinin birinci turu ile dördüncü turu arasında ne olur?

Bütçe, her yeniden çizimde biraz akar ve normal bir kurulumda hiçbir şey bunu kaydetmez. Birinci tur sorun değildir. Bütçelerin öldüğü yer dördüncü turdur ve aradaki kısmı neredeyse hiçbir süreç belgesi kapsamaz.

Bu yüzden sayın. Review round alanı belirsiz bir debelenme hissini sıralanabilir bir sütuna çevirir. Bir tur normal, iki tur sorun değil. Bir küme üçüncü tur ise tasarım sorunu kılığına girmiş bir talep girişi sorunudur: brief yanlıştı ve yeniden çizmek brief'i düzeltmez.

Diğer yarısı turların içeriğidir. Yedi şirketten 264 çalışan üzerinde yaptıkları çalışmada Zhenxing Gong ve Na Zhang, destekleyici bir geri bildirim ortamının yaratıcı performansı dolaylı olarak, insanların ruh hali üzerinden beslediğini buldu.

Vardıkları sonuç: "destekleyici bir yönetici geri bildirim ortamı oluşturmak, yaratıcı performansı artırmak için oldukça önemlidir." Bu bir anket verisi, dolayısıyla bir kaldıraç değil, bir korelasyon olarak okuyun. Ama nokta geçerli: geri bildirim işe bir tepki değil, işin parçasıdır.

Bu da uygulamaya değer tek bir kural verir. Geri bildirim duyguyu değil değişikliği söyler.

"İçime sinmedi" bir revizyon talebi değildir. "Rozet 375px'te kartın dışında kalıyor" bir revizyon talebidir. Değişikliği söyleyemeyen incelemeci incelemeye hazır değildir. Bunu erkenden söylemek, üç tur tahminden daha naziktir.

Quire'da bu geri bildirim dosyalarla birlikte görevin üzerinde durur. Böylece ikinci tur, birinci turun konusu olan aynı çizimle açılır. İncelemeci de başka bir şey istemeden önce geçen sefer ne istediğini görebilir.

Şablonda, vaka çalışması tek sayfalığında işlenmiş bir örnek var: yukarıdaki listede Creative sign-off: Değişiklik iste yazan iki satırdan biri.

İkinci turda duruyor ve iki düzenlemeyi adlandıran bir yorum taşıyor: bir müşteri alıntısında eksik iş unvanı ve gövde metniyle uyuşmayan bir metrik.

Sonra yorum, birinci turun zaten onayladığı şeyi açıkça korur. Bu son kısım duyulduğundan daha önemlidir, çünkü karara bağlanmış bir kararı yeniden açmak ikinci turu beşinci tura çevirmenin yoludur.

Müşteri işi bu sorunun sesi açılmış halidir, çünkü revizyonlar kendi ekibinizin dışından gelir: kaos olmadan ajans proje yönetimi, incelemeci ödemeyi yapan taraf olduğunda turları sınırlamayı anlatır.

Kim onaylar ve karar nerede kaydedilir?

Her karar için adı belli tek bir kişi ve karar talebin kendisine kaydedilir. İki onaylayıcısı olan bir tasarımın hiç onaylayıcısı yoktur. Şablon bir Creative sign-off kategorisi kullanır, böylece karar bir odaya değil adı belli bir onaylayıcıya bağlanır.

Görevde hangi kararın onlara ait olduğunu da belirtin. "Renk paletini değil, wordmark lockup'ını onaylıyorsunuz" cümlesi, en yaygın inceleme sapmasını önler: kimsenin sormadığı bir soruyu yanıtlayan incelemeci.

Yol kısadır. Talebi açın, Creative sign-off altında onay isteyin, o kişiye ulaşır. Onlar onaylar ya da değişiklik ister.

Hangisi olursa olsun yanıt talebin üzerinde durur. Değişiklik isteği işi bir tur geri gönderir, dolayısıyla Review round bir artar.

Tek bir ayar imzayı gerçek bir kapıya çevirir. Proje ayarları içinde, Durum altında, onay beklerken tamamlamayı engelleyen seçeneği açın. Onaylayıcı evet diyene kadar hiçbir şey Delivered'a ulaşmaz.

Çoğalttığınız anda değiştirmeniz gereken bir şey var: örnek, Creative sign-off'u iki onaylayıcıyla getiriyor. Proje ayarlarında gerçek incelemecinizi atayın ve bire indirin, çünkü iki onaylayıcılı tasarım yine hiç onaylayıcısı olmayan tasarıma döner.

Onay, Premium ve üzeri Quire planlarında kullanılabilir. Altı aşamalı pipeline'ı taşıyan özel durumlar, Free dahil her planla gelir. Ayrıntılar fiyatlandırma sayfasında.

Mekaniğin kendi yazıları var: özel durumlarla kurulan bir onay akışı ve özel Onay özelliği. Bu yazı, ikisinin de varsaydığı katmandır: onları besleyen kuyruk.

Önemli çıkarımlar

Bu yazıdan tek bir şey alacaksanız tur sayacını alın. Üçüncü turdaki bir tasarım neredeyse hiçbir zaman tasarım sorunu değildir. Onu yeniden çizmeye harcanan her saat, bir belirtiyi tedavi etmeye harcanmış saattir.

Turları görev yönetimi yazılımınızda sayın, kanıt kendiliğinden yukarı akışı işaret eder: üzerine inşa edilemeyecek kadar belirsiz olan talebi. Gerisi bunun ardından gelir.

Design Pipeline şablonunda sayaç, intake listesi ve altı yanıtlı talep belgesi hazır, dolayısıyla sonraki adım küçük. Talep belgesini bugün taleplerinizin geldiği kanala yapıştırın ve bu haftaki isteklerden kaçının altısını da yanıtlayabildiğine bakın.

Quire'a kaydolun, pipeline'ı kopyalayın ve bir sonraki tasarım talebinizi içinden geçirin.

Sık sorulan sorular

Tasarım onay süreci nedir?

Yaratıcı işin, biri onu istediğinden adı belli bir kişi onaylayana kadar izlediği yol. Çoğu ekipte ortası vardır, başı ve sonu yoktur. Quire'ın Design Pipeline şablonu ikisini de sunar: başta bir talep belgesi, sonda kayıtlı bir onay.

Tasarım talepleri rastgele mesajlar olarak gelmesin diye ne yapılır?

İnsanlara daha iyi bir yer verin ve onu daha hızlı yol yapın. Şablon, bir talebin ihtiyaç duyduğu altı yanıtı sıralayan bir talep belgesiyle gelir. Yeni taleplerin Requested durumunda düştüğü bir intake alt listesi de sunar.

Kaç tasarım revizyon turu normaldir?

Bir tur normaldir, iki tur sorun değildir, üç tur genellikle sorunun işte değil brief'te olduğunu gösterir. Review round alanı bunu bir his olmaktan çıkarıp sıralanabilir bir sütuna dönüştürür.

Tasarım işini kim onaylamalı?

Her karar için adı belli tek bir kişi ve o kişi hangi kararın kendisine ait olduğunu bilmeli. Quire'ın onay kategorileri kararı bir kanala değil bir kişiye bağlar.

Dış müşteriler tasarım işini Quire'da nasıl inceler?

Yalnızca bakması gereken müşteri, isterseniz tek bir alt listeyle sınırlandırılmış, kayıt gerektirmeyen bir paylaşım linkini açar. Karar veren müşteri projeye adı belli onaylayıcı olarak katılır, böylece imza talebin üzerine düşer.

Görev yönetimi yazılımı bir tasarım onay sürecini yürütebilir mi?

Evet. Quire'da her talep bir görev, her aşama bir durum ve imza görevin üzerindeki bir onaydır. Kuyruk, turlar ve karar tek bir kaydı paylaşır.

İyi bir tasarım onay süreci ekibin işte daha verimli olmasına nasıl yardımcı olur?

Daha az yeniden çizim. Quire'da inceleme turlarını saymak, üçlerin nerede kümelendiğini gösterir. O brief'leri düzeltirseniz aynı çizime iki kez ödemeyi bırakırsınız. Bu da tasarımcılara yeniden çizimin yediği saatleri geri verir.