डिसीजन लॉग: टॉप डिज़ाइनर वे फ़ैसले क्यों दर्ज करते हैं जिनके बारे में किसी ने पूछा ही नहीं

एक सीनियर डिज़ाइनर और एक मिड-लेवल डिज़ाइनर एक ही स्क्रीन शिप कर सकते हैं। सीनियर को याद रहता है कि क्यों। मिड-लेवल को याद रहता है कि क्या।

यह फ़र्क़ एक ही आर्टिफ़ैक्ट का है। हर डिज़ाइन फ़ैसले का छोटा, तारीख़वाला, structured रिकॉर्ड, जिसके साथ उसका तर्क जुड़ा हो। यानी decision log। ज़्यादातर डिज़ाइनर इसे नहीं रखते, क्योंकि स्कूल ने कभी माँगा नहीं और पिछली टीम में था नहीं। यह आदत अपने आप नहीं फैलती।

2026 में जो टीमें बार तय कर रही हैं, वे इसे पहले से चला रही हैं। Linear के पास design RFCs हैं। Vercel इंजीनियरिंग स्पेक के साथ प्रोडक्ट स्पेक भी शिप करता है। Anthropic research notes प्रकाशित करता है। Stripe design review docs चलाता है। Brian Lovin अपना लॉग एक सार्वजनिक पर्सनल साइट पर रखते हैं। Jordan Singer छोटे प्रोडक्ट शिप करते हैं और उनके साथ सार्वजनिक design diaries जोड़ते हैं। हर कमरे में वही आर्टिफ़ैक्ट।

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

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

डिज़ाइन का सबसे कम आँका गया आर्टिफ़ैक्ट डिसीजन लॉग है। केस स्टडी नहीं, Figma फ़ाइल नहीं, डेक नहीं। हर डिज़ाइन फ़ैसले का छोटा, structured, तारीख़वाला रिकॉर्ड, तर्क के साथ, काम शिप होने से पहले लिखा हुआ।

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

डिसीजन लॉग असल में क्या है

डिज़ाइन विकल्पों का structured रिकॉर्ड: विचार किए गए विकल्प, लागू बंदिशें, फ़ैसले के पीछे का तर्क, मालिक और नतीजा। छह फ़ील्ड, तारीख़वाले, ठोस, आर्टिफ़ैक्ट से जुड़े हुए। पूरी परिभाषा बस इतनी है।

यह केस स्टडी नहीं है। केस स्टडी हर चुनाव को अपरिहार्य दिखाती है। लॉग चुनाव को वैसा दिखाता है जैसा वह लिया गया था: मेज़ पर रखे विकल्प, उन्हें बाहर करने वाली बंदिशें, और वह नतीजा जिसका मालिक अब डिज़ाइनर है।

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

हायरिंग मैनेजर मॉकअप से ज़्यादा इसे क्यों पसंद करते हैं

चमकदार मॉकअप आउटपुट दिखाते हैं। डिसीजन लॉग judgment दिखाते हैं। 2026 में सीनियर हायरिंग मैनेजर लॉग पहले पढ़ते हैं, क्योंकि आउटपुट AI के लिए सस्ता है और judgment नहीं।

एक मॉडल आठ मिनट में चमकदार लैंडिंग पेज शिप कर देता है। जो हायरिंग मैनेजर वह पेज देखता है, उसे शिप करने वाले डिज़ाइनर के बारे में कुछ पता नहीं चलता। वही मॉडल, वही prompt, वही Dribbble रेफ़रेंस। AI द्वारा polish के कमोडिटी बन जाने के बाद भी सिर्फ़ लॉग बचता है, क्योंकि लॉग आउटपुट नहीं है, वह चुनावों का वह सिलसिला है जिसने बाक़ी अठारह की जगह यही आउटपुट बनाया।

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

यह प्रथा कहाँ से आई

डिसीजन लॉग सॉफ़्टवेयर से भी पुराना है। Christopher Alexander ने ऐसी pattern languages लिखीं जो इमारत के स्तर पर डिसीजन लॉग की तरह पढ़ी जाती हैं, हर पैटर्न तारीख़वाला, नामित, तर्कसंगत, विकल्पों के नोट के साथ। आर्किटेक्ट सदियों से डिज़ाइन बुक रखते आए हैं।

सॉफ़्टवेयर को यह RFC संस्कृति से विरासत में मिला। IETF 1969 से Request for Comments दस्तावेज़ प्रकाशित कर रहा है। Spotify, Pivotal और Thoughtworks के ADRs (architecture decision records) छोटे पैमाने पर वही आर्टिफ़ैक्ट हैं। सबसे ताज़ा विरासत रिसर्च लैब्स की है। Anthropic ऐसे research notes प्रकाशित करता है जो मॉडल के स्तर पर डिसीजन लॉग की तरह पढ़े जाते हैं।

तीन वंशावलियाँ, वही आर्टिफ़ैक्ट। डिज़ाइनर देर से अपनाने वाले हैं, और बार इतनी तेज़ी से उठ रहा है कि "देर" अब जूनियर जैसा लगने लगा है।

छह फ़ील्ड का टेम्पलेट, इसे कॉपी कीजिए

छह फ़ील्ड। Decision, Alternatives, Constraints, Reasoning, Owner, Outcome। टेम्पलेट जानबूझकर छोटा है। अनुशासन इसे लिखने में है, डिज़ाइन करने में नहीं। यह ब्लॉक कॉपी कीजिए। कल से इस्तेमाल कीजिए।

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

हर असली फ़ैसले के लिए एक एंट्री। हर प्रोजेक्ट में पाँच से दस एंट्री। कवर पेज छोड़ दीजिए। ऊपर वाला ब्लॉक ही असली काम है।

हर फ़ील्ड बिना हिचक के कैसे लिखें

हर फ़ील्ड का एक नियम है। नियम छोड़ा तो लॉग नाटक बन जाता है।

Decision। एक वाक्य, वर्तमान काल, ठोस। "ईमेल और पासवर्ड वर्टिकली स्टैक करें।" "हमें लगा कि वर्टिकल चल सकता है" नहीं। अगर फ़ैसला हुआ ही नहीं है, तो अभी एंट्री मत लिखिए।

Alternatives। नंबर वाली सूची, मेज़ पर रखे दो से चार असली विकल्प। पुतले नहीं। अगर सिर्फ़ एक पर विचार हुआ था, तो वही लिखिए और बताइए कि खोज क्यों रुक गई।

Constraints। बुलेट सूची, नामित, स्रोत के साथ। इंजीनियरिंग क्षमता, ब्रांड नियम, सपोर्ट टिकट, accessibility का न्यूनतम स्तर, performance budget। इनके बिना लॉग पसंद को तर्क का जामा पहनाने जैसा लगता है।

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

Owner। डिज़ाइनर का नाम लिखिए। रिव्यूअर का नाम लिखिए। बेनाम लॉग किसी सीनियर रिव्यूअर के सामने टिकते नहीं।

Outcome। शिप के दो हफ़्ते से दो महीने बाद भरिए, तारीख़ के साथ। मेट्रिक ने क्या किया, क्या दोबारा देखा गया, अगली बार क्या बदलेगा। "मैं magic-link वाले ब्लॉक पर ग़लत था" लिखने की हिम्मत लॉग का सबसे भरोसेमंद संकेत है।

लॉग कहाँ रखें

लॉग वहाँ रहे जहाँ टीम सच में उसे खोलेगी। स्टोरेज से ज़्यादा मायने नियमितता रखती है।

Notion। पूरी टीम के लिए सबसे आसान सेटअप। एक डेटाबेस, हर फ़ैसले की एक एंट्री, छह फ़ील्ड कॉलम की तरह। ज़्यादातर प्रोडक्ट टीमें इसके पैसे पहले से देती हैं और एक डिज़ाइनर इसे एक घंटे में खड़ा कर सकता है।

Linear docs। सही चुनाव अगर इंजीनियरिंग और डिज़ाइन पहले से वहीं रहते हैं। फ़ैसले उन issues के बगल में बैठते हैं जिन्होंने उन्हें जन्म दिया, और इंजीनियरिंग RFC में जाना बस एक क्लिक है।

रेपो में एक markdown फ़ाइल। design engineers और design system के मालिकों के लिए सही चुनाव। रेपो की जड़ में या /docs/decisions/ के नीचे रखी decisions.md गंभीर लगती है क्योंकि वह कोड के साथ versioned है। इंजीनियर इस फ़ॉर्मेट को देखते ही इज़्ज़त देते हैं।

छोटा निजी ब्लॉग या पर्सनल साइट। public trail बना रहे अकेले डिज़ाइनर के लिए सही चुनाव। Brian Lovin अपना ऐसे ही चलाते हैं। स्टैटिक साइट, तारीख़वाली एंट्री, सार्वजनिक लिंक। यह एक साथ पोर्टफ़ोलियो की सतह और हायरिंग में मौजूदगी बन जाता है।

एक चुनिए। एक तिमाही चलाइए। पहली चूक यह है कि टूल चुना और फिर कभी खोला ही नहीं।

Linear के design RFCs और Vercel के product specs

Linear अपने docs में design RFCs को पहली श्रेणी के आर्टिफ़ैक्ट की तरह चलाता है। हर अहम डिज़ाइन फ़ैसला एक RFC के साथ शिप होता है, काम से पहले लिखा हुआ, डिज़ाइन और इंजीनियरिंग लीड्स द्वारा रिव्यू किया हुआ, प्रोजेक्ट के साथ आर्काइव किया हुआ। RFC काम का हिस्सा है, बाद का write-up नहीं।

Vercel इंजीनियरिंग स्पेक के साथ प्रोडक्ट स्पेक उसी रेपो में शिप करता है। डिज़ाइन का फ़ैसला और इंजीनियरिंग का फ़ैसला एक ही डॉक में बैठते हैं, तारीख़वाले, मालिक वाले, रिव्यू किए हुए। टीम स्पेक को अनुबंध मानती है। जब v0 कोई नई सतह शिप करता है, तो स्पेक लॉन्च आर्टिफ़ैक्ट का हिस्सा होता है।

दोनों टीमें लिखित तर्क को craft का हिस्सा मानती हैं। बुधवार दोपहर का write-up नहीं। वैकल्पिक नहीं। आर्टिफ़ैक्ट उसी तरह काम है जैसे Figma फ़ाइल काम है, और बिना इसके आने वाला डिज़ाइनर अधूरा लगता है।

Anthropic के research notes और Stripe के design review docs

Anthropic ऐसे research notes प्रकाशित करता है जो मॉडल के स्तर पर डिसीजन लॉग जैसे पढ़े जाते हैं। क्या आज़माया, क्या चला, क्या नहीं चला, अगला क़दम क्या है। छोटे, तारीख़वाले, मालिक वाले, लिंक किए हुए। तीन पढ़ लीजिए तो प्रथा साफ़ हो जाती है। नोट्स रिकॉर्ड हैं, spin नहीं।

Stripe ऐसे design review docs चलाता है जो प्रोडक्ट साइकल के पार भी बचे रहते हैं। Stripe Press सार्वजनिक सतह है, भीतरी प्रथा उससे पुरानी है। रिव्यू लिखे जाते हैं, आर्काइव होते हैं, और अगले साइकल में मिलता-जुलता फ़ैसला आने पर दोबारा खोले जाते हैं। संस्थागत याददाश्त जो सालों में बढ़ती है, बजाय इसके कि किसी सीनियर डिज़ाइनर के जाते ही चली जाए।

अगर आप इसे अपनी टीम के craft में बिठाने में मदद चाहते हैं, तो Brainy को हायर कीजिए। BrandBrainy वह craft लेयर शिप करता है जिसकी AI नक़ल नहीं कर सकता। ClaudeBrainy वे Skill packs और prompt libraries शिप करता है जो लॉग को अनुशासन से डिफ़ॉल्ट बना देती हैं।

Brian Lovin और Jordan Singer अपना लॉग सार्वजनिक रखते हैं

Brian Lovin एक लंबे समय से चल रही पर्सनल साइट चलाते हैं जो उनके अपने काम पर सार्वजनिक डिसीजन लॉग की तरह पढ़ी जाती है। छोटे पेज, सीधा लेखन, डिज़ाइन के चुनाव तीन-चार वाक्यों में समझाए गए, तारीख़वाले, लाइव प्रोडक्ट से जुड़े। सालों की एंट्रियाँ। साइट एक साथ पोर्टफ़ोलियो और हायरिंग में मौजूदगी है, यही दोहरा उपयोग the anti-portfolio प्लेबुक का सहारा है।

Jordan Singer छोटे प्रोडक्ट शिप करते हैं और उनके साथ सार्वजनिक design diaries जोड़ते हैं। हर प्रोजेक्ट के पीछे के फ़ैसलों का लिखित रिकॉर्ड सार्वजनिक रूप से पोस्ट होता है, और "यह नहीं चला" ज़ोर से कहने की हिम्मत के साथ। डायरी एक साथ मार्केटिंग है, रिकॉर्ड है और हायरिंग आर्टिफ़ैक्ट भी।

दोनों ऐसे टेम्पलेट हैं जिन्हें कोई भी काम करता डिज़ाइनर इसी हफ़्ते कॉपी कर सकता है। स्टैटिक साइट, छह फ़ील्ड की एंट्री, तारीख़वाली, सार्वजनिक, लिंक की हुई। हर एंट्री पर पंद्रह मिनट। महीने में तीन। साल भर बाद सार्वजनिक लॉग उस तरह सीनियर लगता है जैसा कोई Behance केस स्टडी कभी नहीं लगती।

सावधानी वाला हिस्सा: बाद में गढ़ा गया तर्क

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

पहचान alternatives फ़ील्ड में है। जीवित लॉग उन विकल्पों को गिनाता है जो सच में मेज़ पर थे, अक्सर एक विकल्प मज़बूत सुनाई देता है। बाद में लिखा लॉग तीन ऐसे विकल्प गिनाता है जिन पर लिखने वाले ने कभी गंभीरता से सोचा ही नहीं, ताकि चुना हुआ विकल्प स्वाभाविक लगे। हायरिंग मैनेजर यही अभ्यास सौ बार कर चुका है। उसे पता है spin कैसा दिखता है।

दूसरी पहचान outcome फ़ील्ड है। जीवित लॉग में ऐसे नतीजे होते हैं जो अनुमान से मेल नहीं खाए। "मुझे conversion बढ़ने की उम्मीद थी, टेस्ट सपाट रहा, यहाँ ग़लत क्या हुआ।" नाटक वाले लॉग में सिर्फ़ जीतें होती हैं, असलियत से बेहतर दिखने के लिए पहले से गोल की हुई।

इलाज असहज है। एंट्री काम शिप होने से पहले लिखिए। तारीख़ डालिए। उसे ऐसे रिव्यूअर को दीजिए जो पलटकर सवाल करेगा। नतीजा दो हफ़्ते बाद भरिए, ख़बर बुरी हो तब भी। ख़ासकर तब। ईमानदार एंट्री का ब्याज बढ़ता है।

इंटरव्यू और रिव्यू में लॉग का इस्तेमाल कैसे करें

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

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

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

जो डिज़ाइनर लॉग का बचाव कर सकता है, वह काम का बचाव करता है। जिसके पास लॉग नहीं, वह किसी चीज़ का बचाव नहीं करता।

नया बार: लॉग के बिना सीनियर काम जूनियर जैसा पढ़ा जाता है

डिसीजन लॉग अब सीनियर के लिए "होता तो अच्छा" वाली चीज़ नहीं है। यह सीनियर judgment का सबसे सस्ता संकेत है जो कोई डिज़ाइनर शिप कर सकता है, और इसे छोड़ने की क़ीमत बढ़ रही है।

सार्वजनिक लॉग वाला सीनियर पोर्टफ़ोलियो सीनियर पढ़ा जाता है। बिना लॉग वाला ऐसा काम लगता है जो शायद सीनियर रहा हो, कहना मुश्किल। हायरिंग मैनेजर दोनों पढ़ते हैं। कॉल पहले वाले को वापस आती है। तीन छोटे प्रोजेक्ट पर लॉग वाला जूनियर अपने स्तर से आगे दिखता है। बारह परफ़ेक्ट Dribbble शॉट्स और बिना लॉग वाला जूनियर वही जूनियर दिखता है जो वह साल भर पहले था।

2026 में Taste is the last moat इसलिए है कि प्रोडक्शन कमोडिटी हो गया, और लॉग वह सार्वजनिक आर्टिफ़ैक्ट है जो साबित करता है कि काम में taste मौजूद है। अगर आप design engineering हाइब्रिड के रूप में शिप करते हैं, तो लॉग डिज़ाइन लेयर पर इंजीनियरिंग RFC का भी काम करता है। अगर आप the new design career ladder चढ़ रहे हैं, तो लॉग वही आर्टिफ़ैक्ट है जिस पर सीढ़ी टिकी है।

FAQ

डिज़ाइन डिसीजन लॉग क्या है?

डिज़ाइन चुनावों का छोटा structured रिकॉर्ड, जिसके साथ तर्क जुड़ा हो। हर एंट्री में छह फ़ील्ड: Decision, Alternatives, Constraints, Reasoning, Owner, Outcome। तारीख़वाली, ठोस, आर्टिफ़ैक्ट से जुड़ी।

यह केस स्टडी से कैसे अलग है?

केस स्टडी हर चुनाव को अपरिहार्य दिखाती है। लॉग चुनावों को वैसा दिखाता है जैसे वे सच में लिए गए थे: मेज़ पर रखे विकल्प, फ़ैसले को बाँधने वाली बंदिशें, और अपनाया हुआ नतीजा। केस स्टडी बेचती हैं। लॉग दर्ज करते हैं।

इसे कहाँ रखूँ?

जहाँ आपकी टीम सच में इसे खोलेगी। प्रोडक्ट टीमों के लिए Notion, पहले से Linear पर मौजूद टीमों के लिए Linear docs, design engineers के लिए रेपो में markdown फ़ाइल, और अकेले डिज़ाइनर के सार्वजनिक सिलसिले के लिए छोटी निजी साइट।

हर एंट्री कितनी लंबी होनी चाहिए?

छोटी। पूरा टेम्पलेट एक स्क्रीन में आ जाता है। हर एंट्री पर पंद्रह मिनट।

अगर मेरी कंपनी इसे नहीं अपनाएगी तो?

इसे निजी तौर पर चलाइए। डिज़ाइनर का अपना लॉग नौकरियों के पार बढ़ता है। Brian Lovin और Jordan Singer अपना सार्वजनिक रखते हैं। यह प्रथा आपकी है, आपके नियोक्ता की नहीं, और आर्टिफ़ैक्ट आपके साथ चलता है।

इसी हफ़्ते लॉग शुरू कीजिए

तीन क़दम। स्टोरेज सेट कीजिए। Notion, Linear, रेपो या छोटी साइट में से चुनिए। इसे तीस मिनट में खड़ा कीजिए। वही चुनिए जिसे आप कल खोलेंगे।

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

लॉग किसी एक सीनियर रिव्यूअर को दिखाइए। उनसे कहिए कि तर्क पर पलटकर सवाल करें। पलटवार को संकेत मानिए। एंट्रियाँ अपडेट कीजिए। लॉग का बढ़ना पहले रिव्यू से शुरू होता है।

अगर आप डिसीजन-लॉग की प्रथा को अपनी टीम के craft में बिठाने में मदद चाहते हैं, तो Brainy को हायर कीजिए। BrandBrainy वह ब्रांड और craft लेयर शिप करता है जिसकी AI नक़ल नहीं कर सकता। ClaudeBrainy वे Skill packs और prompt libraries शिप करता है जो लॉग को अनुशासन से डिफ़ॉल्ट बना देती हैं। जो टीमें इसे पहले से चला रही हैं, वे आगे निकल रही हैं। बार ऊपर उठ रहा है, और जो डिज़ाइनर इसी हफ़्ते शुरू करेगा, वही वह होगा जिसे ये नामी टीमें एक तिमाही बाद पढ़ रही होंगी।