Quantitative Research | تحقیق کمی

تعریف دقیق

تحقیق کمی به معنای استفاده از دادهٔ عددی و روش‌های آماری برای توصیف، مقایسه و پیش‌بینی رفتار کاربران یا اثر مداخلات طراحی است. در UX و product، منابع شامل analytics رفتاری (event، funnel، cohort)، آزمایش A/B یا multivariate، نظرسنجی با مقیاس likert، meta-analysis تجربه، و دادهٔ operational مثل support volume است.

هدف کمی اغلب «اندازه و اطمینان» است: آیا تغییر معنادار است؟ کدام segment بیشتر affected است؟ آیا روند بهبود پایدار است؟ برخلاف کیفی، تمرکز روی generalizable patterns در مقیاس بزرگ‌تر است، به‌شرط طراحی درست نمونه و تعریف متریک.

تعریف عملی: تحقیق کمی وقتی ارزش دارد که سوال، متریک، baseline و threshold تصمیم از قبل روشن باشد؛ وگرنه dashboard فقط noise تولید می‌کند.

چرا مهم است

Stakeholder به عدد اعتماد می‌کند؛ اولویت‌بندی roadmap بدون signal کمی سخت می‌شود. A/B به تیم اجازه می‌دهد بین دو راه‌حل طراحی با ریسک کنترل‌شده انتخاب کند. cohort و retention نشان می‌دهد onboarding واقعاً stickiness ساخته یا نه.

در سازمان‌های data-informed، کمی از overspending روی فیچرهای کم‌اثر جلوگیری می‌کند. برای compliance و گزارش به هیئت‌مدیره، متریک استاندارد (conversion، churn) زبان مشترک است.

اما کمی بدون زمینه می‌تواند تصمیم غلط بدهد—مثلاً افزایش کلیک وقتی هدف اشتباه بهینه شده است. برای همین معمولاً باید با تحقیق کیفی جفت شود.

چگونه کار می‌کند

مراحل: تعریف hypothesis و primary metric، instrumentation (event naming schema)، جمع‌آوری با sample کافی، پاک‌سازی outliers، تحلیل (funnel، significance test)، segment drill-down، و مستندسازی decision.

برای A/B: randomization، duration کافی، guardrail metrics (مثلاً revenue نباید افت کند)، و جلوگیری از peeking. برای survey: پرسش unbiased، scale یکسان، و نرخ پاسخ representativeness.

Experimentation platform و analytics باید با privacy و consent هم‌راستا باشند.

اجزا و انواع

انواع: descriptive (چه شد)، diagnostic (کجا افت)، predictive (چه خواهد شد با مدل). ابزار: GA4، Mixpanel، Amplitude، Hotjar quant، internal SQL. نقش analyst، data scientist، و PM metric owner.

UX-specific: benchmark task success در usability test با N بزرگ‌تر، SUS score aggregate، tree test success rate.

کاربرد در محصول و UX

Funnel checkout برای پیدا کردن step drop-off. Event برای feature adoption. Holdout برای اندازه‌گیری long-term effect redesign. Segment mobile vs desktop برای اولویت responsive fix.

برای محتوای فارسی، CTR ممکن است با length copy مرتبط باشد—کمی نشان می‌دهد کدام variant در segment ایران بهتر است، کیفی چرایی را توضیح می‌دهد.

مثال‌های عملی

تیم دو چیدمان صفحهٔ قیمت‌گذاری را A/B می‌کند؛ متریک اصلی «شروع دوره آزمایشی» است؛ variant B حدود ۴٪ بهتر با معناداری آماری؛ سپس rollout. مثال دیگر: تحلیل cohort نشان می‌دهد کاربرانی که آموزش اولیه را رد کردند retention پایین‌تر دارند—محصول onboarding را بازطراحی می‌کند.

مثال بد: ۳ روز A/B و declare winner. مثال بد: optimize page views به‌جای revenue. مثال بد: ignore seasonality در مقایسهٔ ماه به ماه.

اشتباهات رایج

Vanity metrics. تعریف event inconsistent. Simpson’s paradox نادیده گرفته شده. Survey فقط از power users. Dashboard زیاد بدون action.

در UX research: sample کوچک اما ادعای درصد. mixing qualitative quotes با fake precision.

نکات پیاده‌سازی

North Star + input metrics tree. data dictionary برای event. review هفتگی metric با action item. ethics: minimize PII، aggregate where possible.

برای تیم کوچک، شروع با ۳ متریک حیاتی و یک funnel کافی است؛ بعد instrumentation گسترش یابد.

ارتباط با مفاهیم مرتبط

کمی با qualitative research، experimentation، product analytics، KPI، OKR، statistical analysis، و continuous discovery pair می‌شود. RICE و prioritization از signal کمی تغذیه می‌شود.

جمع‌بندی کاربردی

تحقیق کمی مقیاس، روند و معناداری آماری به تصمیم UX می‌دهد وقتی سوال و متریک درست تعریف شده باشد. با بخش‌بندی کاربران، مدت کافی آزمایش، متریک‌های محافظ و ترکیب با کیفی برای «چرا»، تیم از حدس به شواهد نزدیک می‌شود.

تفاوت با مفاهیم نزدیک

در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.

برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.

جایی که معمولاً گیر می‌کنیم

در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.

برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.

سوالات درست قبل از اجرا

در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.

برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.