أن نحمل الرحلة المنظَّمة نفسها (بذات المستندات، وذات الإقرارات، وذات قواعد الشركاء) عبر جهاز يستخدم في سيارة، أو وقت الاستراحة القصيرة، أوفي الطريق، ثم يُوضع جانبًا من حين لآخر ثم العودة لاحقاً.
السياق
رحلة الويب تفترض جلسة واحدة متصلة: جهاز كمبيوتر، وخمس عشرة دقيقة، وينتهي الأمر. أما الموبايل فلا يفترض شيئًا من ذلك. العميل يبدأ وهو خارج من العمل، ثم يُقاطَع، ثم يعود بعد يومين.
والمقاطعة على الموبايل ليست حالة استثنائية نتعامل معها عند حدوثها، بل هي السلوك المتوقع الذي يجب أن يُبنى التصميم حوله. وهذه قراءتي أنا لبيئة وطبيعة الاستخدام، وكل قرار اتخذته في هذا المشروع يحترم طبيعة الاستخدام.
ومع استحالة التغيير او التعديل في اقرارات البنك التنظيمية، متطلبات البنك المركزي، وجمع والإطلاع على المستندات، والنهاية بالتوقيع اليدوي: كلها مطابقة للويب. فالسؤال التصميمي لم يكن يومًا ماذا تطلب الرحلة من العميل، بل كيف يستخدمها إنسان بيد واحدة على شاشة صغيرة.
القرار
المسار الخطي صار قائمة مهام
على الويب، الرحلة مسار خطي من خمس مراحل متتابعة. وعلى الموبايل اقترحت قائمة المهام (dashboard): خمس مسارات (أنواع الحسابات، وبيانات الشركة، وبيانات الملكية، والبيانات المالية، والإقرارات التنظيمية)، لكل مسار شكل وطريقة عرض خاصة تختلف حسب البيانات المطلوبة. والتسلسل نفسه لم يتغير إطلاقًا. لا تبدأ البيانات المالية قبل إنهاء بيانات الملكية، ولا بيانات الملكية قبل بيانات الشركة نفسها. يتم تفعيل المسار التالي حين تكتمل البيانات المطلوبة للمتابعه، وتبقى المسارات المكتملة مفتوحة للرجوع إليها في أي وقت. الذي تغير هو ما يراه المستخدم، لا ما يسمح له النظام بفعله. ولماذا يهم ذلك؟ المسار الواحد الخطي يظهر للعميل المراحل المتبقية أمامه. بل قائمة المهام تعرض عليه ما أنجزه بالفعل. نفس المعلومة تمامًا، وشعور معاكس كلياً. وفي بيئة طبيعتها الابرز هي مغادرة المستخدم والعودة باستمرار، فإن أول ما يراه عند عودته هو ما يقرر إن كان سيكمل أم لا: المسار الخطي يواجهه بسؤال «أين كنت؟»، وقائمة المهام تجيب عنه قبل أن يُطرح. وثلاثة أمور أخرى تبعت هذا القرار: ١ · لا توجد صفحة مراجعة نهائية. الويب احتاج صفحة مراجعة طويلة قبل التقديم يستعرض فيها العميل كل ما أدخله. وهنا القائمة نفسها تؤدي هذا الدور: تعرض ما اكتمل وما لم يكتمل، وكل مسار منتهي يفتح للمراجعة والتعديل حتى لحظة التقديم. ولو التعديل يترتب عليه تعديل ما يليه من مسارات، عادت تلك المسارات إلى حالة «لم يكتمل» تلقائياً. أي أن فئة كاملة من الشاشات حُذفت بفضل البنية نفسها. ٢ · الشاشة لم تكن لتتسع لمسار خطي أصلًا. لا يوجد عرض أفقي كافٍ لمراحل تخبر المستخدم أين هو من الرحلة. والقائمة تحل ذلك بأن تلخص كل مرحلة في عنوان شامل. ٣ · المرحلة الأولى تم انجازها سلفًا. أنواع الحسابات كانت موضع خلاف حقيقي: اقترحتها عنوان في القائمة، ورفض فريق إدارة الأعمال أن تظهر كخطوة مستقلة. والحل الوسط خرج أفضل من الموقفين معًا: يُوجَّه العميل إليها مباشرة بعد الانضمام، قبل أن يرى القائمة أصلًا. فيكون أول ظهور للقائمة أمامه وفيها خطوة من خمس مكتملة بالفعل. أي أنه يبدأ الجزء الثقيل من الرحلة وهو قد انجز، وقد استثمر وقتًا لا يريد أن يخسره. ولو أغلق التطبيق قبل الاختيار، انتظرته المرحلة في حالة فارغة.
القرار
القائمة المنسدلة صارت ترتيب نمطي
على الويب، بنية الشركة قائمة منسدلة طويلة تعرض كل الأشكال القانونية دفعة واحدة. والمشكلة أن أغلب المتقدمين لا يعرفون تصنيف شركتهم القانوني أصلًا، فالقائمة الطويلة تدفعهم إلى التخمين. فقسّمت القرار إلى خطوتين: فردية أم شراكة؟ (وهو سؤال يستطيع أي إنسان الإجابة عنه) ثم تظهر الأشكال التابعة لذلك النوع وحدها. أي أن العميل يصل إلى تصنيف ما كان ليستطيع تسميته، عبر أسئلة يستطيع الإجابة عنها. ثم يسري المبدأ نفسه على الرحلة كلها. التصميم موثق في صورة ترتيب نمطي: بنية الشركة × الجنسية × الإقامة × دور المساهم × سلطة التوقيع. ولكل تركيبة من هذه مسارها القصير الخاص: مساهم مصري، أو غير مصري مقيم وغير مساهم، أو مفوَّض بالتوقيع لا يملك نسبة. وتختلف المستندات باختلاف المسار (بطاقة، أو جواز سفر، أو تصريح إقامة)، وتختلف بيانات التواصل، بل وتختلف المنتجات المصرفية نفسها: المفوَّض المنفرد بالتوقيع يحصل على بطاقة خصم ودفتر شيكات، أما التوقيع المشترك فيحصل على دفتر الشيكات فقط. والفرق العملي بين المنصتين: على الويب كانت هذه الأنماط حقول تظهر وتختفي داخل صفحة واحدة أمام عين المستخدم. وعلى الموبايل، أنماط متتالية من شاشات كل منها بسؤال واحد، وكل إجابة تختار الشاشة التالية. أي أن الجهد الذهني يقع على القرار نفسه، لا على إعادة قراءة صفحة تبدل شكلها في كل مرة. ملاحظة: المستندات المطلوبة لكل شركة، عقد الشركة وتعديلاته لشركات الأشخاص، والنظام الأساسي (AOA) لذات المسؤولية المحدودة، والتراخيص المهنية إن استلزم الأمر، هي متطلبات تنظيمية للبنك، مطابقة للويب تمامًا. والعمل التصميمي كان يجب أن يبدو كل مسار طبيعيًا للعميل لا مشروطًا ومربكًا.
القرار
التصوير اسهل في تصحيح المستندات
على الويب، فشل رفع السجل التجاري بعد الإطلاق التجاري: احتفظ الملاك بكل صفحة كملف منفصل، ورفعوا الصفحة الأولى فقط، فلم يجد القارئ الآلي OCR ما يقرأه. وحلت منصة المتابعة الأمر لاحقًا عبر الاستفسارات، لكن بعد أن وقع الجهد على العميل مرتين بالفعل. وعلى الموبايل، أداة التصوير نفسها تغلق هذا الباب. الرفع يقدم ثلاثة مسارات أصلية في نظام الهاتف: الصور، أو الملفات، أو الكاميرا. والكاميرا تعمل بأسلوب ماسح المستندات: صفحة، ثم صفحة، ثم صفحة، وتدمجها جميعا في ملف واحد، وتقدم مرة واحدة. أما المستندات ذات الوجهين كالبطاقة الضريبية فتقدم بنفس الطريقة أو من الصور مباشرة. وقبل الالتقاط يوجد الإرشادات: الصيغ المقبولة، وحدود حجم المستند، ومطابقة اسم المالك لما في البطاقة، والختم والسريان. أي أن معايير القبول انتقلت من بعد وقوع الخطأ إلى ما قبل المحاولة. والخلاصة: الويب تعلّم هذا الفشل في بيئة الإنتاج بثمن دفعه العملاء، والتصميم على الموبايل استوعب الدرس قبل أن يلمسه عميل واحد. وهذا أكثر من أي شاشة بعينها هو ما يبرر وجود منصة ثانية أصلًا.
النتيجة
التطبيق مُصمَّم ومُتحقَّق منه داخليًا، وينتظر فريق البناء المخصص. وما سيُقاس يومًا سيُقاس مقابل خط أساس رحلة الويب، في جدول نتائجه الخاص.
والذي يمكن ادعاؤه الآن هو التصميم نفسه: الرحلة المنظَّمة ذاتها، أعيد هيكلتها لتتناسب مع حالات الخروج والعودة المتكرره. قائمة تجيب عن «أين كنت؟» قبل أن يُسأل السؤال، ترتيب نمطي لا تطالب العميل بمعرفة مصطلحات البنوك، ونموذج تصوير المستندات يمنع الفشل الوحيد الذي اضطر الويب لتعلمه بعد الإطلاق.
Next chapter: Mobile Customer Portal, the waiting relationship, in the pocket.