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