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

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

एक अच्छा ब्रीफ पहले दिन समय बचाता है। एक कमजोर ब्रीफ फ्रीलांसर के वायरफ्रेम फ़ाइल खोलने से पहले 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 के बाद कोई नई विशेषता अलग से अनुमानित की जाएगी।” वह पंक्ति बजट की रक्षा करती है और वेब ऐप को एक दिशा में आगे बढ़ाती है।

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