تجربة المستخدم في التقنية المالية

دليل عملي لتجربة المستخدم في التقنية المالية لفرق المنطقة. تسجيل واعرف عميلك يكمله المستخدم الجديد، ورسائل خطأ لا تولّد تذاكر دعم، وعرض صادق للمبالغ، وعربية أصلية لا مترجمة، وإتاحة وصول، وأنماط خادعة يجب تجنبها.

· · تحديث · 26 دقائق قراءة

رسم توضيحي لشاشة تطبيق مصرفي تعرض مبلغًا بالعربية وحقل رمز تحقق وزر تأكيد
في هذا المقال

لماذا تهم تجربة المستخدم في التقنية المالية

لا أحد يفتح تطبيقًا مصرفيًا للمتعة. يفتحه الناس لأن الإيجار مستحق، أو لأن الراتب لم يصل، أو لأن البطاقة رُفضت عند صندوق السوبر ماركت، أو لأن قريبًا في الخارج يحتاج إلى المال قبل نهاية الأسبوع. كل شاشة في منتج مالي يقرؤها شخص ضاق انتباهه بفعل التوتر، وعلى الواجهة أن تعمل لهذا الشخص تحديدًا، لا للمصمم الهادئ الذي بناها على شاشة كبيرة.

القلق يغيّر القواعد

الشاشة المربكة في تطبيق محفظة تكلّف المستخدم مالًا، أو تجعله يظن أنها فعلت، وهو الأمر نفسه من زاوية الثقة. رصيد يومض إلى الصفر أثناء التحميل، وتحويل يظهر بحالة "فشل" ثم يظهر في كشف الحساب على أي حال، ورسوم "أُفصح عنها" في لوحة تمرير لم يقرأها أحد: كل واحدة من هذه تتحول إلى مكالمة دعم، أو شكوى لدى الجهة الرقابية، أو تقييم بنجمة واحدة يحتوي كلمة "نصب". مهمة تجربة المستخدم في التقنية المالية هي أن تجعل عملية معقدة قانونيًا ومشحونة عاطفيًا تبدو بديهية وهادئة، وقابلة للتراجع كلما أمكن ذلك.

التنظيم قيد لا ذريعة

كل فريق تقنية مالية يسمع في مرحلة ما عبارة "الامتثال لن يسمح لنا بذلك". في أغلب الأحيان ليست صحيحة. الجهة الرقابية تريد أن يكون العميل معرَّفًا ومُطلَعًا ومحميًا؛ وهي لا تفرض نموذجًا من سبع شاشات بزر رمادي وملف PDF لا يستطيع أحد فتحه على الهاتف. تعامل مع KYC والموافقة والإفصاح بوصفها مدخلات للتصميم، كما يتعامل المهندس الإنشائي مع حدود الأحمال. القيد حقيقي. أما القبح فاختياري.

لم تطلب جهة رقابية يومًا نموذجًا سيئًا. اختاره أحدهم لأنه كان أسرع طريقة لإغلاق تذكرة.

أين يكمن المال

ثلاثة أشياء تدفع ثمن عمل التصميم في التقنية المالية، وثلاثتها تظهر في قائمة الدخل لا في استبيان رضا. إكمال التسجيل: كل خطوة يتخلى عندها مستخدم جديد هي إنفاق استحواذ مشطوب. تكلفة الدعم: حالة الخطأ المربكة تتحول إلى مكالمة، وفي مركز اتصال خاضع للرقابة تبدأ كل مكالمة بالتحقق من الهوية. النزاعات: شاشة التأكيد التي تُقرأ فعلًا تقلل شكاوى "لم أصرّح بهذا"، وعمليات رد المبالغ، والمراسلات مع الجهة الرقابية.

وهناك أيضًا حجة السوق: كثير ممن ينضمون اليوم إلى التمويل الرقمي في مصر والسعودية والإمارات لم يملكوا حسابًا مصرفيًا من قبل، ويقرؤون العربية بأريحية تفوق الإنجليزية بكثير، ويستخدمون هاتف Android متوسط الفئة على شبكة مزدحمة. التصميم لهؤلاء هو السوق القابلة للوصول، والمنتجات التي تصيب في ذلك تصبح الخيار الافتراضي، كما حدث مع إنستاباي في مصر.

أين تُستخدم

تجربة المستخدم في التقنية المالية ليست سطحًا واحدًا، بل عائلة من الأسطح بدرجات حرارة عاطفية مختلفة، والمنتج الذي يعاملها جميعًا بالطريقة نفسها سيخطئ في معظمها.

التسجيل واعرف عميلك (KYC)

السطح الأعلى مخاطرة: تقابل المستخدم للمرة الأولى وتطلب منه فورًا بطاقة هويته الوطنية وصورة شخصية. المسار الجيد يقول مقدمًا ما الذي سيُطلب، ويسمح للناس بالتوقف والاستئناف، ويشرح لماذا تُجمع كل معلومة، ولا يتركهم أبدًا يحدقون في مؤشر تحميل بعد الصورة الشخصية.

المدفوعات والدفع عند الشراء

جعلت منصات تجميع الفواتير مثل فوري نموذج "ادفع فاتورة من رقم مرجعي" مألوفًا في أنحاء مصر. أما الدفع لدى التاجر فهو حيث تلتقي إدخالات البطاقة والحقول المستضافة وApple Pay والشبكات المحلية مثل ميزة أو مدى، والمهمة هي أن تجعل لحظة الدفع تبدو مؤكدة: مبلغ واحد واضح العنوان، وزر واحد، وإيصال يمكن العثور عليه مرة أخرى.

التحويلات والحوالات

التحويلات هي حيث يبلغ الخوف ذروته، لأن المال يغادر وعلى المستخدم أن يثق في أنه وصل. تأكيد اسم المستفيد قبل الإرسال، وشاشة مراجعة تكرر المبلغ، ومتتبّع حالة بعد الإرسال هي الأنماط الأساسية. عمّمت Wise عرض سعر الصرف والرسوم كلًا على حدة بدلًا من إخفاء الفارق؛ وهذا الآن هو المعيار الذي يُقارن به أي منتج حوالات إلى مصر.

البطاقات

تحكم وشرح: التجميد وإلغاء التجميد، وعرض رقم PIN بأمان، وضبط الحدود، وتفعيل الاستخدام عبر الإنترنت أو الدولي، والأهم من ذلك كله شرح الرفض بكلمات يستطيع المستخدم التصرف بناءً عليها. "رُفضت العملية" ليس شرحًا؛ أما "هذا التاجر خارج الدول المسموح بها. فعّل المدفوعات الدولية لإعادة المحاولة" فهو شرح.

الإقراض والشراء الآن والدفع لاحقًا

تحمل شاشات الإقراض أثقل عبء إفصاح: التكلفة الإجمالية للائتمان، وجدول السداد، وما يحدث عند تأخر قسط، والموافقة على الاستعلام لدى مكتب الائتمان (I-Score في مصر، وسمة في السعودية، والاتحاد للمعلومات الائتمانية في الإمارات). التحدي هو عرض كل ذلك دون دفن الرقم الوحيد الذي يريده المستخدم: كم أدفع شهريًا، ولكم من الوقت.

الاستثمار والادخار

الذهب والصناديق والصكوك والأسهم وأهداف الادخار. هنا على التخصص أن يقاوم التلعيب: الأداء يُعرض مع فترته وأساس مقارنته، وتحذيرات المخاطر مقروءة لا مجرد موجودة، وملصقات التوافق مع الشريعة دقيقة وموثقة المصدر، لأنها لشريحة واسعة من الجمهور مسألة عقيدة.

الدعم والنزاعات

السطح المنسي. متتبّع "أين مالي" ومسار نزاع يملأ تفاصيل المعاملة مسبقًا يفعلان للاحتفاظ بالمستخدمين أكثر مما تفعله إعادة تصميم أخرى لمسار التسجيل.

نقاط القوة

ماذا يكسب المنتج حين يأخذ هذا التخصص على محمل الجد؟ أربعة أشياء، كلها قابلة للقياس.

ثقة يمكن رؤيتها

الثقة في منتج مالي ليست أجواءً عامة؛ إنها مجموعة إشارات ملموسة يتفقدها المستخدم قبل أن يضع ماله. ويستطيع المنتج أن يراجع نفسه مقابلها.

إشارة الثقة ما يراه المستخدم ما تخبره به
ذكر الترخيص والجهة الرقابية "مرخص من البنك المركزي المصري" مع رقم الترخيص، في التذييل وشاشة "حول التطبيق" هناك من يُحاسَب
الرسوم قبل الزر الأخير الرسوم بالضبط وما سيصل إلى المستلم بالضبط، على شاشة المراجعة لا مفاجآت في كشف الحساب
اتساق الرصيد الرقم نفسه في الشاشة الرئيسية وكشف الحساب والإشعار والرسالة النصية إنه نظام واحد لا ثلاثة
حالة بعد كل إجراء مالي "أُرسل"، "قيد المعالجة لدى البنك المستلم"، "وصل"، مع طوابع زمنية المال في مكان ما، لم يضع
أمان بلغة بسيطة "لن نطلب رمزك عبر الهاتف أبدًا"، على شاشة OTP نفسها المنتج يعرف شكل عمليات الاحتيال

تحويل دون تلاعب

مسار التسجيل المصمم جيدًا يحوّل الزائر إلى عميل لأنه يزيل الشك، لا لأنه يخفي المخرج. مؤشر التقدم، وقائمة واضحة بالمستندات المطلوبة، وإمكانية التوقف مؤقتًا هي الأدوات الصادقة، وهي الأدوات الدائمة أيضًا: المستخدمون الذين جُلبوا بالضغط يغادرون عند أول رسوم؛ والذين جُلبوا بالوضوح يبقون.

تذاكر دعم أقل

كل شاشة غامضة تذكرة مستقبلية. تصميم الأخطاء الجيد، وتتبع الحالة، وأدوات الخدمة الذاتية (تجميد بطاقة، رفع حد، تنزيل كشف حساب) تنقل العمل من مركز الاتصال إلى داخل المنتج، وحيث تبدأ كل مكالمة بالتحقق من الهوية يكون ذلك توفيرًا مباشرًا.

الامتثال بالتصميم

حين يعيش الإفصاح والتقاط الموافقة وسجلات التدقيق داخل مكتبة المكونات، يرثها كل منتج جديد. فريق امتثال يراجع مكوّن موافقة واحدًا مرة واحدة أكثر فاعلية من فريق يراجع ثلاثين شاشة كل ربع سنة.

أرخص ملاحظة تدقيق هي تلك التي جعلها نظام التصميم مستحيلة.

المخاطر والمزالق

أنماط الفشل في تجربة المستخدم المالية متوقعة، وهذا خبر جيد: يمكن اصطياد معظمها بقائمة تحقق.

رسائل الخطأ التي تصنع التذاكر

رسالة الخطأ هي خدمة عملاء تُقدَّم في أسوأ لحظة ممكنة. معظمها يكتبه مطوّر عند نقطة إطلاق الاستثناء، ولهذا تصف النظام لا الموقف. العلاج هو مراجعة من منظور تصميم المحتوى تجعل كل رسالة تجيب عن ثلاثة أسئلة: ماذا حدث، وهل تحرك المال، وماذا أفعل الآن.

الموقف قبل بعد
رمز OTP خاطئ "رمز غير صالح" "لم يتطابق هذا الرمز. لديك محاولتان أخريان، أو اطلب رمزًا جديدًا."
بلوغ الحد اليومي "خطأ 403: تجاوز الحد" "هذا المبلغ أعلى من المتبقي من حدك اليوم. يمكنك إرسال 12,500 جنيه إضافية اليوم، أو رفع حدك من الإعدادات."
رفض صورة الهوية "المستند مرفوض" "لم نتمكن من قراءة هويتك. أظهر الزوايا الأربع، وتجنب الانعكاس، ثم حاول مرة أخرى."
انقطاع أثناء التحويل "حدث خطأ ما" "نتحقق مما إذا كان هذا التحويل قد تم. لا ترسله مرة أخرى؛ سنخطرك خلال دقائق."

صف الانقطاع هو الأهم: المستخدم الذي يرى "حدث خطأ ما" بعد الضغط على "إرسال" سيضغط "إرسال" مرة أخرى، وإذا لم تكن الواجهة الخلفية مصممة لتجاهل التكرار (idempotent) فقد صنعت للتو تحويلًا مكررًا ونزاعًا.

الأنماط الخادعة التي تكلّف أكثر مما تكسب

بعض الأنماط تحقق تحويلًا هذا الربع وتدمر المنتج خلال السنوات القليلة التالية. الأنماط التي أرفض إطلاقها:

  • الرسوم المخفية أو المتسربة: رسوم لا تظهر إلا في الشاشة الأخيرة أو في كشف الحساب. اعرضها على شاشة المراجعة، بالحجم نفسه الذي يظهر به المبلغ.
  • الموافقة المحددة مسبقًا: تسويق أو مشاركة بيانات أو إضافة مدفوعة مفعّلة افتراضيًا. الموافقة التي لم يمنحها المستخدم بإرادته ليست موافقة.
  • التخجيل عند الرفض: "لا، لا أريد حماية أموالي" كزر رفض لعرض تأمين. المستخدمون يتذكرون الازدراء.
  • الاستمرارية القسرية: تجربة مجانية تتحول بصمت إلى اشتراك مدفوع، مع إخفاء الإلغاء خلف محادثة الدعم.
  • الإلحاح الزائف وإعاقة الإغلاق: عدادات تنازلية تُعاد، أو حساب يحتاج زيارة فرع لإغلاقه بينما لم يحتج لفتحه سوى صورة شخصية.

أخطاء تنسيق المبالغ

صغيرة وفي كل مكان. حساب الفاصلة العائمة في الواجهة الأمامية ينتج مجاميع تختلف عن دفتر الحسابات بقرش. المبالغ السالبة المعروضة بالأحمر فقط، وهو ما يفشل مع المصابين بعمى الألوان ومع أي شخص يقرأ تحت شمس ساطعة. العملات ذات الثلاث خانات عشرية (الكويتية والبحرينية والعُمانية) مقطوعة إلى خانتين. ومبالغ عربية تقع فيها علامة السالب في الجانب الخطأ لأن أحدًا لم يعزل المقطع ثنائي الاتجاه.

الواجهة المترجمة

كثير من الواجهات المالية العربية هي واجهات إنجليزية استُبدلت نصوصها: تسميات مقطوعة لأن العربية أطول، وأيقونات تشير إلى الاتجاه الخطأ، وشعارات انعكست مع التخطيط، وعربية رسمية تُقرأ كإشعار قانوني، ونص بديل (placeholder) يُستخدم بوصفه التسمية الوحيدة فيختفي بمجرد أن يبدأ المستخدم الكتابة. العربية ليست مهمة توطين تُترك لنهاية المشروع؛ إنها في هذه المنطقة لغة التصميم الأساسية في الغالب.

الاحتكاك في المكان الخطأ

احتكاك قليل جدًا، فيرسل المستخدم مدخراته إلى محتال بنقرة واحدة. احتكاك كثير جدًا، فلا يستطيع المستخدم دفع فاتورة دون ثلاثة رموز OTP وصورة شخصية. يجب أن يتناسب الاحتكاك مع المخاطرة: مستفيد جديد مع مبلغ كبير في ساعة غير معتادة يستحق توقفًا وتحذيرًا؛ أما فاتورة الكهرباء نفسها التي تُدفع كل شهر فلا.

أنماط البنية والتكامل

التصميم في مؤسسة تقنية مالية نظام، لا سلسلة من النماذج المرئية. هذه هي القطع الهيكلية التي تتيح لفريق صغير الإطلاق باتساق عبر الويب وiOS وAndroid بلغتين.

نظام تصميم يعامل المال كمكوّن من الدرجة الأولى

تبدأ معظم أنظمة التصميم بالأزرار والألوان. أما نظام التصميم في التقنية المالية فينبغي أن يبدأ بمكوّن "المبلغ": تنفيذ واحد يتولى العملة والوحدات الصغرى والإشارة والأرقام الجدولية وعزل ثنائية الاتجاه ومتغيرات الحجم وحالة الإخفاء للخصوصية. كل رصيد ورسم وقسط وحد يُعرض من خلاله، فحين يطلب الامتثال إظهار رمز العملة بجانب الرمز، تغيّر مكوّنًا واحدًا. يغطي Material Design وإرشادات Apple للواجهة البشرية أعراف المنصات، لكن لا يملك أي منهما مكوّن مال؛ هذا الجزء عليك أن تبنيه.

قواعد طباعة المبالغ واتجاه RTL

/* Money: tabular digits so columns, totals and running balances line up */
.amount,
.ledger td {
  font-variant-numeric: tabular-nums lining-nums;
  font-feature-settings: "tnum" 1;
}

/* Mixed Arabic/Latin runs (an amount inside an Arabic sentence): let each
   run resolve its own direction instead of inheriting the paragraph's */
.amount,
.reference {
  unicode-bidi: plaintext;
  white-space: nowrap;
}

/* Logical properties: one rule serves both LTR and RTL layouts */
.ledger td {
  padding-inline-start: 0.75rem;
  padding-inline-end: 0.75rem;
  text-align: end;
}
.amount__currency {
  margin-inline: 0 0.25em; /* start, end: the gap sits after the symbol */
}

/* RTL-only adjustments that logical properties cannot express */
[dir="rtl"] {
  font-family: "IBM Plex Sans Arabic", "Noto Sans Arabic", system-ui, sans-serif;
  line-height: 1.7; /* Arabic glyphs need more vertical room than Latin */
}
[dir="rtl"] .iban {
  direction: ltr; /* IBANs are always read left to right */
  unicode-bidi: isolate;
  display: inline-block;
}
[dir="rtl"] .icon-chevron {
  transform: scaleX(-1); /* directional icons flip; logos and numerals do not */
}

/* Users who asked the OS for less motion get no counting-up balances */
@media (prefers-reduced-motion: reduce) {
  .balance,
  .skeleton {
    animation: none;
    transition: none;
  }
}

تم الاختبار مع المتصفحات الحديثة (2025+).

تصميم المحتوى بوصفه بنية تحتية

تعامل مع النصوص كما تتعامل مع الكود. لكل نص يواجه المستخدم مفتاح، وقيمة إنجليزية، وقيمة عربية، ومالك، وحالة. الأخطاء تُكتب من قوالب. مسرد مصطلحات يثبّت الكلمات العربية لـ"تحويل" و"مستفيد" و"قسط" و"حد" بحيث يستخدم التطبيق والرسالة النصية والإشعار وموظف الدعم الكلمة نفسها. يراجع الامتثال المسرد والقوالب، لا كل شاشة. نظام تصميم GOV.UK هو أفضل مثال عام على معايير محتوى تعيش داخل مكتبة مكونات.

عمليات البحث

يجب أن يكون البحث مستمرًا لا حدثًا ربع سنوي: لوحة مشاركين وافقوا صراحة جُندوا عبر المنتج باشتراك واضح، وموعد أسبوعي ثابت للجلسات، ودرج من هواتف Android الرخيصة، وجلسات عن بُعد للمستخدمين خارج العاصمة، وبروتوكول للمستخدمين محدودي القراءة ومن يفتحون حسابهم الأول. تظل قواعد مجموعة نيلسن نورمان الإرشادية قائمة تحقق صالحة لمراجعة الخبراء بين الجلسات.

التسليم من التصميم إلى التطوير

ناتج التسليم ليس ملف Figma. إنه رموز تصميم (tokens) مصدَّرة إلى الكود، ومكتبة مكونات يستهلكها المهندسون، ومعايير قبول تشمل الحالات التي لا يرسمها أحد: التحميل، والفراغ، والخطأ، وانقطاع الاتصال، والفشل الجزئي، وRTL، والنص الكبير، والحركة المخفضة. لا تكتمل المهمة قبل إرفاق لقطة شاشة RTL ونتيجة فحص قارئ الشاشة.

خطوط التحليلات والتجريب

قِس القمع خطوةً خطوة لا شاشةً شاشة: كل خطوة KYC تصدر أحداث البدء والنجاح والفشل مع سبب مصنّف والتخلي. تشترك الأخطاء في تصنيف واحد عبر الواجهة الأمامية والخلفية وفريق المحتوى، بحيث يعني "document_glare" شيئًا واحدًا في كل مكان. تجلس مقاييس الحماية (الشكاوى، والنزاعات، وطلبات الدعم لكل ألف معاملة) بجوار التحويل، فتفشل تلقائيًا أي تجربة ترفع التحويل عبر الإضرار بالفهم.

الأمان والامتثال

يُقدَّم الأمان والامتثال عادة بوصفهما عدوّي تجربة المستخدم. عمليًا تُترجم معظم المتطلبات إلى حفنة من أنماط التصميم، ومعظم العداء يأتي من تنفيذها دون وجود مصمم في الغرفة.

اعرف عميلك ومكافحة غسل الأموال من مقعد المستخدم

تأتي قواعد العناية الواجبة بالعملاء في المنطقة من البنوك المركزية (البنك المركزي المصري، ومؤسسة النقد العربي السعودي "ساما"، ومصرف الإمارات المركزي) وتتبع توصيات مجموعة العمل المالي FATF بشأن التعريف والتحقق القائم على المخاطر والمراقبة المستمرة. من مقعد المستخدم تتحول هذه القواعد إلى سلسلة من الطلبات، وكل طلب يحتاج إلى سبب، وتلميح عن الصيغة، ومسار تعافٍ.

المتطلب نمط UX الفشل الشائع
التعرف على العميل (هوية، صورة شخصية، كشف الحيوية) التقاط موجّه بإطار تحديد، وملاحظات فورية عن الانعكاس، وبديل مراجعة يدوية بجدول زمني ثلاث محاولات صامتة ثم "فشل التحقق"
التحقق من مصدر وطني (الرقم القومي المصري، نفاذ، الهوية الرقمية الإماراتية UAE PASS) شرح التحويل، وإظهار ما سيُشارك، وإعادة المستخدم إلى الخطوة نفسها يهبط المستخدم على الشاشة الرئيسية دون أن يعرف هل نجح الأمر
أسئلة المخاطر (المهنة، مصدر الأموال، صفة الشخص السياسي PEP) أسئلة بلغة بسيطة مع أمثلة و"لماذا نسأل" مضمّنة مصطلحات قانونية دون نص مساعدة
دليل الموافقة موافقة بطابع زمني مع نسخة النص بالضبط علامة منطقية دون نص

المصادقة القوية للعملاء وشاشة OTP

سواء كان المحفّز قواعد المصادقة القوية للعملاء في PSD2، أو اشتراط البنك المركزي عاملًا ثانيًا، أو محرك المخاطر الخاص بك، فإن شاشة OTP هي أكثر سطح أمان ظهورًا في المنتج، وهي حيث تتصادم إتاحة الوصول مع الأمان: يضيف WCAG 2.2 معيارًا للمصادقة الميسّرة يطلب ألا تجبر المستخدمين على نسخ الأشياء أو تذكرها حين توجد آلية أيسر. ينبغي أن تكون مفاتيح المرور والقياسات الحيوية للجهاز هي العامل الأساسي حيث يسمح التنظيم، مع OTP بوصفه البديل الذي يُملأ تلقائيًا من الرسالة النصية، ويعمل مع قارئ الشاشة، ويقول على الشاشة نفسها إن أحدًا لن يطلبه أبدًا.

مجموعة إدخال OTP ميسّرة

<form class="otp" novalidate>
  <fieldset aria-describedby="otp-hint otp-error">
    <legend>Enter the 6-digit code we sent to +20 1•• ••• 4321</legend>
    <p id="otp-hint">It expires in 2 minutes. Nobody from us will ever ask you for it.</p>
    <div class="otp-group" dir="ltr">
      <label for="otp-1" class="visually-hidden">Digit 1 of 6</label>
      <input id="otp-1" type="text" inputmode="numeric" autocomplete="one-time-code"
             maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
      <label for="otp-2" class="visually-hidden">Digit 2 of 6</label>
      <input id="otp-2" type="text" inputmode="numeric" autocomplete="one-time-code"
             maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
      <label for="otp-3" class="visually-hidden">Digit 3 of 6</label>
      <input id="otp-3" type="text" inputmode="numeric" autocomplete="one-time-code"
             maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
      <label for="otp-4" class="visually-hidden">Digit 4 of 6</label>
      <input id="otp-4" type="text" inputmode="numeric" autocomplete="one-time-code"
             maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
      <label for="otp-5" class="visually-hidden">Digit 5 of 6</label>
      <input id="otp-5" type="text" inputmode="numeric" autocomplete="one-time-code"
             maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
      <label for="otp-6" class="visually-hidden">Digit 6 of 6</label>
      <input id="otp-6" type="text" inputmode="numeric" autocomplete="one-time-code"
             maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
    </div>
    <!-- Linked by aria-describedby, so screen readers read it with the field -->
    <p id="otp-error" class="field-error" role="alert" hidden></p>
    <!-- Visually hidden live region: "Code accepted", "2 attempts left", etc. -->
    <p id="otp-status" class="visually-hidden" aria-live="polite" aria-atomic="true"></p>
  </fieldset>
  <button type="submit">Verify</button>
  <button type="button" class="button-link">Resend code</button>
</form>

تم الاختبار مع المتصفحات الحديثة (2025+).

موافقة وإفصاح يقرؤهما الناس فعلًا

قدّمهما على طبقات: ملخص من شاشة واحدة يضم الحقائق الثلاث أو الأربع التي تغيّر القرار (الرسوم، والمعدل، وما تشاركه، وكيفية الإلغاء)، ورابط إلى النص الكامل، ثم إجراء موافقة محدد ("أوافق على مشاركة تقريري الائتماني مع سمة لهذا الطلب") لا عام. خزّن نسخة النص بالضبط مع الطابع الزمني، واجعل سحب الموافقة بسهولة منحها.

تحذيرات الاحتيال واحتكاك التأكيد

عمليات الاحتيال الحديثة اجتماعية لا تقنية: يتصل أحدهم منتحلًا صفة البنك أو شركة الاتصالات أو جهة حكومية ويقود الضحية خطوةً خطوة إلى اعتماد تحويل. عند أول تحويل إلى مستفيد جديد، خاصة إن كان كبيرًا، اعرض تحذيرًا واضحًا ("هل طلب منك أحد إجراء هذا التحويل؟ البنوك لا تطلب منك أبدًا نقل أموالك إلى 'حساب آمن'")، وأضف تأخيرًا قصيرًا مع زر إلغاء ظاهر، واطلب عاملًا ثانيًا. أما المدفوعات الروتينية فابتعد عن طريقها.

التزامات إتاحة الوصول

WCAG 2.2 بمستوى AA هو المعيار الذي تشير إليه الجهات الرقابية وفرق المشتريات: التباين، وقابلية التشغيل بلوحة المفاتيح وقارئ الشاشة، والتركيز المرئي، والحد الأدنى لحجم الأهداف، وعدم حمل المعنى باللون وحده، والمعايير الأحدث بشأن الإدخال المتكرر والمصادقة الميسّرة التي تنطبق مباشرة على KYC. وخارج المعيار، كثير من المستخدمين هنا محدودو القراءة بأي من الخطّين؛ فالأهداف الكبيرة والجمل القصيرة والأيقونات ذات التسميات والملاحظات الصوتية في الدعم تصميم سائد، لا إضافات.

العربية والأرقام والتقويمات وصيغ الهوية

صحة RTL تتجاوز الانعكاس: ينعكس التخطيط والأيقونات الاتجاهية، ولا تنعكس الشعارات والأرقام، والنصوص مختلطة الاتجاه (جملة عربية تحتوي IBAN أو مبلغًا) تحتاج إلى عزل ثنائية الاتجاه وإلا وقعت علامات الترقيم في الجانب الخطأ. تفضيل الأرقام يختلف: مصر تستخدم عادة الأرقام الغربية في التطبيقات، والسعودية تميل إلى الأرقام العربية المشرقية في السياقات الرسمية، وكلا الشعبين يقرأ الاثنين، فوفّر إعدادًا واختبر الخيار الافتراضي. يحتاج المستخدمون السعوديون غالبًا إلى التاريخ الهجري والميلادي جنبًا إلى جنب، لذا يتعامل مكوّن التاريخ مع التقويمين. وموارد W3C للتدويل هي المرجع لتفاصيل ثنائية الاتجاه.

الأسماء العربية تتكون عادة من أربعة مقاطع دون "اسم عائلة" واحد؛ التقط الاسم كما يظهر في الهوية، مع كتابة لاتينية منفصلة إن احتاجتها البطاقات، لأن "Mohamed" و"Mohammed" و"Muhammad" شخص واحد. تملك السعودية عنوانًا وطنيًا مهيكلًا، بينما يستخدم كثير من المصريين عناوين وصفية لا تناسب حقل الرمز البريدي. صيغ الهوية معلنة وتستحق التحقق منها في جهة العميل: الرقم القومي المصري 14 رقمًا ويشفّر تاريخ الميلاد والمحافظة، والهوية السعودية والإقامة 10 أرقام، والهوية الإماراتية 15 رقمًا تبدأ بـ784.

الأداء والتوسع

الأداء في منتج مالي يتعلق باليقين بقدر ما يتعلق بالسرعة. الشاشة السريعة التي تعرض حالة خاطئة أسوأ من شاشة أبطأ صادقة.

الأداء المحسوس وحالات الهيكل العظمي

لا تعرض الرصيد أبدًا بصيغة "0.00" أثناء تحميله. استخدم شكل هيكل عظمي للمبالغ والقوائم، وأبقِ آخر رصيد معروف ظاهرًا مع مؤشر تحديث حين يعود المستخدم. التحديثات المتفائلة مقبولة لإعادة تسمية مستفيد وخطيرة مع المال: لا تعرض تحويلًا بوصفه مرسلًا قبل أن تؤكده الواجهة الخلفية. مؤشرات الدوران لانتظار أقل من ثانية؛ وأي شيء أطول يحتاج إلى جملة تقول ما الذي يحدث.

العمل دون اتصال والشبكات الضعيفة

كثير من المستخدمين في المنطقة على شبكات جوال مزدحمة. البيانات للقراءة فقط (كشوف الحساب، والمستفيدون، وتفاصيل البطاقة) يمكن تخزينها مؤقتًا وعرضها مع طابع "آخر تحديث". أما الإجراءات التي تحرك المال فلا يجوز وضعها في طابور بصمت: إذا تعذر إرسال الطلب فقل ذلك، واحتفظ بالمسودة، واجعل إعادة المحاولة متجاهلة للتكرار بحيث لا تعني نقرتان دفعتين. يحدد مجلس معايير أمان صناعة بطاقات الدفع PCI ما يجوز تخزينه مؤقتًا حين تكون البطاقات في الصورة.

التوطين على نطاق واسع

للعربية ست فئات جمع، لذا فإن أي نص يعدّ أشياء ("3 أقساط متبقية") يحتاج إلى مكتبة جمع لا إلى ضم نصوص. التوطين الزائف في CI (توسيع كل نص بمقدار الثلث ولفّه بعلامات RTL) يصطاد أخطاء القطع وثنائية الاتجاه قبل أن يراها المترجم. المال والتواريخ والأرقام تمر عبر واجهات التدويل في المنصة مع لغة محلية صريحة يتحكم فيها المنتج؛ ويغطي مرجع MDN لـ Intl.NumberFormat الخيارات المستخدمة أدناه.

منسّق مبالغ يحترم اللغة المحلية والعملة

// Amounts travel as integers in minor units (piastres, halalas, fils). Never floats.
const MINOR_DIGITS = { KWD: 3, BHD: 3, OMR: 3, JOD: 3, JPY: 0 };

function toMajorString(amountMinor, digits) {
  const negative = amountMinor < 0;
  const abs = String(negative ? -amountMinor : amountMinor).padStart(digits + 1, '0');
  const whole = abs.slice(0, abs.length - digits);
  return (negative ? '-' : '') + whole + (digits ? '.' + abs.slice(-digits) : '');
}

function formatMoney(amountMinor, currency, locale, { showSign = false } = {}) {
  const digits = MINOR_DIGITS[currency] ?? 2;
  const formatter = new Intl.NumberFormat(locale, {
    style: 'currency',
    currency,
    minimumFractionDigits: digits,
    maximumFractionDigits: digits,
    // 'exceptZero' prints "+" for credits and "-" for debits; zero stays plain
    signDisplay: showSign ? 'exceptZero' : 'auto',
  });
  // A decimal string keeps the value exact (Intl.NumberFormat v3, evergreen browsers)
  return formatter.format(toMajorString(amountMinor, digits));
}

// Egypt, English interface
formatMoney(125050, 'EGP', 'en-EG');            // EGP 1,250.50
// Egypt, Arabic interface forced to Western digits (the usual choice in Egypt)
formatMoney(125050, 'EGP', 'ar-EG-u-nu-latn');  // 1,250.50 ج.م.
// Saudi Arabia, Arabic interface with the locale's default Arabic-Indic digits
formatMoney(99900, 'SAR', 'ar-SA');             // ٩٩٩٫٠٠ ر.س.
// Three-decimal currencies keep every fils
formatMoney(1500, 'KWD', 'en-KW');              // KWD 1.500
formatMoney(2750, 'BHD', 'ar-BH-u-nu-latn');    // 2.750 د.ب.
// Debits in a statement row: the sign is explicit, never implied by colour alone
formatMoney(-45000, 'EGP', 'en-EG', { showSign: true }); // -EGP 450.00
formatMoney(45000, 'EGP', 'en-EG', { showSign: true });  // +EGP 450.00
// Exact symbol, spacing and bidi marks vary slightly between engines; test yours.

تم الاختبار مع المتصفحات الحديثة (2025+).

حوكمة نظام التصميم

نظام التصميم غير المحكوم يتحول إلى قاعدة كود قديمة ثانية. رقّمه دلاليًا، وشغّل اختبارات الانحدار البصري في الاتجاهين وكلا نظامي الألوان، وأنشئ نموذج مساهمة يتيح لفريق الإقراض إضافة مكوّن جدول السداد دون تفريع. قِس التبني: نسبة الشاشات المبنية بالكامل من مكونات النظام تتنبأ بسرعة إطلاق التغيير التنظيمي التالي.

الفريق والتوظيف في المنطقة

نضج سوق مواهب التصميم للتقنية المالية في مصر والسعودية والإمارات بسرعة، لكن بتفاوت. مهارة التصميم البصري وفيرة؛ أما تصميم المحتوى والبحث والحرفة الخاصة بالواجهات المالية فأندر.

الأدوار التي تحرك المقاييس

لفريق تصميم التقنية المالية الرشيق أربعة أدوار، وترتيب التوظيف مهم. أولًا، مصمم منتج أطلق منتجًا تعامليًا من قبل: شخص يرسم حالات الخطأ قبل المسار السعيد. ثانيًا، مصمم محتوى يكتب العربية بوصفها لغته الأم والإنجليزية جيدًا، لأن النص العربي هو حيث تُكسب معظم الثقة أو تُخسر. ثالثًا، باحث يستطيع إدارة جلسات مع من يفتحون حسابهم الأول. رابعًا، مهندس تصميم يملك مكتبة المكونات. ويأتي المتخصصون البصريون بعد ذلك.

تصميم المحتوى العربي مهارة تخصصية

ترجمة النصوص الإنجليزية القصيرة إلى العربية تنتج عربية لا يقولها أحد. تصميم المحتوى العربي الجيد يكتب من العربية أولًا: السجل اللغوي المناسب (العربية الفصحى الحديثة لكل ما هو مالي، بدفء يكفي لتجنب نبرة التعميم الحكومي)، ومصطلحات متسقة، وجمل تصمد على الشاشات الضيقة. يجلس مصمم المحتوى مع الامتثال حين تُكتب الإفصاحات، بدلًا من تلقّيها لاحقًا للترجمة.

البحث مع مستخدمي الحساب الأول ومحدودي القراءة

تفترض بروتوكولات قابلية الاستخدام القياسية مشاركًا يقرأ بطلاقة ويفكر بصوت عالٍ بارتياح؛ وكثير من أهم المستخدمين هنا لا يفعلون أيًا منهما. جنّد عبر القنوات المجتمعية، وأدر الجلسات على هاتف المستخدم نفسه في بيئته الخاصة، واعتمد على الملاحظة أكثر من الاستبيانات، وادفع الحوافز رصيد جوال أو شحن محفظة، واستعن بميسّر يتحدث لهجة المشارك. راقب المستخدم الذي يومئ ويقول "نعم، واضح" بينما إبهامه معلّق في الهواء؛ هذا التعليق هو النتيجة.

إشارات المقابلة

لمصممي المنتج، أطلب من المرشحين شرح مسار تحويل أطلقوه وسرد ما يحدث حين تنقطع الشبكة بعد الضغط على "إرسال"؛ المرشحون الأقوياء يصفون حالة "قيد الانتظار"، والضعفاء يصفون الحركة. لمصممي المحتوى، أعطيهم خطأ كتبه مطوّر وأطلب إعادة الصياغة بالعربية والإنجليزية جنبًا إلى جنب؛ والاختبار هو هل تُقرأ العربية بوصفها النص الأصلي. للباحثين، أسأل كيف سيختبرون التسجيل مع شخص لم يملك حسابًا مصرفيًا قط؛ وينبغي أن تذكر الإجابة التجنيد واللهجة قبل أن تذكر أداة.

أين يوجد الناس

القاهرة تملك أعمق بركة من مصممي المنتج ومجتمع تصميم محتوى متناميًا؛ والرياض وجدة فيهما طلب قوي وخط إمداد محلي سريع النمو؛ ودبي وأبوظبي تجذبان المواهب العليا من أنحاء المنطقة. العمل عن بُعد عبر الثلاث أمر طبيعي.

إطار اتخاذ القرار

يواجه المؤسسون وقادة التقنية سؤال التصميم عادة بإحدى ثلاث صيغ: بناء فريق داخلي، أو التعاقد مع وكالة، أو تبنّي نظام تصميم قائم وإبقاء الفريق صغيرًا جدًا. تعتمد الإجابة على المرحلة، وعدد الأسطح التعاملية، ومدى تكرار تغيّر التنظيم من تحتك.

ثلاثة مسارات

فريق داخلي. أعلى تحكم واستمرارية، وأبطأ انطلاقًا، والخيار الوحيد الذي يبني معرفة بحثية تتراكم. الخيار الافتراضي الصحيح بمجرد أن يحصل المنتج على الترخيص.

وكالة أو استوديو. سريع في إنتاج علامة تجارية وموقع تسويقي ونسخة أولى من التطبيق. ضعيف في الاستمرارية وعمق المحتوى العربي والتغييرات التنظيمية التي تحتاج إلى مصمم يعرف المنتج بالفعل. الأنسب لسباق إطلاق مع تسليم مخطط، أو لعمل تخصصي مثل العلامة التجارية.

تبنّي نظام تصميم مع فريق صغير. ابدأ من نظام تصميم مفتوح، وابنِ فوقه العناصر الأولية للتقنية المالية، واعمل بمصمم أو اثنين مع مهندس تصميم. تكلفة أقل، واتساق قوي، وتمايز أقل، ولا ينجح إلا إذا امتلك فريق الهندسة مكتبة المكونات.

مصفوفة القرار

المعيار فريق داخلي وكالة أو استوديو نظام تصميم مفتوح مع فريق صغير
الوقت حتى أول إصدار بطيء (التوظيف أولًا) سريع سريع
التكلفة على ثلاث سنوات مرتفعة ومتوقعة متوسطة ومتقطعة منخفضة إلى متوسطة
عمق المحتوى العربي قوي إذا وُظّف له ضعيف عادة يعتمد على موظف المحتوى الوحيد
الاستجابة للتغير التنظيمي قوية ضعيفة بعد التسليم متوسطة
الاتساق عبر المنصات قوي مع الحوكمة متوسط قوي
استمرارية البحث قوية معدومة خفيفة
تمايز المنتج عالٍ متوسط منخفض إلى متوسط
الأنسب لـ منتجات مرخصة بخارطة طريق متعددة السنوات سباقات الإطلاق والعلامة التجارية والعمل التخصصي مرحلة ما قبل الترخيص والأعمال B2B والتمويل المضمّن

كيف كنت سأقرر

قبل الترخيص، تبنَّ نظامًا وأبقِ الفريق صغيرًا؛ وأنفق المال على البحث مع مستخدمين حقيقيين بدلًا من ذلك. عند الترخيص، وظّف مصمم المحتوى ومصمم المنتج وابدأ المسار الداخلي، مع إبقاء الوكالة للعلامة التجارية والحملات. بمجرد أن يتجاوز المنتج سطحين تعامليين، أضف مهندس التصميم وعامل مكتبة المكونات بوصفها برمجيات إنتاج. أعد النظر في القرار كلما ظهر سوق جديد أو فئة ترخيص جديدة.

وظّف من يكتب العربية قبل من يرسم الرسوم التوضيحية.

الأسئلة الشائعة

هل ينبغي لتطبيق مالي عربي استخدام الأرقام العربية المشرقية أم الغربية؟

اجعل الخيار الافتراضي هو العرف الذي يراه مستخدموك بالفعل على نقودهم وفواتيرهم، ووفّر إعدادًا. في مصر تستخدم معظم المنتجات الرقمية وكشوف الحساب الأرقام الغربية؛ وفي السعودية وأجزاء من الخليج، الأرقام العربية المشرقية شائعة في الوثائق الرسمية. أيًا كان الخيار الافتراضي، أبقِه متسقًا عبر التطبيق والرسالة النصية والإيصالات، ودع المنسّق لا المترجم هو من يقرر.

ما مقدار الاحتكاك المناسب لتأكيد التحويل؟

بما يتناسب مع المخاطرة. الدفعة المتكررة لمستفيد معروف ضمن الحدود المعتادة تحتاج إلى شاشة مراجعة واحدة واضحة وتأكيد بالقياسات الحيوية. أما الدفعة الأولى لمستفيد جديد، أو مبلغ كبير، أو توقيت غير معتاد، فتستحق تحذيرًا من الاحتيال، وتأخيرًا قصيرًا مع زر إلغاء ظاهر، وعاملًا ثانيًا.

هل يكفي تسجيل الدخول بمفتاح مرور أو القياسات الحيوية، أم ما زلنا نحتاج إلى OTP؟

حيث تقبل الجهة الرقابية بيانات الاعتماد المرتبطة بالجهاز عاملًا قويًا، تكون مفاتيح المرور والقياسات الحيوية عاملًا أساسيًا أفضل من OTP عبر الرسائل النصية: أسرع، ومقاومة للتصيد، وأيسر وصولًا. أبقِ OTP بديلًا لتغيير الجهاز وللمستخدمين الذين لا يملكون قياسات حيوية، وصمّم تلك الشاشة كما ينبغي.

هل يمكننا إجراء اختبارات A/B على شاشات التسجيل والموافقة؟

اختبر التخطيط والترتيب والتعليمات ووضوح الصياغة، وقِس الفهم والإكمال. لا تختبر طريقة عرض الرسوم أو الخيارات الافتراضية للموافقة أو بروز الإفصاح بحثًا عن النسخة الأعلى تحويلًا. إذا كانت تجربة ما ستحرجك أمام الجهة الرقابية، فهي نمط خادع بلوحة تحكم.

ما الحد الأدنى لإتاحة الوصول في تطبيق مالي بالمنطقة؟

WCAG 2.2 بمستوى AA في كلتا اللغتين، مع اهتمام خاص بالتباين، وحجم الأهداف، وتسميات قارئ الشاشة على كل مبلغ وعنصر تحكم، وعدم الاعتماد على اللون وحده، ومعيار المصادقة الميسّرة لـ OTP وCAPTCHA. ثم تجاوز المعيار: أهداف لمس كبيرة، وجمل قصيرة، وأيقونات بتسميات، ودعم يقبل الصوت.

أهم الخلاصات

  • يصل مستخدمو التقنية المالية قلقين؛ صمّم للشخص المتوتر على هاتف متوسط الفئة، لا للمصمم الهادئ على شاشة كبيرة.
  • التنظيم مدخل للتصميم لا ذريعة لنموذج سيئ؛ معظم المتطلبات تُترجم إلى حفنة من الأنماط القابلة لإعادة الاستخدام.
  • الثقة مجموعة إشارات ملموسة (الترخيص، والرسوم قبل الزر، واتساق الأرصدة، والحالة الصادقة) يستطيع المنتج مراجعة نفسه مقابلها.
  • كل رسالة خطأ تجيب عن ثلاثة أسئلة: ماذا حدث، وهل تحرك المال، وماذا أفعل الآن.
  • ابنِ مكوّن المبلغ أولًا؛ التنسيق والإشارة والأرقام الجدولية وعزل ثنائية الاتجاه والعملات ذات الثلاث خانات تنتمي إلى مكان واحد.
  • العربية هنا لغة التصميم الأساسية لا خطوة توطين: اكتبها أولًا، واعزل المقاطع ثنائية الاتجاه، وادعم التقويمين.
  • الاحتكاك يتناسب مع المخاطرة: توقف وحذّر عند المستفيدين الجدد والمبالغ الكبيرة، وابتعد عن الطريق في الفواتير الروتينية.
  • لا تختبر الرسوم أو الموافقة أو الإفصاح بأسلوب A/B من أجل التحويل أبدًا؛ اختبر الوضوح وقِس الفهم.
  • وظّف مصمم المحتوى العربي ومهندس التصميم قبل الرسام؛ وتبنَّ نظام تصميم مبكرًا وانتقل إلى الفريق الداخلي بمجرد حصولك على الترخيص.