उपयोगकर्ता खातों के साथ एक वेब ऐप के लिए फ्रीलांस ब्रीफ कैसे लिखें

उपयोगकर्ता खातों के साथ एक वेब ऐप के लिए फ्रीलांस ब्रीफ कैसे लिखें

एक अच्छा ब्रीफ दिन 1 पर समय बचाता है। एक कमजोर ब्रीफ फ्रीलांसर के वायरफ्रेम फ़ाइल खोलने से पहले 10 फॉलो-अप प्रश्न उत्पन्न करता है। यदि आप उपयोगकर्ता खातों के साथ एक वेब ऐप के लिए फ्रीलांस ब्रीफ लिखने का तरीका समझ रहे हैं, तो व्यवसाय की समस्या से शुरू करें, मेनू लेबल से नहीं। एक स्पष्ट परिणाम तीन अस्पष्ट इच्छाओं से बेहतर है।

1. वेब ऐप का उद्देश्य और व्यवसायिक लक्ष्य परिभाषित करें

वेब ऐप क्या करता है, इसे एक साधारण पैराग्राफ में कहें। एक फ्रीलांसर को यह जानने की आवश्यकता है कि यह एक क्लाइंट पोर्टल है, एक बुकिंग सिस्टम, एक लर्निंग डैशबोर्ड, या एक सब्सक्रिप्शन उत्पाद। उद्देश्य में उपयोगकर्ता और परिणाम का नाम होना चाहिए: “ग्राहक ऑर्डर ट्रैक करने के लिए लॉग इन करते हैं” “एक आधुनिक प्लेटफॉर्म संलग्नता के लिए” से बेहतर है।

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

व्यवहार में सफलता कैसी दिखती है, यह बताएं। उदाहरण के लिए: “एक उपयोगकर्ता एक खाता बना सकता है, ईमेल सत्यापित कर सकता है, और 3 मिनट के भीतर एक पहला कार्य पूरा कर सकता है।” यह एकल पंक्ति फ्रीलांसर को सामान्य उत्साह के एक पृष्ठ से अधिक बताती है। यह काम को एक वास्तविक परिणाम से भी जोड़े रखता है, न कि एक काल्पनिक उत्पाद डेक से।

2. उपयोगकर्ता प्रकारों और खाता आवश्यकताओं का वर्णन करें

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

पंजीकरण और लॉगिन नियमों को ठोस चरणों में स्पष्ट करें। क्या ईमेल और पासवर्ड का उपयोग किया जाएगा? सामाजिक लॉगिन? जादुई लिंक? दो-कारक प्रमाणीकरण? कहें कि कौन सा आवश्यक है और कौन सा वैकल्पिक है। यदि पहुंच से पहले ईमेल सत्यापन अनिवार्य है, तो वह लिखें।

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

यदि आपके ऐप में एक से अधिक खाता प्रकार हैं, तो एक सरल तालिका जोड़ें। यह संक्षिप्त विवरण को स्कैन करना आसान बनाता है और गलतफहमी को कठिन बनाता है।

3. मुख्य विशेषताओं और उपयोगकर्ता प्रवाहों का खाका तैयार करें

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

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

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

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

4. डिज़ाइन, सामग्री, और ब्रांडिंग आवश्यकताओं को निर्दिष्ट करें

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

उन पृष्ठों की सूची बनाएं जिन्हें फ्रीलांसर को डिज़ाइन करना चाहिए। एक साधारण ऐप को 6 या 7 की आवश्यकता हो सकती है: लैंडिंग पृष्ठ, साइन अप, लॉगिन, डैशबोर्ड, प्रोफ़ाइल, सेटिंग्स, प्रशासन पैनल। यदि आपके पास कानूनी पृष्ठ, सहायता पृष्ठ, या ऑनबोर्डिंग स्क्रीन हैं, तो उन्हें शामिल करें। अन्यथा, वे अंतिम सप्ताह तक गायब हो जाते हैं, जो आमतौर पर गलत सप्ताह होता है।

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

आप जिन ऐप्स को पसंद करते हैं, उनके 2 या 3 उदाहरण और 1 उदाहरण जिसे आप पसंद नहीं करते हैं, उसके साथ प्रत्येक के लिए एक कारण शामिल करें। "मुझे ऐप A का डैशबोर्ड पसंद है क्योंकि यह एक नज़र में स्थिति दिखाता है" उपयोगी है। "मुझे ऐप B पसंद नहीं है क्योंकि यह बहुत सारे क्लिक के पीछे खाता सेटिंग्स छुपाता है" यह भी उपयोगी है। एक फ्रीलांसर इसके साथ काम कर सकता है। एक मूड शब्द नहीं कर सकता।

5. तकनीकी आवश्यकताएँ और एकीकरण सेट करें

यदि आपके पास कोई स्टैक है तो तकनीकी आवश्यकताओं में उसका नाम होना चाहिए। यदि आपको पहले से ही React, Django, Laravel, या किसी अन्य फ्रेमवर्क की आवश्यकता है, तो ऐसा कहें। यदि फ्रीलांसर चुन सकता है, तो कहें कि विकल्प खुला है लेकिन आपके होस्टिंग और रखरखाव योजना के अनुसार होना चाहिए। यह उन स्थानों में से एक है जहाँ एक अस्पष्ट संक्षिप्त विवरण महंगा हो जाता है।

होस्टिंग, डेटाबेस, फ़ाइल भंडारण, और तृतीय-पक्ष सेवाओं की सूची बनाएं। यदि ऐप को Stripe, SendGrid, Google Maps, Slack, या एक CRM से कनेक्ट करना है, तो प्रत्येक सेवा का नाम लिखें। यदि कोई API पहले से मौजूद है, तो दस्तावेज़ीकरण लिंक और संस्करण नोट करें। यदि वेबहुक की आवश्यकता है, तो कहें कि उन्हें क्या ट्रिगर करना चाहिए। एक फ्रीलांसर एक एकीकरण का आकार नहीं जान सकता और फिर भी आपको एक ठोस अनुमान दे सकता है।

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

संगतता की आवश्यकताएँ यहाँ भी होनी चाहिए। बताएं कि क्या ऐप को Chrome, Safari, और Firefox के नवीनतम 2 संस्करणों पर काम करना चाहिए, या केवल डेस्कटॉप पर, या मोबाइल ब्राउज़रों पर भी। यदि पहुंच महत्वपूर्ण है, तो बताएं कि आप किस स्तर की अपेक्षा करते हैं। ये विवरण परीक्षण समय को आकार देते हैं, और परीक्षण समय उद्धरण को बदलता है।

6. डिलीवर करने योग्य, मील के पत्थर, और समीक्षा प्रक्रिया को परिभाषित करें

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

प्रत्येक मील के पत्थर को एक ठोस आउटपुट दें। उदाहरण के लिए: “मील का पत्थर 1: 8 स्क्रीन के लिए उपयोगकर्ता प्रवाह मानचित्र और वायरफ्रेम।” “मील का पत्थर 2: क्लिक करने योग्य प्रोटोटाइप।” “मील का पत्थर 3: लॉगिन, डैशबोर्ड, और प्रोफ़ाइल के लिए विकास निर्माण।” भले ही बाद में संख्याएँ बदलें, संरचना मदद करती है। “डिज़ाइन चरण” जैसे अस्पष्ट मील के पत्थर बहस को आमंत्रित करते हैं।

फ्रीलांसर को बताएं कि फीडबैक कैसे काम करता है। क्या आप 2 हितधारकों की टिप्पणियों को एक दस्तावेज़ में संकलित करेंगे? क्या संशोधन Figma, एक प्रोजेक्ट बोर्ड, या ईमेल में होंगे? कितने संशोधन राउंड शामिल हैं? यदि कोई अंतिम अनुमोदन का मालिक नहीं है, तो परियोजना एक बटन के रंग या एक शीर्षक लेबल पर हफ्तों तक रुक सकती है।

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

7. बजट, समयसीमा, और संचार विवरण जोड़ें

बजट एक सीमा होनी चाहिए, कोई रहस्य नहीं। यदि आप $3,000 से $5,000 खर्च कर सकते हैं, तो ऐसा कहें। यदि बजट निश्चित है, तो वह भी कहें। एक फ्रीलांसर जो सीमा जानता है, सही दायरा प्रस्तावित कर सकता है बजाय इसके कि वह संकीर्ण संख्या में बहुत कुछ पैक करे। इससे दोनों पक्षों को अजीब आश्चर्य से बचने में मदद मिलती है।

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

एक मुख्य संचार चैनल चुनें और उसी पर टिके रहें। स्लैक, ईमेल, या एक परियोजना बोर्ड ठीक काम करते हैं, लेकिन सभी 3 को मिलाना आमतौर पर लोगों को धीमा कर देता है। बताएं कि आप कितनी बार अपडेट चाहते हैं: दैनिक, सप्ताह में दो बार, या प्रत्येक मील का पत्थर समाप्त होने पर। यदि आप 24 घंटे के भीतर उत्तर की अपेक्षा करते हैं, तो इसे स्पष्ट रूप से लिखें ताकि किसी को अनुमान न लगाना पड़े।

निर्णय नियमों के साथ संक्षिप्त को बंद करें। कहें कि स्कोप परिवर्तनों को कौन मंजूरी दे सकता है, भुगतान पर कौन हस्ताक्षर करता है, और अंतिम उत्पाद खाता किसका है। उल्लेख करें कि यदि काम शुरू होने के बाद संक्षिप्त में परिवर्तन होता है तो क्या होगा। यहां तक कि एक वाक्य मदद करता है: “माइलस्टोन 2 के बाद कोई भी नई विशेषता अलग से अनुमानित की जाएगी।” यह पंक्ति बजट की रक्षा करती है और वेब ऐप को एक दिशा में आगे बढ़ाती है।

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