تقسيم الجمهور حسب الحاجة يبدأ بسؤال عملي: ما الفائدة التي يبحث عنها الشخص في هذا الاستخدام؟ يعرّف OpenStax تقسيم المنافع على أساس ما يقدمه المنتج، وتوضح الصفحة أن الصفات العامة قد لا تكشف الصورة الكاملة. [1] نستخدم الفكرة هنا لبناء مجموعات قابلة للفحص، دون نسخ أمثلة الكتاب أو افتراض أن كل شخص في عمر واحد يريد العرض نفسه.
الخلاصة السريعة
اختر حاجة مرتبطة بقرار في المنتج أو العرض، وسجّل دليلها وحدود المجموعة قبل استخدامها.
- أساس المجموعة هو المنفعة المطلوبة من المنتج، لا افتراضها من العمر أو المهنة. هذا هو التعريف التعليمي المستخدم هنا. [1]
- في مثال المصباح، إضاءة القراءة وثبات الإضاءة في رحلة حاجتان مختلفتان؛ قد يذكر الشخص الاثنتين، فلا تفرض مجموعات حصرية بلا قاعدة.
- اربط اسم المجموعة بموقف موثق، وافصل ما قاله الشخص عما استنتجه الفريق؛ سجل الحالة غير المعروفة أيضًا.
- حوّل الاختلاف إلى خيار واضح للفحص: ضبط الإضاءة أو مدة التشغيل في المثال، دون وعد بأن التقسيم سيرفع المبيعات.
- راجع المجموعة عندما تظهر أدلة تناقض أساسها، ولا تعتبر عدد من قابلتهم حصة ثابتة من السوق.
اختر أساسًا يغير قرارًا
يساعد تعريف تقسيم المنافع في التركيز على وظيفة المنتج المطلوبة. [1] لكن عنوانًا مثل «محبو الجودة» لا يحدد أي قرار: هل يقصدون دوام المادة، أم دقة اللون، أم سهولة الإصلاح؟ اكتب الاختلاف الذي يستطيع فريقك التعامل معه بدل الاكتفاء بوصف إيجابي يشترك فيه الجميع.
قبل إضافة مجموعة، سمِّ القرار الذي ستؤثر فيه. إذا لم يتغير شرح العرض أو تصميمه أو الخدمة المصاحبة له، فقد تكون المجموعة مجرد زينة في التقرير. هذه قاعدة عمل مقترحة للمثال، وليست اختبارًا معياريًا من المصدر.
مصباح واحد وموقفان
نفترض متجرًا يطور مصباحًا محمولًا. يذكر مشارك افتراضي أنه يقرأ في غرفة مشتركة ويريد توجيه الضوء بعيدًا عن الآخرين. ويذكر آخر أنه يستخدم المصباح في رحلة ويريد استمرار الإضاءة دون شحن متكرر. لا نستنتج هذين الاحتياجين من عمرهما؛ دليل المثال هو وصف كل موقف.
قد يقرأ الشخص نفسه أثناء الرحلة. لذلك يمكن أن يحمل وسم الحاجتين إذا كانت قواعد الملف تسمح بالتداخل. وإذا احتجت مجموعات حصرية لمقارنة معينة، اسأل عن الاستخدام الرئيسي وحدد طريقة اختيار واحد، ثم اشرح أن التصنيف لا يمحو الاستخدامات الأخرى.
اكتب الدليل بجانب الاسم
أنشئ صفًا يتضمن رمز المشاركة، والموقف، والحاجة المذكورة، وتاريخ الملاحظة، وحالة الدليل. مثال ذلك: «توجيه الضوء؛ ذكره أثناء شرح القراءة». لا تضع عبارة «يكره الإضاءة القوية» إذا لم يقلها ولم توجد ملاحظة تدعمها؛ الوصف الأول أضيق وأكثر قابلية للمراجعة.
إذا كانت الحاجة مجرد تفسير من الفريق، سمّها فرضية تحتاج سؤالًا إضافيًا. ويمكن أن تكون خانة الاستخدام غير معروفة حتى يُجمع دليل مناسب. المحافظة على هذه الخانة تمنع تحويل نقص المعلومات إلى مجموعة وهمية مثل «لا يهتم بالميزة».
اربط المجموعة بعرض تستطيع فحصه
في النموذج الافتراضي، نعرض طريقة ضبط زاوية الضوء لموقف القراءة، ونوضح مدة التشغيل المقاسة وفق شروط الاختبار لموقف الرحلة إذا توفرت لدينا فعلًا. لا نخترع مدة بطارية هنا، ولا نعد كل مسافر بما لم يختبره المنتج.
يمكن لاحقًا فحص هل فهم المشاركون الفرق بين الخيارين وهل أجاب العرض عن سؤالهم. سجل النتيجة التي تريد ملاحظتها قبل الجلسة. فهم العرض أو تفضيله في جلسة صغيرة لا يساوي تلقائيًا طلبات شراء في السوق، ولا يمنح التقسيم نجاحًا مضمونًا.
احتفظ بإمكانية تغيير المجموعة
إذا اتضح في ملاحظات لاحقة أن المشكلة الأساسية هي حمل المصباح لا توجيهه، أعد فحص حدود المجموعة بدل إجبار كل تعليق على الاسم القديم. احتفظ بنسخة سابقة وتاريخ التغيير، حتى لا تبدو مقارنة تقريرين وكأنها تستخدم التعريف نفسه.
لا تستخدم عدد الأشخاص في مقابلاتك لتعلن نسبة الجمهور كله ما لم يدعم تصميم البحث ذلك. المنتج المحدد والمواقف التي درستها يحددان نطاق الاستنتاج. نتيجة هذا المثال هي طريقة لتوثيق الحاجة والقرار المرتبط بها؛ أما وجودها وانتشارها في نشاطك فيحتاجان بياناتك.
المصادر ومتابعة القراءة
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.