يبدأ التطبيق المفيد بمهمة مستخدم حقيقية واحدة
يجب أن يجعل تطبيق ويب3 مهمة مفيدة واحدة سهلة الفهم. تخيل استوديو على وشك فتح نسخة تجريبية مغلقة، في المساء الذي يسبق جلسة AMA. يريد فريقه أن يجرب الأعضاء تدفقًا على الموبايل، لذا سنقوم برسم خطوة المحفظة قبل اختيار الشاشات.
قد تكون تلك المهمة الأولى هي التحقق من الرصيد، أو استخدام ميزة DeFi، أو رؤية مكافأة ولاء. نبدأ بسؤال ما يحتاج الشخص إلى فعله. نسأل عن المعلومات التي يحتاجها، وأي إجراء يتطلب اتصالاً بالمحفظة أو البلوكشين. هذا يعطي الفريق طريقة عملية لفصل أساسيات الإطلاق عن الأفكار التي يمكن أن تنتظر.
يمكن أن يناسب العمل منتجًا جديدًا أو جزءًا موبايل من خدمة ويب3 أوسع. نربط خطة التطبيق بالمنتج الحالي، وإعداده التقني، والأشخاص الذين سيصونونه. إذا كانت هناك حاجة أيضًا إلى تجربة قائمة على المتصفح، فإن عملنا في تطوير dApp يمكن أن يساعد في الحفاظ على توافق رحلتي الموبايل والويب. للحصول على بناء منتج أوسع، راجع تطوير ويب3.
المهمة الأولى الواضحة تعطي أيضًا التصميم والهندسة نفس نقطة البداية. يمكن لفريقك مراجعة التدفق قبل استثمار الوقت في شاشات أو تكاملات لا تخدمه.
أي تجربة موبايل تناسب منتجك؟
يتبع تنسيق التطبيق الصحيح رحلات المستخدم للمنتج، واحتياجات المنصة، وخطط الصيانة. ننظر إلى تلك الاحتياجات قبل اختيار التطوير الأصلي لنظامي iOS وAndroid أو نهج عبر المنصات.
متى تكون التطبيقات الأصلية منطقية
يمكن أن يناسب التطوير الأصلي عندما تحتاج تجارب iOS وAndroid إلى سلوك مختلف أو تصميم خاص بالمنصة. نرسم تلك الاختلافات مع فريقك، ثم نلاحظ ما يجب أن يدعمه كل إصدار. هذا يعطيك رؤية أوضح للعمل قبل بدء التطوير.
متى يناسب التطوير المشترك
يمكن أن يناسب البناء عبر المنصات المنتجات التي تكون شاشاتها وإجراءاتها الرئيسية مشتركة إلى حد كبير. نتحقق من التكاملات واحتياجات الواجهة وخطة الصيانة المستقبلية معًا. يجب أن يعكس القرار ما يحتاجه فريقك للتشغيل، وليس تفضيل إطار عمل.
على سبيل المثال، تخيل منتج ولاء حيث يرى الأعضاء المكافآت في التطبيق، ثم يصلون محفظة لإجراء محدد. سنحدد أي المعلومة معروضة فقط وأي الإجراء يحتاج إلى اتصال. إذا كا المنتج بحاجة إلى تجربة محفظة خاصة به، قارن المتطلبات مع تطوير محفظة العملات المشفرة. عندما يحتاج سلوك العقد الحالي أو الجديد إلى اهتمام، قد يكون تطوير العقود الذكية مسار عمل ذا صلة.
أربعة قررات نستقرها قبل البرمجة
قبل بدء البرمجة، نحول فكرة المنتج إلى خططة قصيرة. يمكن للتصميم والهندسة كلاهما استخدام تلك الخططة. ملاحظة بدء مكونة من 3 أجزاء تلتقط هدف المستخدم، وإجراءات الإطلاق، والتبعيات التقنية.
- تسمية رحلة المستخدم الرئيسية. نحدد المهمة الأولى التي يج أن يدعمها التطبيق. ثم نرسم الشاشات التي يحتاج الشخص إلى إكمالها.
- رسم الاتصالات. ندرج عمل المحفظة والبلوكشين والخلفية وAPI المطلوب. نلاحظ أيضًا أي خدمات موجودة أو مواد تقنية يمكن للفريق توفيرها.
- اختيار ميزات الإصدار الأول. نحدد ما يجب أن يكون موجودًا عند الإطلاق وما يمكن أن يأتي لاحقًا. هذا يساعد في الحفاظ على تركيز البناء الأول دون إغفال المنتج الأوسع.
- الاتفاق على الفحوصات. نحدد كيف سيراجع الفريق كل تدفق أساسي. تغطي الفحوصات التأكيدات، وحالات الانتظار، وما يراه الشخص عندما لا يكتمل الإجراء.
خريطة تدفق من صفحة واحدة يمكن أن تجعل هذه القرارات أسهل للمراجعة. تساعد قادة المنتج والتقنية في اكتشاف التفاصيل المفقودة مبكرًا، مع إعطاء عمل الواجهة مسارًا واضحًا للأمام. إذا كان التطبيق يعتمد على توكن جديد، يمكننا ربط التخطيط مع إنشاء ونشر التوكن حتى تكون افتراضات التطبيق واضحة.
من الشاشة الأولى إلى بناء جاهز للإطلاق
يجلب البناء رحلات المستخدم المتفق عليها إلى تطبيق عامل. ثم يتحقق من تلك الرحلات قبل التحضير للتقديم. إليك كيف تتناسب الأجزاء الرئيسية معًا:
| جزء العمل | ما تحصل عليه |
|---|---|
| المنتج والواجهة | رحلات المستخدم، تصميم واجهة المستخدم وتجربة المستخدم، وحالات الشاشة الرئيسية |
| تطوير التطبيق | عمل أصلي أو عبر المنصات لأهداف iOS وAndroid المتفق عليها |
| الاتصالات | تكاملات المحفظة والبلوكشين والخلفية وAPI المحددة |
| الاختبار | فحوصات التدفقات الأساسية المتفق عليها، وسلوك الواجهة، والتكاملات |
| الإطلاق والدعم | تحضير التقديم وأي دعم متفق عليه بعد الإطلاق |
نحافظ على اتصال التصميم والهندسة بينما يتشكل التطبيق. يشمل ذلك التلميحات، والتأكيدات، ولحظات الانتظار، ورسائل الخطأ. يواجه الأشخاص هذه التفاصيل أثناء الإجراءات المهمة. يتحقق الفريق من مرشح الإطلاق مقابل السلوك المتفق عليه، بدلاً من الاعتماد على مراجعة بصرية في اللحظة الأخيرة وحدها.
نوضح أيضًا من يقدم الوصول إلى حساب المطور، ونص المنتج، ولقطات الشاشة، ومدخلات الإطلاق الأخرى. قد تناسب ميزة قائمة على Telegram بشكل أفضل كتطبيق مصغر بدلاً من تطبيق موبايل مستقل. يمكننا مقارنة تلك الحاجة مع تطوير بوتات وتطبيقات Telegram المصغرة قبل أن يلتزم فريقك بالتنسيق الخاطئ.
حافظ على خطة الإطلاق قائمة على قواعد المتجر
خطة الإطلاق الجيدة تجعل المسؤوليات والأسئلة المفتوحة مرئية قبل البناء النهائي. نراجع سياسات تطبيقات العملات المشفرة قبل التطوير. ثم نربط تلك المراجعة المبكرة بالميزات والتصميم وعمل التقديم الذي يحتاجه فريقك. هذا يعطي الجميع فرصة لطرح الأسئلة بينما لا يزال هناك مجال لمناقشة تدفق المنتج.
نتفق أيضًا على من يملك حسابات متجر التطبيقات وقرارات التقديم. نوضح من يقدم تفاصيل المنتج، ومن سيتعامل مع المتابعة. في قائمة التحقق البدءية لدينا، يسجل Brand Community أهداف المنصة، وأولويات الإطلاق، والمواد التقنية الموجودة، والأشخاص الذين يمكنهم الموافقة على العمل. أثناء المشروع، نتحقق من الواجهة والرحلات الأساسية قبل أن يمضي التنفيذ قدمًا. ثم نراجع البناء مقابل نفس السلوك المتفق عليه.
تحدد Apple وGoogle سياسات تطبيقات العملات المشفرة وتتخذ قررات المراجعة؛ ولا يمكننا التحكم في أي من النتيجتين. نحضر عمل التقديم المتفق عليه، لكن لا يمكننا الوعد بالموافقة. للبدء، أرسل لنا ملخصًا قصيرًا للمنتج، ومنصاتك المقصودة، وأي تصميمات موجودة أو ملاحظات فنية. أخبرنا بأي إجراء للمستخدم هو الأهم عند الإطلاق. سنراجع تلك المواد، ونحدد القررات الأولى، ونحدد خطط بناء عملي معك.
كيف نعمل
- شارك ملاحظات المنتجأرسل الهدف، والمستخدمين المقصودين، وخطط المنصة، وأي تصميمات موجودة أو مواد تقنية. أشر إلى الإجراءات المهمة عند الإطلاق.
- ارسم التطبيق واتصالاتهنحدد الرحلات الرئيسية، وروابط المحفظة والبلوكشين المطلوبة، وعمل الخلفية أو API، والأسئلة المفتوحة.
- راجع الواجهةنستعرض الشاشات الرئيسية وحالات التفاعل معًا قبل بدء التطوير.
- ابنِ واختبر التدفقات الأساسيةنطور التطبيق المتفق عليه ونختبر رحلاته الرئيسية وتكاملاته مقابل المتطلبات.
- حضر تسليم الإطلاقننظم عمل التقديم في الخطة، ونوضح من يقدم كل عنصر، ونتفق على أي دعم بعد الإطلاق.
الأسئلة الشائعة
ما الذي يجب أن يكون جاهزًا لدينا قبل تخطيط التطبيق؟
ابدأ بملخص قصير للمنتج، والمستخدمين المقصودين، والمنصات المستهدفة، والإجراء الرئيسي الذي يجب أن يدعمه التطبيق. التصميمات الموجودة، وتفاصيل API، وملاحظات العقد، ومتطلبات المحفظة مفيدة، لكن لا تحتاج جميعها إلى أن تكون جاهزة. يمكننا إدراج المعلومات المفقودة أثناء المراجعة الأولى وتحديد من يمكنه الإجابة على كل سؤال مفتوح.
كيف تختار بين التطوير الأصلي والتطوير عبر المنصات؟
نقارن رحلات المستخدم للتطبيق، والاحتياجات الخاصة بالمنصة، والتكاملات، وخطط الصيانة. يمكن أن يناسب التطوير الأصلي عندما تحتاج تجارب iOS وAndroid إلى سلوك مختلف. يمكن أن يناسب النهج عبر المنصات تطبيقًا ذا شاشات وإجراءات مشتركة إلى حد كببر. نسجل السبب قبل التطوير حتى يفهم فريقك الاختيار.
هل يمكن للتطبيق الاتصال بمحفظة ومنتجنا الحالي؟
نعم، يمكن أن تكون اتصالات المحفظة والبلوكشين جزءًا من الخطة. نرسم أولاً أي إجراءات للمستخدم تحتاج إلى اتصال، وما المعلومات التي يجب أن يعرضها التطبيق، وأي شبكات أو مكونات تقنية موجودة متضمنة. على سبيل المثال، يمكن معاملة عرض المكافأة واستخدام ميزة مربوطة بالمحفظة كخطوتين منفصلتين في التدفق.
كم من الوقت يجب أن نخطط لبناء تطبيق ويب3 للموبايل؟
يمكننا تحديد التوقيت بعد مراجعة الميزات واحتياجات التصميم والمنصات المستهدفة والتكاملات. التطبيق المركز ذو المتطلبات الواضحة له تسلسل مختلف عن الذي يحتاج أيضًا إلى عمل خلفية جديد أو عدة رحلات معقدة. سنظهر المراحل الرئيسية والتبعيات بمجرد أن نفهم ما يحتاجه إصدارك الأول.
هل يمكنك الوعد بأن Apple أو Google ستقبل التطبيق؟
لا. تحدد Apple وGoogle سياسات تطبيقات العملات المشفرة الخاصة بهما وتتخذان قرر المراجعة. نراجع السياسات ذات الصلة قبل التطوير ونحضر عمل التقديم المضمن في الخطة، لكن المنصات تقرر ما إذا كا التطبيق مقبولاً. يمكننا أيصًا توضيح من سيرد إذا أثارت المراجعة أسئلة.
هل سيناسبنا تطبيق Telegram المصغر أكثر من تطبيق موبايل؟
يعتمد ذلك على أين يحتاج الأعضاء إلى استخدام المنتج وما يجب أن تفعله الميزة. قد يناسب التطبيق المستقل منتجًا يحتاج إلى تجربة iOS وAndroid مخصصة. قد يناسب تطبيق Telegram المصغر ميزة مخصصة للعيش داخل Telegram. يمكننا رسم مهمة المستخدم الرئيسية ومقارنة التنسيقين قبل الاستقرار على بناء.
أخبرنا عن مشروعك
أجب عن أربعة أسئلة سريعة وسيرسل لك مدير الحساب خلال ساعة خطة وجدولا زمنيا ونطاقا للميزانية. كل شيء يبقى سريا.
جار تحميل النموذج…