डिज़ाइन ब्रीफ कैसे लिखें जो सच में शिप हो

ज़्यादातर डिज़ाइन ब्रीफ नाटक होते हैं। वे सपने का वर्णन करते हैं, "मॉडर्न" और "ह्यूमन-फर्स्ट" जैसे विशेषण गिनाते हैं, और अंत में एक vibe board पर ख़त्म होते हैं जिस पर क्लाइंट ने सहयोगी दिखने के लिए दस्तख़त कर दिए। फिर प्रोजेक्ट भटक जाता है।

जो ब्रीफ शिप होता है वह छह सवालों के जवाब देता है, constraints के एक पन्ने में समा जाता है, और काम शुरू होने से पहले लिखे kill criteria पर ख़त्म होता है। बाकी सब सजावट है।

ज़्यादातर डिज़ाइन ब्रीफ नाटक होते हैं

पारंपरिक डिज़ाइन ब्रीफ शादी के भाषण जैसा पढ़ा जाता है। भावनाओं से भरा, फ़ैसलों में हल्का, और उन लोगों के दस्तख़त वाला जो इतने विनम्र हैं कि पलटकर सवाल नहीं करते।

डेक में 30 स्लाइड होती हैं और मूड बोर्ड में 40 तस्वीरें। कहीं नहीं लिखा होता कि काम पूरा होने का फ़ैसला कौन करेगा, कौन सा आँकड़ा रिश्ते को ख़त्म करेगा, या प्रोजेक्ट क्या नहीं है।

यह ब्रीफ नहीं है, यह कवर पेज वाली विश लिस्ट है। छठे हफ़्ते में यह दम तोड़ देती है, जब क्लाइंट "बस एक और राउंड" माँगता है और एजेंसी के पास बातचीत ख़त्म करने के लिए कोई दस्तावेज़ नहीं होता।

असली ब्रीफ छोटा, तय और असहज करने वाला होता है। अगर उसे ज़ोर से पढ़ने पर कोई कुर्सी पर पहलू न बदले, तो उसने अपना काम नहीं किया।

हर डिज़ाइन ब्रीफ को इन छह सवालों के जवाब देने चाहिए

हर ब्रीफ, हर प्रोजेक्ट, हर एंगेजमेंट। अगर ब्रीफ इनके जवाब नहीं दे सकता, तो प्रोजेक्ट तैयार नहीं है।

इनमें से कोई एक भी छोड़ दीजिए और तीन महीने बाद आपके इनबॉक्स में प्रोजेक्ट का बचाव करना पड़ेगा।

Decider, done, और scope के चारों ओर की रेखा

पहले तीन सवाल तय करते हैं कि काम का मालिक कौन है और काम क्या है। यहाँ धुंधले जवाब बाकी सब में ज़हर घोल देते हैं।

1. काम पूरा हुआ, यह कौन तय करता है

एक नाम। "लीडरशिप टीम" नहीं, "देखते ही पहचान लेंगे" नहीं, "फ़ाउंडर आख़िर में राय देंगे" नहीं।

एक अकेला approver जो हाँ कह सके, ना कह सके, और जिसकी हाँ बाध्यकारी हो। अगर उसे पहले दूसरों से सलाह लेनी है, तो ब्रीफ में वे नाम भी लिखे जाते हैं, पर दस्तख़त फिर भी approver ही करता है। कमेटियाँ डिज़ाइन को approve नहीं करतीं, वे उसे बातचीत करके लुगदी बना देती हैं।

पहले पैराग्राफ़ में decider का नाम लिखिए। अगर क्लाइंट नहीं लिख सकता, तो प्रोजेक्ट शुरू होने के लिए तैयार नहीं है।

2. "पूरा" असल में कैसा दिखता है

"एक पॉलिश्ड वेबसाइट" नहीं। "एक ब्रांड जो दिल को छू ले" नहीं। एक artifact जिसका आप स्क्रीनशॉट ले सकें और एक लिंक जो किसी अजनबी को थमा सकें।

मार्केटिंग साइट के लिए, पूरा होने का मतलब है तय पेज संख्या, कंपोनेंट लाइब्रेरी और Core Web Vitals की सीमा वाला डिप्लॉय किया हुआ URL। ब्रांड आइडेंटिटी के लिए, यह लोगो सेट, टाइप सिस्टम, कलर टोकन और एक पन्ने के उपयोग दस्तावेज़ वाला asset फ़ोल्डर है। ठोस। फ़ोटो खींचने लायक। बंद करने लायक।

अगर टीम अंतिम डिलीवरेबल एक वाक्य में बयान नहीं कर सकती, तो ब्रीफ अब भी मूड-बोर्ड मोड में है।

3. साफ़ तौर पर scope से बाहर क्या है

किसी भी ब्रीफ का सबसे ताकतवर हिस्सा उन चीज़ों की सूची है जो प्रोजेक्ट नहीं करेगा।

हर प्रोजेक्ट के आसपास अदृश्य काम होता है जो किसी के देखते न रहने पर चुपचाप scope के अंदर खिसक आता है। जो ब्रीफ शिप होता है वह उस पर OUT की मुहर लगाता है, ऐसी पंक्तियों के साथ: "कोई अतिरिक्त लोकलाइज़ेशन नहीं, CRM इंटीग्रेशन नहीं, चौथे हफ़्ते के बाद ब्रांड एक्सप्लोरेशन का दूसरा राउंड नहीं।"

Scope से बाहर की चीज़ें सुरक्षा हैं, इनकार नहीं। आपको डिज़ाइन सिस्टम की ज़रूरत नहीं सिस्टम के स्तर पर यही अनुशासन है, और डिज़ाइनर अब PM हैं बताता है कि scope की निगरानी ब्रीफ में क्यों रहती है।

पैसा और समय, आँकड़ों में लिखे हुए

अगले दो सवाल vibe को आँकड़ों में बदलते हैं।

4. कौन सा बजट आँकड़ा प्रोजेक्ट को ख़त्म करता है

एक ठोस मुद्रा में रकम। "तंग" नहीं, "प्रतिस्पर्धी" नहीं, "लचीला" नहीं। एक संख्या जो पार होने पर एंगेजमेंट ख़त्म कर दे।

दरअसल दो संख्याएँ। वह रकम जिस पर प्रोजेक्ट बेचा गया, और वह रकम जो रुकने का ट्रिगर बनती है। Kill संख्या आमतौर पर बेची गई संख्या से 15 से 25 प्रतिशत ऊपर होती है, ताकि टीम ईमानदार गलतियाँ सोख सके और ओवररन छिपाने की ज़रूरत न पड़े।

Kill संख्या को ब्रीफ में, दस्तख़त के साथ लिखिए। प्राइसिंग पेज की समस्या सार्वजनिक सतह पर यही अनुशासन बताती है; value-based pricing गहरी पढ़ाई है।

5. कौन सी समयसीमा प्रोजेक्ट को ख़त्म करती है

एक असली कैलेंडर तारीख़। "Q3" नहीं, "गर्मी के अंत तक" नहीं, "लॉन्च से पहले" नहीं। एक दिन जो छूटने पर एंगेजमेंट ख़त्म कर दे या दोबारा बातचीत शुरू करा दे।

फिर से दो तारीख़ें। Ship तारीख़ और kill तारीख़। Kill तारीख़ कोई नहीं लिखना चाहता क्योंकि लिखते ही वह असली हो जाती है। फिर भी लिखिए।

अगर प्रोजेक्ट किसी लॉन्च या फंडरेज़ से जुड़ा है, तो kill तारीख़ को उससे बाँधिए। Anthropic की eval-gated रिलीज़ और Linear के छह हफ़्ते के साइकिल ऐसे ब्रीफ का संकेत देते हैं जहाँ किसी ने तारीख़ लिखी और उसे हिलाने से इनकार कर दिया।

वह एक संख्या जो सफलता तय करती है

आख़िरी सवाल सबसे छोटा है और सबसे ज़्यादा विवादित। यह बाकी सब कुछ तय करता है।

6. वह एक मेट्रिक क्या है जो मायने रखती है

एक। इकलौती। डैशबोर्ड नहीं। एक संख्या, टीम के बाहर से देखी जा सकने वाली, जो तय करे कि प्रोजेक्ट सफल हुआ या नहीं।

मार्केटिंग साइट के लिए, हर महीने क्वालिफ़ाइड लीड। लॉन्च के लिए, पहले 30 दिनों में सक्रिय हुए अकाउंट। ब्रांड रिफ्रेश के लिए, इनबाउंड डील की गुणवत्ता में मापने योग्य बदलाव, "ब्रांड अवेयरनेस" नहीं।

लालच होता है पाँच मेट्रिक गिनाने का ताकि कुछ भी फ़ेल न हो सके। इससे बचिए।

वह इकलौती मेट्रिक ब्रीफ में जाती है, कॉन्ट्रैक्ट में जाती है, और दीवार पर टँगती है। एंटी-डैशबोर्ड बताता है कि एक संख्या डैशबोर्ड के पीछे छिपी बारह संख्याओं से क्यों बेहतर है।

एक पन्ने की constraints शीट

छह सवाल, एक पन्ना। अगर जवाब एक शीट में नहीं समाते, तो प्रोजेक्ट पर अब भी बातचीत चल रही है।

यह टेम्पलेट कॉपी कीजिए, क्लाइंट को कमरे में बिठाकर भरिए, और अगले चरण की scoping से पहले दस्तख़त ले लीजिए।

ONE-PAGE CONSTRAINTS SHEET Project: [name] Client: [company] Date: [date] 1. DECIDER Approver of record: [single name + title] Consulted before approval: [up to 3 names] 2. DONE Final deliverable: [one sentence] Acceptance artifact: [URL, file, or shipped surface] 3. OUT OF SCOPE Not included: - [item] - [item] - [item] Anything not listed above is also out of scope. 4. BUDGET Sold at: [currency + figure] Kill at: [currency + figure] 5. TIMELINE Ship date: [calendar date] Kill date: [calendar date] External anchor: [event, launch, or contract trigger] 6. METRIC The one number we own: [metric] Measured by: [tool or person] Reviewed: [date] Signed: ______________________ [decider name + date]

Copy

फ़ॉर्मेट मायने नहीं रखता, अनुशासन रखता है। फ़ोन स्क्रीन पर समा जाने वाली शीट, जो किकऑफ़ पर ज़ोर से पढ़ी जाए और decider के दस्तख़त से गुज़रे, प्रोजेक्ट शिप कराती है। 30 पन्नों का ब्रीफ जिसे कोई नहीं पढ़ता, नहीं कराता।

Kill criteria, काम शुरू होने से पहले लिखे हुए

Kill criteria वह हिस्सा है जिसे कोई नहीं लिखता क्योंकि उसे लिखना नाकामी की योजना बनाने जैसा लगता है। उसे छोड़ना तकलीफ़ की योजना बनाना है।

Kill criteria वे शर्तें हैं, पहले दिन लिखी गईं, जो प्रोजेक्ट को जान-बूझकर रोकती या ख़त्म करती हैं। "यह बुरी तरह चल रहा है" नहीं, बल्कि "यह घटना हुई, आगे हम यह करेंगे।"

आम डिज़ाइन एंगेजमेंट के लिए काम करने वाला एक सेट:

1. लिखित हैंडऑफ़ के बिना प्रोजेक्ट के बीच में decider बदल जाता है। नया decider पाँच कार्यदिवसों के भीतर constraints शीट पर दोबारा दस्तख़त करता है, वरना प्रोजेक्ट रुक जाता है।

2. बजट kill संख्या छू ली जाती है। काम रुकता है, ईमानदार इनवॉइस भेजा जाता है, और अगले चरण की scoping दोबारा होती है।

3. Done की शर्त शिप हुए बिना समयसीमा की kill तारीख़ आ जाती है। प्रोजेक्ट लिखित पुनर्वार्ता में जाता है, चुपचाप खिंचाव में नहीं।

4. चेंज ऑर्डर के बिना scope से बाहर की चीज़ें जोड़ी जाती हैं। तीन कार्यदिवसों में चेंज ऑर्डर पर दस्तख़त होते हैं, वरना अनुरोध छोड़ दिया जाता है।

5. वह एक मेट्रिक मापी नहीं जा सकती। अगर टीम लगातार दो रिव्यू अवधियों तक उसे माप नहीं पाती, तो ब्रीफ दोबारा खोला जाता है।

6. लिखित कारण के बिना लगातार दो माइलस्टोन छूट जाते हैं। अगले माइलस्टोन से पहले प्रोजेक्ट decider के साथ रिकवरी रिव्यू में जाता है।

हर मापदंड का एक ट्रिगर और एक जवाब होता है। जवाब कभी "देखेंगे सबको कैसा लगता है" नहीं होता, वह एक लिखित, यांत्रिक कार्रवाई होता है।

ब्रीफ हर नाकामी की भविष्यवाणी नहीं करता। वह पहले से वचन देता है कि नाकामी दिखने पर टीम कैसे पेश आएगी।

Linear, Stripe और Vercel के ब्रीफ कैसे पढ़े जाते हैं

उन कंपनियों के बाहर किसी ने उनके ब्रीफ नहीं पढ़े। काम ही उल्टा ब्रीफ है।

Linear छह हफ़्ते के साइकिल पर शिप करता है, एक जवाबदेह मालिक, कसे हुए scope और शिप हुई सतह के साथ। Stripe फ़ीचर शिप होने के दिन ही डॉक्स शिप करता है, यानी डॉक्स का ब्रीफ फ़ीचर के साथ ही बना था। Vercel डिप्लॉय लॉग को ही लॉन्च की सतह बना देता है, वही रुख जो लोडिंग स्टेट ही प्रोडक्ट है में है।

काम से ब्रीफ को रिवर्स-इंजीनियर कीजिए। हर सतह के लिए एक decider। Done का मतलब शिप हुआ, approve हुआ नहीं। Scope से बाहर की सूची उन फ़ीचर में दिखती है जो कभी शिप नहीं हुए।

सबक यह नहीं है कि "अपना ब्रीफ Linear की तरह लिखो"। सबक यह है कि "जिस काम की आप इज़्ज़त करते हैं उसे देखिए और पूछिए कि कौन सा ब्रीफ उसे पैदा करता"। नाकामी का तरीका 2026 में हर SaaS एक जैसा क्यों दिखता है में है।

ब्रीफ एक कॉन्ट्रैक्ट है, विश लिस्ट नहीं

जो ब्रीफ कॉन्ट्रैक्ट के बगल में रहता है, वह कॉन्ट्रैक्ट है। जो किसी धूल खाते Notion पेज में रहता है, वह विश लिस्ट है।

Constraints शीट को स्टेटमेंट ऑफ़ वर्क से जोड़िए। Kill criteria का हवाला एंगेजमेंट लेटर में दीजिए। उस एक मेट्रिक को क्लॉज़ बनाइए, स्लाइड नहीं। अगर वायरफ़्रेम किसी स्क्रीन का संरचनात्मक कॉन्ट्रैक्ट है, तो पूरे एंगेजमेंट के लिए यही काम ब्रीफ करता है।

जब काम भटकता है, और वह हमेशा भटकता है, ब्रीफ भटकाव को ख़त्म करता है। एक पन्ना, दस्तख़त किया हुआ, किकऑफ़ पर पढ़ा गया, प्रोजेक्ट चैनल में पिन किया हुआ। ब्रीफ और नाटक में यही फ़र्क है।

इसे सोमवार सुबह चलाइए

आपकी मेज़ पर पड़ा अगला ब्रीफ किकऑफ़ कॉल से पहले छह-सवाल की जाँच से गुज़रेगा।

उसे खोलिए। एक खाली पन्ना लीजिए और बाईं ओर छह सवाल लिखिए, दाईं ओर ब्रीफ के जवाब। अगर कोई जवाब गायब है, धुंधला है, या artifact की जगह विशेषणों में लिखा है, तो वही किकऑफ़ का एजेंडा है। "चलिए डेक देखते हैं" नहीं, बस "जब तक ये छह जवाब नहीं मिलते हम शुरू नहीं कर सकते।"

ज़्यादातर क्लाइंट इसकी इज़्ज़त करते हैं। जो नहीं करते, वही क्लाइंट हैं जो छूटी हुई डेडलाइन और अनचुकाया अंतिम इनवॉइस पैदा करते। ब्रीफ उन्हें काम शुरू होने से पहले ही छाँट देता है।

FAQ

डिज़ाइन ब्रीफ कितना लंबा होना चाहिए?

Constraints का एक पन्ना, साथ में जो भी सहायक संदर्भ टीम को चाहिए। Constraints शीट ही कॉन्ट्रैक्ट है। अगर वे constraints एक पन्ने में नहीं समाते, तो प्रोजेक्ट पर अब भी बातचीत चल रही है।

क्रिएटिव ब्रीफ और डिज़ाइन ब्रीफ में क्या फ़र्क है?

क्रिएटिव ब्रीफ मैसेजिंग, ऑडियंस और टोन को कवर करता है। डिज़ाइन ब्रीफ यह सब कवर करता है और साथ में वे संचालन संबंधी constraints भी जो तय करते हैं कि प्रोजेक्ट शिप होगा या नहीं: decider, done, बजट kill, समयसीमा kill, scope से बाहर, एक मेट्रिक। डिज़ाइन ब्रीफ के बिना क्रिएटिव ब्रीफ बस एक vibe दस्तावेज़ है।

डिज़ाइन ब्रीफ किसे लिखना चाहिए, एजेंसी को या क्लाइंट को?

एजेंसी ड्राफ़्ट बनाती है, क्लाइंट एडिट करता है, decider दस्तख़त करता है। पूरी तरह क्लाइंट का लिखा ब्रीफ विश लिस्ट है; पूरी तरह एजेंसी का लिखा सेल्स डॉक है। सही ब्रीफ मिलकर लिखा जाता है, ढाँचे पर एजेंसी, constraints पर क्लाइंट।

CTA

ऐसा पार्टनर चाहिए जो ब्रीफ को किकऑफ़ स्लाइड की तरह नहीं, कॉन्ट्रैक्ट की तरह चलाए? Brainy छह सवालों, एक पन्ने की constraints शीट और ऐसे kill criteria के साथ शिप करता है जो सबकी रक्षा करते हैं। Brainy को हायर करें और सबसे पहले आपको एक ब्रीफ दिखेगा, एक पिक्सल हिलने से पहले दस्तख़त किया हुआ।