13 يونيو 2025·6 دقيقة قراءة

تسميات حالة سير العمل: 7 حالات واضحة يمكن لفريقك مشاركتها

تسميات حالة سير العمل تجعل التسليمات واضحة عبر الأدوات. تعرّف على 5–7 حالات عملية، ما يعنيه كل منها، وكيف تحافظ على اتساقها على الويب والهواتف.

لماذا تؤخر التسميات غير الواضحة العمل

تسميات حالة سير العمل المبهمة تخلق ارتباكًا يبدو كعمل شغل. الناس يحركون العناصر للأمام، لكن لا أحد متأكد مما تغيّر فعليًا. قد يعني تذكرة معنونة "In Progress" أن "بدأت أفكر بها"، أو "موقوف بسبب عائق"، أو "انتهيت وأنتظر المراجعة"، اعتمادًا على آخر من لمسها.

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

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

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

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

ماذا يجب أن تعني تسمية الحالة (وما لا يجب أن تعنيه)

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

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

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

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

حالة مفيدة يجب أن تثير واحدًا من ثلاثة أشياء:

مالك تالي (من يلتقطها)
إجراء تالي (ما الذي يحدث بعد ذلك)
شرط انتظار (ما الذي ننتظره)

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

كم عدد الحالات ولماذا 5–7 مناسب

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

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

الحفاظ على مجموعة صغيرة يقلل أيضًا من "بحث الحالة" (التخمين أي من 12 خيارًا الأقرب)، ويسهّل التقارير، ويجبرك على إبقاء الأولوية، والمالك، والنوع كحقول منفصلة.

الأسماء يمكن أن تختلف، وهذا مقبول. قد يقول فريق "In Progress" بينما يقول آخر "Doing". ما لا يمكن أن يختلف هو المعنى. إذا كان "In Review" يعني أحيانًا "في انتظار QA" وفي أحيانٍ أخرى "في انتظار العميل"، تتحول لوحتك إلى ضوضاء.

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

مجموعة بسيطة من 7 حالات يمكنك البدء بها

إذا أردت تسميات تظل واضحة مع الزمن، ابدأ بمجموعة صغيرة تجيب عن ثلاثة أسئلة: من يملكها الآن، ماذا يحدث بعد ذلك، وما معنى "المنجز".

إليك مجموعة بسيطة من 7 حالات تعمل لمعظم الفرق دون تعقيد زائد.

Status	What it means (plain English)	Default owner	Next step
New	The request is captured, but nobody has reviewed it yet.	Request triage (lead/PM)	Review and decide: do now, schedule, or reject.
Triaged	It’s been reviewed and routed (bug vs feature), and the team agrees it’s valid.	Lead/PM	Clarify scope and decide whether it’s worth doing.
Ready	It can be started without missing info or dependencies.	Lead/PM	Assign an owner and start work.
In Progress	Someone is actively working on it.	Assignee	Move forward until it’s ready to be checked.
In Review	Work is complete enough to check (peer review, QA, stakeholder approval).	Reviewer	Approve or send back with clear notes.
Blocked	Work can’t continue because of a specific dependency.	Assignee	Remove the blocker or escalate to the person who can.
Done	It meets the agreed definition of done and needs no more action.	Nobody	Keep for reporting; reopen only with a new reason.

القاعدة الأساسية: لا تستخدم "Waiting" بمفردها. إذا كان شيء ما عالقًا، سمه Blocked واذكر الاعتمادية في الملاحظة (مثل: "Blocked: customer reply" أو "Blocked: access granted").

تعريفات لكل حالة (مع قواعد الدخول والخروج)

ابنِ تطبيق سير العمل الخاص بك

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

جرّب AppMaster

تعمل التسميات الواضحة بأفضل شكل عندما تجيب كل واحدة على سؤال بسيط: ما هو الصحيح الآن؟

New

ما هو الصحيح: تم تقيدم العنصر، لكن لم يقيّم أحد الأمر بعد.

ما الذي ليس صحيحًا: لم يتفق أحد على الأولوية أو النطاق أو المالك.

دخول: تم تقديم طلب.

خروج: يقرأه شخص ما وينقله إلى Triaged.

مثال: "وكيل دعم يسجل تقرير خطأ مع لقطة شاشة واحدة."

Triaged

ما هو الصحيح: الفريق يفهم الطلب بما يكفي لتوجيهه والتأكد من صحته.

ما الذي ليس صحيحًا: أنه جاهز للبدء.

دخول: يضيف شخص ما سياقًا أساسيًا (ملخص، التأثير، المنطقة المتأثرة).

خروج: يتم إعداده للعمل (Ready) أو رُفض عمدًا (يُعالج خارج سير العمل، ليس كحالة).

مثال: "يقوم مدير المنتج بعلامته كخطأ حقيقي ويذكر خطوات إعادة الإنتاج."

Ready

ما هو الصحيح: يمكن البدء به دون معلومات ناقصة.

ما الذي ليس صحيحًا: العمل لم يبدأ بعد.

دخول: معايير القبول واضحة والاعتمادات متاحة.

خروج: يبدأ شخص العمل ويجري التغيير الأول المعنوي (In Progress).

مثال: "تم الاتفاق على حقول النموذج وقواعد التحقق."

In Progress

ما هو الصحيح: العمل النشط جارٍ.

ما الذي ليس صحيحًا: أنه ينتظر في قائمة.

دخول: يلتقطه شخص ما ويبدأ العمل.

خروج: يصبح كافيًا للمراجعة (In Review) أو يصطدم بتبعية (Blocked).

مثال: "المطور يبني قائمة الحالة الجديدة ويحفظ المنطق."

In Review

ما هو الصحيح: يُجرى التحقق (مراجعة زميل، QA، أو موافقة أصحاب المصلحة).

ما الذي ليس صحيحًا: لا تتم إضافة ميزات جديدة.

دخول: يقدم المنفّذ العمل للتحقق.

خروج: يُوافق ويستوفي تعريف الفريق للمنجز (Done)، أو يعود بتعليقات (In Progress).

مثال: "QA يؤكد أنها تعمل على الويب والموبايل."

Blocked

ما هو الصحيح: لا يمكن الاستمرار بالعمل بسبب تبعية محددة ومسمّاة.

ما الذي ليس صحيحًا: العنصر مجرد أقل أولوية.

دخول: المصمم يصطدم بتبعية لا يستطيع حلها بمفرده.

خروج: تُزال التبعية ويُستأنف العمل (عادةً In Progress).

مثال: "Blocked: waiting for access to production logs."

Done

ما هو الصحيح: يستوفي معايير القبول المتفق عليها وتم شحنه أو جاهز للشحن.

ما الذي ليس صحيحًا: لا يزال يحتاج مراجعة أو اختبار أو متابعة.

دخول: تجتاز المراجعة وتكتمل خطوات الإصدار (بناءً على تعريف فريقك).

خروج: لا شيء؛ إعادة الفتح تبدأ دورة جديدة مع سبب واضح.

مثال: "تم الإصلاح ونُشر ولم يعد العطل يتكرر."

خطوة بخطوة: أنشئ نظام الحالات الخاص بك في 60 دقيقة

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

جلسة عمل لمدة 60 دقيقة (بهدف واحد)

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

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

بعد ذلك، أزل التكرارات وأعد تسمية الملصقات الغامضة. ادمج التسميات التي تعني نفس الشيء ("In Progress" مقابل "Doing"). أعد تسمية الغامضة ("Pending") إلى شيء يمكن اتخاذ إجراء عليه ("Blocked: customer reply"). إذا لم تستطع شرح تسمية في جملة واحدة، فهي ليست جاهزة.

ثم أضف تعريفات مع قواعد دخول وخروج. لكل حالة اكتب ما يجب أن يكون صحيحًا للدخول وما يجب أن يكون صحيحًا للخروج. اجعلها قصيرة. مثال: "In Review يدخل عندما يُقدَّم العمل، ويخرج عندما تُعالَج الملاحظات ويوافق المراجع."

بعد ذلك، اختر مالكين لكل تسليم. يجب أن يكون لكل حالة مالك افتراضي (دور يكفي). هذا يمنع العناصر من التعثر. مثال: العناصر في "In Review" مملوكة للمراجع، وليس للشخص الذي نفذ العمل.

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

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

حافظ على اتساق الحالات عبر شاشات الويب والموبايل

اجعل حالات الهاتف المحمول واضحة

ابنِ عروض قائمة مدمجة للهاتف حيث تظل تسميات الحالة مقروءة ومتسقة.

أنشئ شاشات

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

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

قواعد صغيرة للشاشات الصغيرة تعمل فعلاً

شاشات الهاتف تجبر على أسماء قصيرة وتصميم بصري قوي. تسمية تبدو جيدة على جدول سطح المكتب قد تصبح شارة مقطوعة ومربكة على الهاتف.

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

المكان مهم أيضًا. ضع الحالة قرب العنوان في عرض التفاصيل لتُرى قبل قراءة الوصف الكامل. في قوائم، اعرضها في نفس الموضع دائمًا.

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

أخطاء شائعة تجعل الحالات تنحرف

تحقق من نظام الحالات الخاص بك

اختبر مجموعة الحالات الخاصة بك على عناصر حقيقية بتطبيق عامل بدلًا من مستند طويل.

نموذج سريع

تنحرف الحالات عندما تتوقف عن معنى "أين العمل" وتبدأ بمعنى "كيف يشعر الناس تجاه العمل". بمجرد أن يحدث ذلك، تبدو لوحتك مشغولة لكن لا أحد يثق بها.

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

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

راقب هذه الأنماط:

عدة تسميات "منجزة تقريبًا" بدون فرق واضح
تسميات شخصية لمرة واحدة ("Waiting for Sam")
تحول "In Progress" إلى موقف انتظار
غياب قواعد دخول وخروج مكتوبة
شاشات جديدة تعرض أسماء حالات أو ترتيبات مختلفة

لمنع الانحراف، عيّن مالكًا واحدًا لمجموعة الحالات واجعل التغييرات نادرة. وعند تغير شيء، دون ما تغيّر، ولماذا، وما الذي استبدله.

مثال: طلب واحد من البداية إلى النهاية

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

New: يجمع الدعم لقطات الشاشة وتفاصيل الجهاز وما الذي يُعد صحيحًا.

Triaged: يؤكد مالك المنتج أنه خطأ حقيقي، يحدد أين ينتمي (تطبيق الموبايل، ليس الخلفية)، ويوضح التأثير.

Ready: تؤكد خطوات إعادة الإنتاج ومعايير القبول.

In Progress: يُعيد مهندس إنتاج العطل، يكتشف أن الـ API تُعيد بيانات لكن الشاشة تصفيها بشكل خاطئ، ويبدأ الإصلاح.

Blocked: يكتشف المهندس أن الواجهة تعتمد حقلًا مفقودًا من حسابات قديمة وتحتاج تغييرًا في الخلفية. يُعلّم العنصر Blocked بملاحظة واضحة: "Blocked: backend needs legacy field mapping."

In Review: بعد حل التبعية، يتحقق QA على iOS و Android ويتأكد أن الحالة الفارغة تظهر فقط عندما لا توجد طلبات بالفعل.

Done: يُوافق على الإصلاح ويُنشر (أو يُدرج في نافذة الإصدار التالية إذا كان ذلك يُعتبر منجزًا لفريقك). يؤكد الدعم أنه مباشر ويرد على العميل.

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

قائمة فحص سريعة للحفاظ على اتساق الفريق

من اللاكود إلى الشيفرة الحقيقية

سجّل تطبيقات جاهزة للإنتاج بشيفرة مُولَّدة بـ Go و Vue3، و Kotlin أو SwiftUI الأصليين.

توليد الشيفرة

إذا كانت لوحتك فوضوية، عادةً ما ترى السبب خلال 10 دقائق.

فحص اللوحة في 10 دقائق

امشِ عبر اللوحة وابحث عن هذه الإشارات:

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

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

فحص اتساق الويب + الموبايل

افتح نفس سير العمل على هاتف وتأكد أن التسميات لا تزال تعمل في المساحات الضيقة.

التسميات قصيرة ومقروءة في قوائم (لا تقطّع)
النص واضح دون الاعتماد على اللون
تغيّرات الحالة يوافق عليها مالك واحد (قائد الفريق أو العمليات)، لا يقررها كل شخص بمفرده
التغييرات تُرافق بملاحظة قصيرة حتى لا تنحرف التعريفات

الخطوات التالية: صيانة، قياس، وتحسين بمرور الوقت

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

حدد إيقاعًا خفيفًا للمراجعة، مثل مراجعة شهرية مدتها 30 دقيقة مع شخص واحد من كل دور يتعامل مع اللوحة. أحضر 5–10 عناصر حديثة وابحث عن استثناءات يمكن إصلاحها.

بعض الإشارات البسيطة التي يستحق تتبعها:

الوقت المستغرق في Blocked (وأسباب القمة)
العناصر التي تتنقل بين حالتين مرارًا
العناصر التي تجلس دون لمس بعد زمن دورتك العادي

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

إذا كنت تبني سير العمل في أداة داخلية، عامل الحالات كبيانات مشتركة بدلًا من نصوص خاصة بالشاشات. في AppMaster (appmaster.io)، على سبيل المثال، يمكنك تعريف حقل الحالة مرة واحدة في Data Designer وإعادة استخدامه عبر تطبيقات الويب والهواتف الأصلية، مما يساعد على منع انحراف المعنى بين الشاشات.

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

ابدأ بخمس إلى سبع حالات تتطابق مع المسار الطبيعي: شيء مثل New، Ready، In Progress، In Review، Blocked، و Done. اجعل كل تسمية تعني شيئًا واضحًا واحدًا وتجنّب استخدام الحالة للتعبير عن الأولوية أو ملاحظات شخصية.

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

استخدم “Blocked” عندما لا يمكن الاستمرار في العمل بسبب تبعية محددة، واكتب سبب الحظر في ملاحظة التذكرة. غالبًا ما يكون مصطلح “Waiting” غامضًا لأنه يخفي على ماذا ننتظر ومن يجب أن يتحرك بعد ذلك.

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

يجب أن تعني «In Progress» أن العمل الفعلي جارٍ، لا أن شخصًا ما ألقى نظرة سريعة أو أنه قد تم تخصيصه فقط. إذا كان متوقّفًا أو بانتظار مدخلات، حوّله إلى Blocked أو أعده لحالة قبل العمل.

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

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

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

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

عامل الحالة كبيانات مشتركة، لا نص خاص بالشاشة، حتى تسحب كل واجهة نفس القيمة. على سبيل المثال، في AppMaster (appmaster.io) يمكنك تعريف حقل الحالة مرة واحدة في Data Designer وإعادة استخدامه عبر تطبيقات الويب والهواتف لتقليل انحراف المعنى بين الشاشات.