أرى أن تطبيقات الهاتف المحمول يجب أن تكون أكثر تخصيصًا. لا أحتاج إلى بعض الوظائف ، بينما أحتاج إلى وظائف أخرى. لكن لسبب ما ، نحن نساوي الجميع تحت مشط واحد ، حتى نتمكن من تلبية احتياجات المزيد من الناس قليلاً. أبعد قليلا من حيث التخصيص ذهب يغذي الأخبار والاجتماعية. الشبكات التي توفر محتوى فريدًا للجميع.
ولكن ماذا لو ذهبنا إلى أبعد من ذلك ونوفر للناس واجهة مستخدم مخصصة بالإضافة إلى المحتوى؟!
نظرية
مفهوم- يفهم التطبيق نفسه ما تستخدمه غالبًا ويجلب وظائف مستخدمة كثيرًا إلى الشاشة الأولى.
- يقوم بترتيب العناصر وفقًا لدرجة الأهمية على الصفحة بحيث لا تحتاج للوصول إلى إبهامك بها.
- بناءً على عدد مرات استخدام هذا العنصر ، سوف يختلف محتواه أيضًا اختلافًا كبيرًا
- هناك أيضًا مشغلات: وصل إشعار بالدفع ، تاريخ محدد أو إجراء مستخدم. هذا المشغل له ثقله الخاص ، الذي تم تعيينه لعنصر فردي لفترة قصيرة.
منطقخطوة المعايرةشخص يستخدم التطبيق.
ويقوم البرنامج نفسه بتحليل عدد النقرات على كل عنصر ويعطي العناصر وزنًا محددًا.
مرحلة التنفيذ السلسبعد المعايرة الأولية ، يمكننا أن ننفذ بعناية الطلب الأكثر شعبية للصفحة الرئيسية ، في كتلة منفصلة.
مرحلة التحقق من البندنقوم بتحليل وتيرة الزيارات وتحديد ما إذا كان العنصر يستحق البقاء على الصفحة الرئيسية.
وإذا كان الأمر يستحق الاستخدام وكثيراً ما يتم استخدامه ، فإننا نفكر في خيار توسيع هذه الخلية ، بحيث يقوم المستخدم بتنفيذ الإجراء المستهدف بشكل أسرع.
ممارسة
مثال تنفيذ التطبيقمثال جيد على ذلك هو التطبيقات المصرفية.
لماذا؟
- فهي متعددة الوظائف.
- معظم الوظائف التي أستخدمها كمستخدم لا تحتاج على الإطلاق ، ولكن قد تكون المهام الأخرى أكثر أهمية.
- قد تكون هناك حاجة لبعض الوظائف ، فقط في لحظة معينة
- الجميع يستخدم هذه التطبيقات ، لذلك من الأسهل فهم المفهوم.
سأحاول هنا أن أوضح في مرحلة الرسم كيف ينبغي أن يكون. إذا كانت المشاركة ممتعة ، فسوف أصنع بالفعل تطبيقًا تجريبيًا على iOS.
سيناريوهاتكل شخص لديه نصوصه الخاصة التي يقوم بها. فهي ليست منطقية دائمًا ، ومهمة التطبيق هي تسهيل الطريق لتحقيق هذا الهدف.
السيناريو 1 : غالبًا ما أقوم بتحويل الأموال إلى نفس الشخص (الأخ الأصغر ، الطفل ، الزوجة).
يمكننا إضافة كتلة مع القدرة على نقل بسرعة له.
لكن الكتلة نفسها يمكن أن تتطور مثل بوكيمون. إذا رأينا أنها غالبا ما تستخدم.
كتلة مستوى 2:
هنا يمكننا بالفعل ترجمة مباشرة من الخلية نفسها من خلال النقر على زر الترجمة
يدرك التطبيق أن هذه الوظيفة لا يتم استخدامها في كثير من الأحيان فقط ، ولكن أيضًا تكون الكمية هي نفسها ، لذلك نذهب إلى أبعد من ذلك ونغير الخلية بحيث يتم تعيين المبلغ الافتراضي لهذه العملية.
3 كتلة المستوى
السيناريو 2 مرة واحدة في الشهر أدفع لشقة ، يتم تشغيل مشغل التاريخ بالفعل هنا.
يدرك التطبيق أنه في هذا التاريخ تقريبًا ، أقدم المال لشقة.
ومن المنطقي أن نعرض هذه المجموعة تمامًا في هذا اليوم على الشاشة الرئيسية وبعد إتمام عملية الدفع ، أزلها.
السيناريو 3 أغلق القرض بعد تلقي sn.
الزناد. تلقيت sn على البطاقة ويفهم التطبيق أنه بعد هذا الإجراء عادةً لمدة يوم أو يومين ، أغلق القرض المعلق بي.
يظهر الدفع الائتماني الآن في الكتلة.
السيناريو 4 أستخدم الدردشة مع الدعم
في كثير من الأحيان ، إذا كنا نتحدث في دردشة مع الدعم ، فإن هذه العملية ليست سريعة ، يمكننا تقليل التطبيق عدة مرات ، والقيام بأعمالنا والعودة لاحقًا ، حتى نتمكن من إحضاره إلى الشاشة الأولى أثناء الاتصال بالدردشة. وبما أننا نعرف متى بدأ المحادثة ومتى ، من حيث المبدأ ، حل المشكلة.
السيناريو 5 سحب الأموال من حساب جاري إلى بطاقة
المشغل لاستلام الأموال / s وأفترض دائمًا توزيعها بين بطاقتي:
أردت أن أنقل فكرة أنه يمكن تحسين تجربة المستخدم من خلال محاولة مساعدته على إكمال ما يريد في أسرع وقت ممكن ، بالطبع سيكون الأمر أكثر صعوبة بالنسبة لنا كمطورين ، ولكن سيتم تقديره من قبل عملائنا. قل لي ، ما رأيك في هذا النهج؟