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

Son güncelleme: 21 Ekim 2026

"Şöyle hızlıca yapabilir misin" yaratıcı işlerin en pahalı cümlesidir. Ardından gelen şey genellikle gerçek bir talep ve gerçek bir teslim tarihidir. Ama talep olarak değil, mesaj olarak gelmiştir. Yani yalnızca biri hatırladığı sürece var olur.

Bunu altı talep edenle çarpın, kuyruk kuyruk olmaktan çıkar. Herkesin kendi sırasının geldiğine inandığı, kişisel anlaşmalardan oluşan bir yığına dönüşür.

Tasarım onay sürecinin bir de tekrara dayanması gerekir. Sözleşme bir kez imzalanır. Aynı tasarım 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: talebin nasıl geldiği ve ilk inceleme ile dördüncü inceleme arasında olanlar.

Tasarım onay süreci nedir?

Tasarım onay süreci altı aşamada ilerler: Talep Edildi, Tasarımda, Dahili İnceleme, Onay Bekliyor, Değişiklik Gerekli ve Teslim Edildi. Talep yazılı bir brif ve tarihinin gerekçesiyle girer. Her revizyon tur sayısına bir ekler. Son evet, tek bir kişinin vereceği onay olarak talebin üzerine işlenir.

Çoğu ekip iki ucu da atlar.

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

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

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

Bunu düzeltmek ucuzdur. Neredeyse her talepte bir tarih vardır, neredeyse hiçbirinde gerekçe yoktur.

Gerekçeyi talebe ayrı bir alan olarak ekleyin, iki tür kendiliğinden ayrışır. "Matbaa kapanışı 16 Temmuz, esneklik yok" bir teslim tarihidir. "Kesin tarih yok, mevcut şablon mobilde bozuluyor" değildir. İkisi de gerçek iştir. Yalnızca biri öne geçer.

Quire'da kapı, ön değerlendirmede durur: bu alanda talep eden ve gerekçe yoksa hiçbir şey giriş listesinden çıkmaz. "Bu acil" böylece kontrol edilebilir bir şeye dönüşür.

Tasarım kuyrukları, çok kişi yorum yapıp kimse karar vermediğinde de tıkanır: RACI, DACI ve RAPID karşılaştırması, aşağıdaki her şeyin altında yatan kim karar verir, kim danışır katmanını anlatıyor.

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

Altı cevap. Altısını da taşıyan talep bugün başlatılabilir. İkisi eksik olan talep ise üç gün sürecek bir konuşmadır.

• Ne olduğu, tek satırda. "Beş slaytlık Instagram carousel", "lansman için bir şeyler"den iyidir.
• Nerede görüneceği, hangi boyutta. Site bannerı, 32px uygulama simgesi ve iki metrelik fuar paneli, tek kelimenin ardındaki üç ayrı iştir.
• Kimin için olduğu. İç paydaş değil, hedef kitle.
• Ne zaman ve neden o tarih. Gerekçe, tarihten daha fazla bilgi taşır.
• Kimin onaylayacağı. Tek bir isim.
• Nelerin zaten var olduğu. Brif, metin, önceki sürüm. Eksik her girdi bir soruya dönüşür, sorular da üç günü iki haftaya çıkarır.

Proje yöneticileri bunun bir rakamını da çıkardı.

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

Altıdan biri kendi alanını hak eder, çünkü alan, cevabı sıralanabilir kılar: tarihin gerekçesi Why this date alanı olur.

Yanına iki alan daha gelir: isteyen kişi için Requested by ve işin kaç kez geri döndüğü için Review round.

Gerisi Görev açıklamasındaki düz metindir. Şablon altısını da, insanları yönlendirebileceğiniz bir How to request design work belgesi olarak sunar.

Ten dakikada deneyin. Ücretsiz bir Quire projesi başlatın ya da yürüttüğünüz bir projeyi açın, Why this date adında bir metin alanı ekleyin ve en eski beş açık talebe doldurun. İkisinde hiç gerekçe çıkmayabilir, tartışmayı da o zaman kazanmış olursunuz.

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

Altı aşama: Talep Edildi, Tasarımda, Dahili İnceleme, Onay Bekliyor, Değişiklik Gerekli ve Teslim Edildi. Bu altısı işin nerede olduğunu izler. Karar ise ayrı bir kayıt alır: Görev üzerindeki bir onay. İkisini ayrı tutmak işin püf noktasıdır.

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

Dahili İnceleme, ekiplerin atladığı ve kendini amorti eden aşamadır. Onaylayıcıyla yapılan ilk turun köşe yarıçaplarına değil, fikre harcanması demektir.

Değişiklik Gerekli geriye doğru çalışan tek aşamadır, o yüzden sayılmaya değer olan da odur. Aşağıda buna devam ediyoruz.

Bu tablodaki her aşama iki ekip arasında bir devirdir: isteyen ekip ve tasarlayan ekip. Fonksiyonlar arası proje yönetimi rehberi, bunun altındaki sahiplik ve devir katmanlarını anlatıyor. Kendi hattınızdaki devirleri önce çizmek isterseniz, iş süreci haritalama yazısı, kulvar diyagramları dahil nasıl yapılacağını gösteriyor.

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. Bütün argüman üç satırda duruyor.

İşe alım posterlerinde Why this date alanında "Kariyer fuarı 16 Ağustos" yazıyor. Bir hafta önce teslim edilecek ortak marka kitinde "Ortak lansmanın henüz tarihi yok" yazıyor. Aynı kuyruk, aynı alan ve yalnızca biri gerçek bir teslim tarihi.

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

• Üç alan ve türleri önemli. Requested by bir kullanıcı alanıdır, böylece kuyruk isteyen kişiye göre filtrelenir. Why this date metindir. Review round, ondalıksız bir sayıdır, bu yüzden sıralanır. Bu üçünü herhangi bir yerde yeniden kurarsanız değerin çoğunu elde edersiniz.
• Yüzey için Etiketler: web, marka, sosyal, baskı, e-posta, video ve gerçekten öyle olanlar için rush.
• Intake: not triaged, henüz kabul edilmemiş, boyutlandırılmamış ya da planlanmamış taleplerin Alt listesi. Uzunluğu kapasite sinyalinizdir. Ön değerlendirme kuralı ise asıl kapıdır: her kalemin bir talep edeni, bir gerekçesi ve ya bir yeri ya da bir hayırı olmalıdır.
• Waiting on a decision, bir onaylayıcıda bekleyen bitmiş işlerin Alt listesi. Uzunluğuna değil, yaşına bakarak okuyun.
• Hazır bir Creative sign-off onay kategorisi. Biten iş, kayıtlı bir evet ya da değişiklik listesi için atanmış bir kişiye gider.
• İki Belge: talep edenler için altı cevaplı kontrol listesi olan How to request design work ve beş adımlı kurulum rehberi olan How to use this template.
• Engellenen Görevler widget'ı ve altı Durum arasındaki dağılımı içeren 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, More'a gidin, Çoğalt'ı seçin ve kopyanın yaşayacağı organizasyonu belirleyin.

Örnek verileri, size ait gibi görünmeye başlamadan silin. Bir şey iki kez ters gitmeden dördüncü bir alan eklemeyin. Üç alan doldurulur, altısı göz ardı edilir. Göz ardı edilen alan hiç olmamasından kötüdür, çünkü hâlâ veri gibi görünür.

Design Pipeline, Quire kitaplığındaki aşamalı hat seçeneğidir. Proje yönetimi şablonları derlemesi, geri kalanları sonlu, tekrarlayan ve aşamalı işlere ayırır. Böylece ihtiyacınız olan bir sonraki şablonu kolayca görürsünüz.

Tasarım talepleri neden sohbet yerine görev yönetim yazılımında yaşamalı?

Çünkü talepler Görev olduğunda, mesaj dizisinin yapamadığı işi hat aşaması yapar. Örnek verilerde dört işin onaylayıcıda, üç işin ise henüz ön değerlendirmesiz olduğunu görmek için kimsenin projeyi açıp bir tasarımcıdan bunu saymasını istemesi gerekmez.

Yaratıcı işlerde görev yönetim yazılımının işi tam olarak budur: her talebin bir aşaması, bir sahibi ve sırada bir yeri olur. Sohbet akışı bunu bir kez bile başaramamıştır.

Bunun çoğunu iki Alt liste taşır. Alt liste, ana listenin yanında duran, projenin kayıtlı bir dilimidir. İkisini de herkes görür. Onay sütunu açıldığında her satırdaki karar da görünür.

Waiting on a decision'da üç gün geçiren bir iş genellikle birinin ondan kaçındığı anlamına gelir.

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

Onay Bekliyor aşaması ortak kuyruktur. Sıralanır ve pazartesi günü incelediğiniz şey budur.

Onaylar ve Talepler widget'ı sizin kendi gelen kutunuzdur. Sizi bekleyen onayları ve gönderdiğiniz talepleri sayar, bu yüzden ikisine de dahil olmayan biri için sıfır gösterir. Ekip sorusuna yalnızca ilki cevap verir.

Dosyaları zaten, çizimin üzerine iğne bırakabildiğiniz özel bir araçta mı inceliyorsunuz? Onu işaretleme için tutun ve inceleme linkini talebe yapıştırın. Kuyruk, tur sayısı ve onay, bütün ekibin görebileceği Görev üzerinde kalır.

Dışarıdan inceleyenler tasarımdan çok hesap açma adımında takılır. Yalnızca bakması gereken bir müşteri, hiç hesap gerekmeden bir linki açabilir, isterseniz tek bir Alt listeyle sınırlı olarak: bir projeyi müşterilerle kayıt olmadan nasıl paylaşacağınız burada.

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

Bütçe, her redraw'da biraz daha sızar 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 ele almaz.

O yüzden sayın. Review round alanı, belirsiz bir "çok dönüp duruyoruz" hissini sıralanabilir bir sütuna çevirir. Bir tur normaldir, iki tur sorun değildir. Üçlerin kümelenmesi ise tasarım sorunu kılığına girmiş bir giriş sorunudur: brif yanlıştı ve yeniden çizmek brifi düzeltmez.

Diğer yarısı, turların içinde ne olduğudur. 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 aracılığıyla beslediğini buldu.

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

Bu da zorunlu kılmaya değer tek bir kural verir. Geri bildirim duyguyu değil, değişikliği adlandırır.

"İçime sinmedi" bir revizyon talebi değildir. "Rozet 375px'te kartın dışında kalıyor" öyledir. Değişikliği adlandıramayan biri henüz incelemeye hazır değildir. Bunu erken söylemek, üç tur boyunca tahmin yürütmekten daha naziktir.

Quire'da bu geri bildirim dosyalarla birlikte görevin üzerinde durur. İkinci tur, birinci turun konusu olan aynı çizimin üzerinde açılır ve inceleyen, başka bir şey istemeden önce geçen sefer neyi 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 bu.

İkinci turda ve yorumda iki düzenleme adlandırılmış: müşteri alıntısında eksik bir unvan ve ana metinle uyuşmayan bir metrik.

Sonra yorum, birinci turda onaylanmış olanı açıkça korur. Bu son kısım göründüğünden önemlidir, çünkü karara bağlanmış bir konuyu yeniden açmak, ikinci turu beşinci tura çeviren şeydir.

Müşteri işi, bu sorunun sesi açılmış halidir, çünkü revizyonlar kendi ekibinizin dışından gelir: kaos olmadan ajans proje yönetimi, inceleyen ödeyen taraf olduğunda turların nasıl sınırlandığını anlatıyor.

Kim onaylar ve karar nerede kaydedilir?

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

Görevde hangi kararın kendisine ait olduğunu da belirtin. "Renk paletini değil, wordmark lockup'ını onaylıyorsunuz" cümlesi, incelemelerdeki en yaygın sapmayı önler: inceleyenin kimsenin sormadığı bir soruyu cevaplaması.

Yol kısadır. Talebi açın, Creative sign-off altında onay isteyin, talep o kişiye düşer. Onaylar ya da değişiklik ister.

Hangisi olursa olsun cevap talebin üzerinde durur. Değişiklik talebi işi bir tur geri gönderir, bu yüzden Review round bir artar.

Bir ayar, onayı gerçek bir kapıya çevirir. Proje ayarları'nda, Durum altında, onay beklerken tamamlanmayı engelleyen seçeneği açın. Onaylayıcı evet demeden hiçbir şey Teslim Edildi'ye ulaşmaz.

Kopyaladığı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 inceleyicinizi belirleyip tek kişiye düşürün, çünkü iki onaylayıcısı olan tasarım yine onaylayıcısız kalır.

Onay Premium ve üzeri Quire planlarında bulunur. Altı aşamalı hattı taşıyan özel durumlar, ücretsiz plan dahil her planda gelir. Ayrıntılar fiyatlandırma sayfasında.

Mekaniklerin kendi yazıları var: özel durumlardan kurulan bir onay akışı ve özel Onay özelliği. Bu yazı ise ikisinin de varsaydığı katman: 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önetim yazılımınızda sayın, kanıt kendiliğinden yukarıyı, üzerine bina edemeyecek kadar belirsiz kalmış talebi gösterir. Gerisi bunun arkasından gelir.

Design Pipeline şablonunda sayaç, giriş listesi ve altı cevaplı talep belgesi hazır. Bu yüzden sonraki adım küçük. Talep belgesini bugün taleplerinizin geldiği kanala yapıştırın ve bu haftaki isteklerin kaçının altı soruya da cevap verebildiğine bakın.

Quire'a kaydolun, hattı kopyalayın ve bir sonraki tasarım talebinizi bu hattan geçirin.

Sıkça sorulan sorular

Tasarım onay süreci nedir?

Yaratıcı işin, biri onu istediği andan tek bir kişinin onaylamasına kadar izlediği yol: Talep Edildi'den Teslim Edildi'ye altı aşama. Quire'ın Design Pipeline şablonu aşamaları Durum olarak sunar. Başta bir talep belgesi, sonda kayıtlı bir onay vardır.

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ı cevabı listeleyen bir talep belgesi ve yeni taleplerin Talep Edildi durumunda düştüğü bir giriş Alt listesi sunar.

Kaç tasarım revizyon turu normaldir?

Bir tur normaldir, iki tur sorun değildir. Üç tur genellikle hatanın işte değil, brifte olduğunu gösterir. Review round alanı bunu bir his olmaktan çıkarıp sıralanabilir bir sütuna çevirir.

Tasarım işini kim onaylamalı?

Karar başına, hangi kararın kendisine ait olduğunu bilen tek bir kişi. Quire'ın onay kategorileri kararı bir kanala değil, bir kişiye bağlar.

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

Yalnızca bakması gereken müşteri, kayıt gerektirmeyen bir Linki Paylaş bağlantısını açar. İsterseniz tek bir Alt listeyle sınırlanır. Karar veren müşteri, atanmış onaylayıcı olarak projeye katılır, böylece onay talebin üzerine düşer.

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

Evet. Quire'da her talep bir Görevdir, her aşama bir Durumdur, onay da Görev üzerindeki bir onaydır. Böylece kuyruk, turlar ve karar tek bir kayıtta durur.

Doğru bir tasarım onay süreci, ekibin işte daha verimli olmasına nasıl yardım eder?

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