01 / المهمةما الذي يحاول المستفيد إنجازه؟
قد يرى النظام الخدمة باسم إجراء داخلي بينما يفكر المستفيد في هدف مختلف: الحصول على تصريح، تعديل بيانات، إثبات استحقاق، أو معرفة حالة طلب. نبدأ من لغة المهمة كما يفهمها الناس، ثم نربطها بالمتطلبات الرسمية. لا تكفي إعادة تسمية الزر إذا بقيت شروط الأهلية أو المستندات غير مفهومة. نحدد نقطة بداية الرحلة ونهايتها، والقنوات التي يمر بها المستفيد، والأسباب التي تدفعه إلى الاتصال أو زيارة الفرع رغم وجود خدمة رقمية. هذا التعريف يسمح بقياس الجهد الحقيقي بدل الاكتفاء بعدد الزيارات الإلكترونية.
02 / الأهليةشرح شروط الخدمة قبل بدء الطلب
كثير من الطلبات المرفوضة لا يعكس عدم أهلية المستفيد، بل غموضًا في تفسير شرط أو نقص وثيقة لم يفهم أهميتها. نراجع نصوص الشروط مع أصحاب السياسة، ونحولها إلى أسئلة واضحة دون تغيير حكمها. يمكن اختبار فاحص جاهزية بسيط يوضح ما يحتاجه الشخص قبل تعبئة نموذج طويل، مع بيان أن التقييم النهائي للجهة المختصة. لا نختزل الاستثناءات أو الحالات الإنسانية في قرار آلي قاطع إذا كانت السياسة تتطلب مراجعة بشرية. التبسيط الجيد يرفع الفهم ويحفظ الحق في المسار الصحيح.
03 / القنواتإجابة واحدة عبر الموقع والهاتف والفرع
حين تختلف معلومة الموعد أو المتطلبات بين قناة وأخرى، يفقد المستفيد الثقة حتى لو كانت الواجهة الرقمية جيدة. نحدد مصدرًا معتمدًا للمعلومة، ومن يملك تحديثه، وكيف يصل التعديل إلى فرق الاتصال والاستقبال والقنوات الرقمية. لا تحتاج كل قناة إلى النص نفسه حرفيًا؛ يكفي أن يكون المعنى والشرط والقرار متسقًا. نختبر ذلك بأسئلة حقيقية وردت إلى القنوات، ونتتبع أين تغيرت الإجابة. يمكن أن يبدأ الحل بقاعدة معرفة ومسؤول تحديث قبل مشروع تقني واسع.
04 / الطلبتقليل إعادة الإدخال دون جمع بيانات لا حاجة لها
نراجع الحقول المطلوبة وما إذا كانت الجهة تملك المعلومة أصلًا أو تستطيع التحقق منها عبر مسار مصرح. لا يبرر وجود حقل في النظام القديم إبقاءه في النموذج الجديد. في الوقت نفسه لا نحذف معلومة لازمة لاتخاذ قرار نظامي. نختبر ترتيب الخطوات وحفظ التقدم ورسائل الخطأ مع مستخدمين مختلفين، بما فيهم من يستخدم الهاتف أو تقنيات مساعدة. يجب أن يعرف المستفيد لماذا يُطلب كل مستند وماذا يفعل عند تعذر توفيره، بدل أن يجد رفضًا عامًا بعد وقت طويل.
05 / الحالاتحالة طلب مفهومة ومسار اعتراض واضح
عبارة «قيد المعالجة» قد تبقى أيامًا دون أن يعرف المستفيد إن كان عليه إجراء شيء. نعرّف حالات مرتبطة بأحداث حقيقية، ونكتب رسالة تبين ما اكتمل وما ينقص ووقت التحديث المتوقع إن أمكن. إذا رفض الطلب، يحتاج الشخص إلى سبب مفهوم وخطوة تصحيح أو اعتراض وفق سياسة الجهة. لا تعد الصفحة بمدة لا يستطيع التشغيل الوفاء بها. ويحتاج الموظف أيضًا إلى رؤية سبب الحالة ومن يملك نقلها، حتى لا تتحول متابعة الطلب إلى اتصالات لا ينتج عنها قرار.
06 / الاستثناءاتخدمة عادلة للحالات التي لا تتبع المسار المعتاد
قد يختلف وضع مستفيد بسبب نقص سجل أو ظرف خاص أو اختلاف وثيقة. إذا صممنا المسار للحالة الأسهل فقط، نقلنا العبء إلى الهاتف والفرع وربما منعنا من يحتاج الخدمة أكثر. نحدد أنواع الاستثناء التي يجب أن يبقى لها مسار بشري، والمعلومات اللازمة للمراجعة، وحقوق التصعيد. لا تبت الجهة المصممة في سياسة الاستحقاق؛ تشارك أصحاب الصلاحية في جعلها قابلة للفهم والتطبيق. نقيس أثر التحسين على الحالات المعقدة أيضًا، لا على متوسط الطلبات المكتملة فقط.
07 / الخصوصيةالحد الأدنى من البيانات مع صلاحيات واضحة
تتعامل الخدمات العامة مع بيانات قد تكون حساسة، لذلك تُراجع حاجة كل دور للوصول إلى المعلومة، وطريقة إخفاء ما لا يلزمه، وسجل تغيير الطلب. لا تُستخدم عينات حقيقية في ورش عامة بلا تصريح وضوابط، ويمكن البدء بحالات ممثلة لا تكشف هوية أشخاص. أي تكامل أو مشاركة بيانات تخضع لموافقة الجهة واشتراطاتها، ولا تكفي فكرة «تحسين التجربة» لتجاوزها. في الموقع العام يكفي وصف المشكلة بصورة مجردة عند طلب النطاق، ثم تحدد قناة آمنة للدراسة الفعلية.
08 / القياساكتمال الخدمة والجهد والثقة بدل عدد النقرات
قد ترتفع الزيارات للبوابة لأن الخدمة غير مفهومة، لا لأنها ناجحة. ننظر إلى الإكمال من أول مرة، وأسباب الرجوع، وعدد الاتصالات بعد الطلب، وزمن الانتظار بين القرارات، وجودة الرد، وإمكانية وصول الفئات المختلفة. تُعرّف المؤشرات وتُقرأ مع تغير السياسة وحجم الطلب والموسمية. لا يجوز دفع الموظفين إلى تصنيف حالة معقدة على أنها مغلقة لتحسين الرقم. إذا افتقدت البيانات دقة كافية، نبدأ بعينة مراجعة واضحة ونبني قاموسًا للمقاييس قبل لوحة إدارة شاملة.
09 / الاختبارتجربة لغة أو خطوة محددة قبل تعميمها
يمكن اختبار نص شروط أو ترتيب حقول أو رسالة حالة مع مجموعة صغيرة في بيئة مناسبة، ثم مراجعة الفهم والأخطاء والجهد. لا يعني نجاح الاختبار إلغاء مراجعة السياسة أو الأمن أو الإتاحة؛ بل يوفر دليلًا يساعد على اتخاذ قرار. عند تطبيق التغيير في قناة واحدة نراقب أثره على القنوات الأخرى، لأن نقل الأسئلة إلى مركز الاتصال ليس تحسنًا في الخدمة الكلية. نوثق ما نجح ولمن وتحت أي شروط، ونحدد معيارًا لإيقاف التجربة إذا ظهرت آثار غير مرغوبة.
10 / المساركيف تختار الجهة بداية عملية؟
إذا كان الألم في لغة المتطلبات وانتقال المستفيد بين القنوات، نبدأ بـتصميم تجربة المستفيد. إذا كان الطلب ينتظر بين إدارات أو صلاحيات، يناسبه نموذج تشغيل واضح. وإذا كان المطلوب إطلاق خدمة جديدة، تفيد منهجية إطلاق الخدمة الرقمية. يحدد أصحاب السياسة والتقنية والتشغيل نطاق التجربة والقيود قبل أي وعد بالمدة أو التكلفة. لا تمثل هذه الصفحة شهادة تنفيذ مع جهة حكومية.
11 / الإتاحةخدمة مفهومة لمن لا يبدأ من التطبيق
قد يعتمد بعض المستفيدين على موظف أو هاتف أو جهاز مشترك، ولا ينبغي أن يضيع حقهم لأن الخدمة الرقمية صممت للمستخدم الخبير فقط. نختبر اللغة وحجم الخط وترتيب الخطوات ورسائل الخطأ مع فئات مختلفة، ونوضح مسار المساعدة عند تعذر الإكمال. لا ننسخ الواجهة نفسها إلى كل قناة؛ نضمن اتساق الشرط والقرار والمعلومة. ويُراجع أثر أي تحسين على مدة الخدمة وجهد الموظف أيضًا، حتى لا يُنقل التعقيد من المستفيد إلى فريق آخر من دون حل.
