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

وهنا تظهر المشكلة.

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

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

وهنا تظهر مفارقة مهمة: الواجهات تطلب من المستخدم التذكّر في اللحظة التي يحتاج فيها أكثر إلى التأكد.

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

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

وهذا يغيّر وظيفة الشاشة نفسها.

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

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

الهدف ليس أن نجعل المستخدم يتذكر أكثر.

الهدف أن نعطيه ما يحتاجه ليتأكد، من دون أن نطلب منه أن يتذكره أصلًا