دراسة حالة · تصوّر لمنتج حكومي · تطبيق جوال

خدماتي

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

  • مصمم UI/UX
  • أسبوع واحد
  • iOS وAndroid · بالعربية، من اليمين إلى اليسار
  • مشروع فردي

نظرة سريعة

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

الجدول الزمني للمشروع

  1. الاستكشافمحادثات غير رسمية ومراجعة للمنصات القائمةاليوم 1
  2. رحلة المستخدمتجديد الهوية الوطنية في سبع مراحلاليوم 2
  3. الإطارات الشبكيةأكثر من 30 إطارًا شبكيًا رماديًااليومان 3–4
  4. الواجهة والنظام التصميميالشاشات النهائية والمكوّنات وحالاتهااليومان 5–6
  5. لوحة تحكم الجهاتأداة للموظفين لتحديث حالة الطلباليوم 7

المشكلة.

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

شهدت الخدمات الحكومية الرقمية تحسنًا كبيرًا، لكن التجربة اليومية ما زالت تواجه ثلاث عقبات متكررة:

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

سؤال التصميم: كيف نصمّم تجربة تُنجز فيها المعاملة الحكومية بسهولة، ثم يعرف المستخدم أنها تسير في مسارها من دون أن يضطر إلى متابعتها يدويًا؟

ماذا تعلّمنا.

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

  1. الثقة موجودة، لكن الوضوح غير كافٍ. يثق المستخدمون بالمنصات الرسمية، لكنهم لا يعرفون أين وصل الطلب بعد التقديم.
  2. البحث عن الخدمة أصعب من إنجازها. كثرة الخدمات من دون تصنيف واضح تجعل اكتشاف الخدمة مرهقًا.
  3. الدفع لحظة قلق. أي غموض في خطوة الدفع يُضعف الثقة في التجربة بأكملها.
  4. الإشعارات إما غائبة أو مزعجة. المطلوب إشعار عند تغيّر حالة الطلب، لا سيل من التنبيهات العامة.

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

رحلة واحدة، من البداية إلى النهاية.

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

ماذا غيّرت هذه الخريطة في التصميم؟

  • ألم «متابعة الحالة» و«الدفع» جعل دورة حياة الطلب قلب المنتج، لا شاشة ثانوية.
  • فرصة «ملخص المتطلبات قبل البدء» أصبحت شاشة تعرض المتطلبات والرسوم والمدة قبل بدء الطلب.
  • فرصة «أكثر من وسيلة دفع مع إمكانية إعادة المحاولة» أصبحت شاشة دفع بثلاث وسائل، مع مسار واضح عند فشل العملية.
خريطة رحلة المستخدم لتجديد بطاقة الهوية الوطنية بالعربية، في سبع مراحل من اكتشاف الخدمة حتى استلام البطاقة، ولكل مرحلة أفعال المستخدم وأفكاره ومشاعره ونقاط الألم وفرص التحسين.

عشرة قطاعات، خمسة تبويبات.

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

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

الشاشة الرئيسية في «خدماتي» مع اختصارات القطاعات والطلبات الحديثة والإشعارات، بجوار قائمة الخدمات الكاملة مع البحث وزر التصفية.نافذة تصفية الخدمات مع شرائح القطاعات، وقائمة الخدمات بعد تطبيق التصفية.

البنية أولًا، ثم التفاصيل البصرية.

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

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

خمس حالات، من دون أن يبقى المستخدم في حيرة.

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

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

حالة الطلب ليست معلومة يبحث عنها المستخدم، بل معلومة تصله في الوقت المناسب.

أربع شاشات للطلب: اختيار وسيلة الدفع، ثم طلب قيد المراجعة، وطلب مكتمل مع زر للتحميل، وطلب مرفوض لعدم استكمال البيانات.

إشعارات لها معنى.

تُصنَّف الإشعارات حسب القطاع، مع إبراز غير المقروء منها بوضوح، ويمكن تصفيتها حسب حالة القراءة والفئة والوقت.

قائمة الإشعارات مع إبراز غير المقروء، ونافذة التصفية بخيارات حالة القراءة والفئة والوقت، والقائمة بعد التصفية.

نظام يُبنى عليه، لا مجرد شاشات جميلة.

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

النظام التصميمي لـ«خدماتي»: تدرّجات اللون الأخضر الأساسي والألوان المحايدة، والمقياس الطباعي العربي من H1 إلى Button، والمكوّنات بكل حالاتها، ومنها بطاقة الطلب بحالاتها الخمس، وبطاقات الإشعارات المقروءة وغير المقروءة، وشرائح تصفية القطاعات.

عربي أولًا، لا ترجمة لاحقة.

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

التجربة لا تكتمل من جهة واحدة.

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

الأرقام الظاهرة في تصميم لوحة الجهات توضّح فرضية العرض، وليست نتائج قياس فعلية.

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

لو أصبح منتجًا حقيقيًا.

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

الأثر

مدة تصميم التصوّر
أسبوع واحد
قطاعات خدمية في تطبيق واحد
10
مراحل في رحلة تجديد الهوية الوطنية
7

ملاحظات ختامية

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