UI से पहले अनुमोदन मैट्रिक्स डिज़ाइन: स्क्रीन से पहले नियम मैप करें

स्पष्ट मैट्रिक्स के बिना स्क्रीन क्यों नाकाम रहती हैं

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

यह भ्रम असल काम में जल्दी दिखने लगता है। कोई अनुरोध सबमिट करता है, वह ऐप में आ जाता है, और पहला सवाल होता है, "क्या यह मैनेजर के पास जाए, फाइनेंस के पास, या दोनों के पास?" स्क्रीन तो तैयार दिखती है, पर निर्णय का रास्ता गायब होता है।

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

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

फिर एक बड़ी समस्या सामने आती है: हर टीम अपने तरीके से नियम लागू करने लगती है। ऑपरेशंस अनुरोध एक तरह भेजता है, फाइनेंस दूसरे तरीके से, और सपोर्ट HR से अलग अपवाद संभालता है। ऐप एक साझा स्क्रीन बन जाता है जो असंगत निर्णयों के लिए इस्तेमाल होती है, न कि एक साझा प्रक्रिया के लिए।

चेतावनी संकेत आमतौर पर पहचानने में आसान होते हैं:

• उपयोगकर्ता पूछते हैं कि अगले कदम का मालिक कौन है
• समान अनुरोधों के अलग परिणाम अलग टीमों में मिलते हैं
• अपवाद चैट या ईमेल में संभाले जाते हैं
• नीति परिवर्तन स्क्रीन बदलने पर मजबूर करते हैं बजाय नियम बदलने के

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

स्क्रीन को निर्णय मार्ग को प्रतिबिंबित करना चाहिए, पर उसे परिभाषित नहीं करना चाहिए। जब मैट्रिक्स पहले स्पष्ट होता है, UI सरल, स्थिर और उपयोग में आसान बन जाता है।

किसी भी वायरफ़्रेम से पहले क्या मैप करें

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

हर अनुरोध प्रकार के लिए, अनुमोदन स्तरों को क्रम में मैप करें। लिखें कि किस रोल का कदम है और वह कदम क्या करने की अनुमति देता है: अनुमोदन, अस्वीकृति, समीक्षा, या संपादन के लिए वापस भेजना। रोल व्यक्तिगत नामों से बेहतर होते हैं क्योंकि लोग बदलते हैं, टीमें बदलती हैं, और प्रक्रिया को टिके रहना चाहिए।

फिर उन नियमों को परिभाषित करें जो मार्ग बदलते हैं। राशि सबसे स्पष्ट ट्रिगर है, पर आम तौर पर अकेला कारण नहीं होता। अनुमोदन वर्कफ़्लो नियम अक्सर क्षेत्र, विभाग, विक्रेता प्रकार, अनुरोध श्रेणी, या जोखिम स्तर पर निर्भर करते हैं। वही राशि एक टीम में सामान्य हो सकती है और दूसरी में संवेदनशील।

अनुपस्थितियों के लिए भी नियम चाहिए। अगर मुख्य अनुमोदक बाहर है, तो कौन तुरंत जिम्मेदारी संभालेगा? अगर बैकअप अस्थायी है, तो किन तिथियों तक? बिना इनके, अनुरोध रुके रहते हैं क्योंकि इस सप्ताह उनका मालिक कौन है यह कोई नहीं जानता।

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

एक व्यावहारिक मैट्रिक्स आमतौर पर पाँच बुनियादी प्रश्नों के उत्तर देता है:

• किस स्थिति से यह नियम शुरू होता है?
• इस चरण में कौन सा रोल अनुमोदन करता है?
• बैकअप कौन है?
• अनुमोदक के पास कार्रवाई करने के लिए कितना समय है?
• अगर डेडलाइन मिस हो जाती है तो क्या होता है?

यदि आप इन उत्तरों को जल्दी मैप कर लें तो बाकी बिल्ड बहुत आसान हो जाता है।

कदम दर कदम मैट्रिक्स कैसे बनाएं

एक टेबल, व्हाइटबोर्ड, या स्प्रेडशीट का उपयोग करें। इसे इतना सरल रखें कि एक मैनेजर, टीम लीड और प्रोसेस ओनर एक बार में समझ सकें।

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

अगले कदम में पहले अनुमोदक और उसके बाद के प्रत्येक निर्णय बिंदु को लिखें। हर अनुरोध प्रकार के लिए नोट करें कि कौन पहले इसकी समीक्षा करता है और अनुमोदन या अस्वीकृति के बाद क्या होता है। रास्ते का पालन तब तक करें जब तक आप अंतिम परिणाम तक न पहुँचें जैसे कि अनुमोदित, अस्वीकृत, बदलाव के लिए वापस भेजा गया, या रद्द।

उसके बाद उन थ्रेशहोल्ड्स को जोड़ें जो मार्ग बदलते हैं। यही वह हिस्सा है जहाँ कई टीमें बाद में अटक जाती हैं। अगर $500 से कम के अनुरोध टीम लीड को जाते हैं पर $500 से ऊपर विभाग प्रमुख को जाते हैं, तो यह अब लिख दें। अगर इमरजेंसी अनुरोध किसी कदम को छोड़ देते हैं या तेज़ रास्ता लेते हैं, तो उसे भी कैप्चर करें।

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

अंत में, ड्राफ्ट की समीक्षा उन लोगों के साथ करें जो आज अनुरोध मंज़ूर करते हैं। पूछें कि काम आमतौर पर कहाँ रुकता है, लोग किन स्टेप्स को स्किप करते हैं, और जब सामान्य अनुमोदक अनुपलब्ध होता है तब क्या होता है। असल आदतें अक्सर उन नियमों को उजागर कर देती हैं जो कभी दस्तावेज़ नहीं हुए।

एक छोटा उदाहरण इसे स्पष्ट कर देता है। एक खरीद अनुरोध की कल्पना करें: कार्यालय की सामग्री $200 तक टीम लीड को जाती है, सॉफ़्टवेयर $200 से $2,000 के बीच विभाग मैनेजर को जाता है, और इससे ऊपर की राशि में फाइनेंस की भी ज़रूरत होती है। अगर फॉर्म शुरुआत में राशि और श्रेणी पकड़ नहीं पाता, तो UI अनुरोध को सही रास्ते पर नहीं भेज पाएगा।

ऐसी सीमाएँ सेट करें जिन्हें लोग वास्तव में फ़ॉलो कर सकें

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

एक स्पष्ट नियम कुछ ऐसा लगेगा: "$1,000 तक टीम लीड को। $1,001 से $5,000 तक विभाग मैनेजर को। $5,000 से ऊपर फाइनेंस और डायरेक्टर।" किसी को अनुमान लगाने की ज़रूरत नहीं रह जाती कि अनुरोध कहाँ जाना चाहिए।

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

अधिकांश टीमों को केवल कुछ रूटिंग नियमों की ज़रूरत होती है। आम उदाहरणों में राशि रेंज, विक्रेता की स्थिति, खरीद श्रेणी, विभाग, और तात्कालिकता शामिल हैं। महत्वपूर्ण हिस्सा नियमों की संख्या नहीं, बल्कि यह है कि क्या हर कोई उन्हें एक ही तरीके से लागू करता है।

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

यह भी मदद करता है कि यह परिभाषित करें कि कौन थ्रेशहोल्ड को ओवरराइड कर सकता है, और कब। इसके बिना स्टाफ या तो बहुत देर तक इंतज़ार करते हैं या प्रक्रिया को ईमेल और चैट में बाईपास कर देते हैं। "महीने के अंत में फाइनेंस डायरेक्टर सीमा से ऊपर के अनुरोध मंज़ूर कर सकते हैं" उपयोगी है। "सीनियर लीडरशिप अपवाद कर सकती है" स्पष्ट नहीं।

एक सरल परीक्षण यहाँ अच्छा काम करता है: एक ही उदाहरण अनुरोध तीन लोगों को दें और पूछें कि यह कहाँ जाना चाहिए। अगर उन्हें तीन अलग जवाब मिलते हैं, तो थ्रेशहोल्ड अभी भी बहुत अस्पष्ट हैं।

बैकअप अनुमोदक, प्रतिस्थापक, और एस्कलेशन की योजना बनाएं

एक मजबूत मैट्रिक्स मुख्य अनुमोदक पर ही नहीं रुकता। वास्तविक काम तब चलता रहता है जब कोई व्यक्ति छुट्टी पर हो, बीमार हो, या समय पर प्रतिक्रिया न दे। अगर आप इसके लिए पहले से योजना नहीं बनाते, तो स्क्रीन ठीक दिख सकती है पर प्रक्रिया चुपचाप अटक जाएगी।

हर महत्वपूर्ण चरण के लिए बैकअप अनुमोदक नामित करके शुरू करें। यह किसी ऐसे व्यक्ति या रोल को होना चाहिए जिनके पास उपयुक्त संदर्भ हो, सिर्फ़ "अगला मैनेजर" डिफ़ॉल्ट न रखें। अगर फाइनेंस लीड एक निश्चित राशि से ऊपर खर्चों को मंज़ूरी देता है, तो तय करें कि वह व्यक्ति अनुपलब्ध होने पर कौन कदम उठाता है।

अस्थायी प्रतिस्थापकों की सीमाएँ होनी चाहिए। एक प्रतिस्थापक को केवल परिभाषित अवधि के लिए अनुमोदन अधिकार मिले, जैसे छुट्टी की तिथियाँ या नियोजित अवकाश। इससे ज़िम्मेदारी स्पष्ट रहती है और ऐसे मामले टाले जाते हैं जहाँ किसी के पास अनुमोदन एक्सेस लंबे समय तक बने रहते हैं जबकि उसे नहीं रखना चाहिए।

एक सरल सेटअप चार चीजों का जवाब देता है: मुख्य अनुमोदक कौन है, बैकअप कौन है, प्रतिस्थापक कितनी देर तक कार्य कर सकता है, और कब अनुरोध चेन में ऊपर जाता है।

एस्कलेशन स्पष्ट ट्रिगर्स पर आधारित होने चाहिए, अनुमान पर नहीं। आम ट्रिगर्स समय, राशि, जोखिम, या ग़ायब जानकारी होते हैं। उदाहरण के लिए, अगर $10,000 से ऊपर का खरीद अनुरोध 24 घंटे तक छुआ नहीं रहता, तो वह विभाग प्रमुख तक एस्केलेट हो सकता है।

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

हर निर्णय को रिकॉर्ड करें। किसने अनुमोदन किया, किसने प्रतिस्थापन किया, हैंडऑफ़ कब हुआ और क्यों अनुरोध एस्केलेट हुआ—यह इतिहास बाद में पूछे जाने पर मायने रखता है।

एक और नियम बहुत महत्वपूर्ण है: लूप्स से बचें। किसी अनुरोध को कभी भी किसी ऐसे व्यक्ति के पास वापस नहीं जाना चाहिए जिसने पहले ही उसे मंज़ूर किया हो, या उसी व्यक्ति के लिए काम कर रहे प्रतिस्थापक के पास नहीं जाना चाहिए। किसी भी ऐप लॉजिक को बनाते समय मैट्रिक्स में सर्कुलर पाथ्स की जाँच करें।

एक सरल उदाहरण: खरीद अनुरोध अनुमोदन

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

अगर अनुरोध $420 का है, तो वह सीधे टीम लीड के पास जाता है। इससे छोटी खरीदें तेज़ रहती हैं। $3,200 का अनुरोध टीम लीड को छोड़कर विभाग मैनेजर के पास जाता है क्योंकि बजट प्रभाव बड़ा है।

अब मानिए $7,800 का अनुरोध नया उपकरण के लिए है। विभाग मैनेजर इसकी समीक्षा करता है, पर वही काफी नहीं है। चूँकि राशि $5,000 से ऊपर है, फाइनेंस को भी इसकी समीक्षा करनी होगी। यहीं एक स्पष्ट मैट्रिक्स मदद करता है: उच्च राशि नियंत्रण बढ़ाती है बिना अंदाज़े के।

अनुपस्थितियाँ यहाँ भी मायने रखती हैं। अगर विभाग मैनेजर छुट्टी पर है, तो अनुरोध को ठहरना नहीं चाहिए। एक नामित प्रतिस्थापक को यह ऑटोमेटिक रूप से मिल जाना चाहिए और वह परिभाषित अवधि के लिए कार्य कर सकता है।

समय सीमाएँ भी उसी स्पष्टता की मांग करती हैं। अगर दो दिनों में कोई कार्रवाई नहीं होती, तो अनुरोध ऑपरेशंस पर एस्केलेट होता है। ऑपरेशंस फ़ॉलो-अप कर सकता है, उसे रीअसाइन कर सकता है, या सुनिश्चित कर सकता है कि वह काम ब्लॉक न करे।

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

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

पुनःकार्य का कारण बनने वाली सामान्य गलतियाँ

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

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

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

टीमें तब भी परेशानी खड़ी करती हैं जब वे दो लोगों को एक ही काम दे देती हैं बिना टाई-ब्रेक नियम के। अगर दोनों अनुमोदक हैं, तो कौन पहले कार्रवाई करेगा? यदि वे असहमत हैं, तो किसका निर्णय मान्य होगा? इसके बिना अनुरोध उछलते रहते हैं और उपयोगकर्ता भरोसा खो देते हैं।

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

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

एक त्वरित रियलिटी चेक इसे जल्दी पकड़ने में मदद करता है:

• क्या दो अनुमोदक एक ही अनुरोध एक साथ प्राप्त कर सकते हैं?
• क्या अस्थायी बैकअप और स्थायी मालिक में स्पष्ट अंतर है?
• क्या तात्कालिक या विनियमित मामलों का अलग मार्ग है?
• क्या प्रत्येक रूटिंग निर्णय उस फ़ील्ड पर निर्भर करता है जो पहले से मौजूद है?
• क्या प्रक्रिया तब भी समझ में आती अगर एक अनुमोदक कंपनी छोड़ दे?

अगर किसी भी उत्तर में अस्पष्टता है, वहीं रुकें। स्क्रीन चमकाने से पहले मैट्रिक्स ठीक करें।

स्क्रीन डिज़ाइन से पहले तेज़ जाँचें

फॉर्म या स्टेटस बैज स्केच करने से पहले लॉजिक को सादी भाषा में टेस्ट करें। एक अच्छा अनुमोदन मैट्रिक्स बिना डायग्राम खोले आसानी से समझाया जा सके। अगर एक मैनेजर, फाइनेंस लीड, या ऑपरेशंस साथी एक मिनट में पूरा रूट बता नहीं पा रहा, तो UI काम के लिए प्रक्रिया अभी भी बहुत अस्पष्ट है।

वास्तविक उदाहरणों से फास्ट रिव्यू चलाएं। एक व्यक्ति से अनुरोध से लेकर अंतिम निर्णय तक पूरा रूट बताने को कहें। चेक करें कि हर संभावित परिणाम के लिए अगले अनुमोदक का नामित उत्तर है, सिर्फ़ "हैप्पी पाथ" नहीं। अस्पष्ट थ्रेशहोल्ड्स को सटीक नियमों में फिर लिखें जैसे "$1,000 और उससे कम" या "10% से अधिक छूट"। पुष्टि करें कि बैकअप और एस्कलेशन नियम स्पष्ट समय सीमाएँ उपयोग करते हैं जैसे "24 घंटे के बाद" या "2 कार्य दिवस के बाद"।

फिर ट्रेसेबिलिटी टेस्ट करें। बाद में कोई पूछेगा कि अनुरोध क्यों देरी हुआ, किसने अपवाद मंज़ूर किया, या प्रतिस्थापक कब आया। आपकी प्रक्रिया पहले से ही उन सवालों के जवाब दे सके। टाइमस्टैम्प, निर्णय इतिहास, और स्पष्ट स्टेटस बदलाव एक्स्ट्रा नहीं हैं—वे नियम सेट का हिस्सा हैं।

एक साधारण परिदृश्य अक्सर कमजोरियां उजागर कर देता है। कल्पना करें $4,800 का खरीद अनुरोध शुक्रवार की दोपहर आता है जबकि सामान्य अनुमोदक बाहर है। अब कौन उसे पाता है? सिस्टम कब तक इंतज़ार करता है इससे पहले कि वह आगे बढ़े? अगर बैकअप भी कुछ नहीं करता तो क्या होता है? अगर उन जवाबों को लिखित नहीं किया गया है तो UI भ्रम छुपाएगी बजाय उसे हल करने के।

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

अगला कदम: मैट्रिक्स को कामकाजी ऐप में बदलें

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

एक व्यावहारिक पहले संस्करण में आमतौर पर बेसिक्स होते हैं: अनुरोध प्रकार, राशि, विभाग, वर्तमान अनुमोदक, अंतिम स्टेटस, और हर निर्णय का स्पष्ट इतिहास। फिर वे नियम जोड़ें जो अनुरोध को आगे बढ़ाते हैं, बैकअप अनुमोदक को भेजते हैं, या जब कोई समय पर जवाब नहीं देता तो एस्केलेट ट्रिगर करते हैं।

पहली स्क्रीनें सरल रखें। एक अनुरोधकर्ता को सबमिट करना, स्टेटस चेक करना और फ़ॉलो-अप प्रश्नों का जवाब देना चाहिए आसान होना चाहिए। एक अनुमोदक को समीक्षा करना, अनुमोदन/अस्वीकृति करना या रीअसाइन करना चाहिए। यही काफी है यह टेस्ट करने के लिए कि वर्कफ़्लो रोज़मर्रा के उपयोग में समझ में आता है या नहीं।

एक समझदारी भरा बिल्ड आदेश सरल है:

• कोर डेटा फ़ील्ड और स्टेटस मान परिभाषित करें
• थ्रेशहोल्ड्स, बैकअप अनुमोदक, प्रतिस्थापक और एस्कलेशन के लिए रूटिंग नियम जोड़ें
• अनुरोधकर्ता और अनुमोदकों के लिए बेसिक स्क्रीन बनाएं
• सुनिश्चित करें कि हर चैनल एक ही सोर्स ऑफ़ ट्रुथ उपयोग करता है
• व्यापक रोलआउट से पहले एक वास्तविक अनुरोध को शुरू से अंत तक टेस्ट करें

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

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

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

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