5 Ws and H | پنج W و H (چه کسی، چه، کجا، کی، چرا، چگونه)
تعریف دقیق
پنج W و یک H (5W1H) روش journalism و تحلیل سیستمی است که قبل از اقدام، واقعیت را از زوایای مختلف می‌پرسد. در UX، جایگزین فرض نیست؛ جایگزین «ما یک اپ می‌خواهیم» بدون تعریف مسئله است.
Who مخاطب و actorها را مشخص می‌کند. What outcome یا artifact است. Where context فیزیکی/دیجیتال. When زمان و urgency. Why motivation و success criteria. How مسیر فعلی یا constraint فنی.
تعریف عملی: یک صفحه template 5W1H پر شده قبل از kickoff redesign یا research plan الزام شود.
چرا مهم است
پروژه‌های شکست‌خورده ا often یک W ضعیف دارند—معمولاً Why یا Who. 5W1H ارزان است اما از ماه‌ها build اشتباه جلوگیری می‌کند.
برای تیم فارسی، ترجمهٔ Wها به زبان ساده در workshop کمک می‌کند stakeholder غیرفنی هم participate کند.
چگونه کار می‌کند
workshop ۴۵ دقیقه: سکوت نوشتن individually، سپس compare gaps. facilitator conflict بین پاسخ‌ها را highlight می‌کند—تناقض here یعنی risk.
پس از پر کردن، problem statement یک پارagraph بنویسید و link به metric. در research، guide interview از gapهای 5W1H سؤال می‌سازد.
اجزا و انواع
می‌توان برای user story، bug ticket، marketing brief، یا service blueprint entry استفاده کرد. نسخهٔ extended: How much (هزینه) گاهی اضافه می‌شود.
کاربرد در محصول و UX
قبل از usability test: Who شرکت‌کننده، What task، Where device، When در funnel، Why hypothesis، How protocol. پس از launch incident: 5W1H post-mortem بدون blame.
مثال‌های عملی
تیم فهمید Why «صرفه‌جویی زمان» بود نه «زیبایی UI»—priorities عوض شد. مثال بد: checkbox template بدون discussion.
اشتباهات رایج
پاسخ کلی «کاربران». What = feature به‌جای outcome. skip How و surprise در integration. استفاده one-time بدون update.
نکات پیاده‌سازی
template در Notion. attach به Jira epic. در retro 5W1H را update کنید وقتی learning جدید آمد.
ارتباط با mفاهیم مرتبط
با problem framing، user story، JTBD، root cause analysis، discovery و workshop facilitation مرتبط است.
جمع‌بندی کاربردی
5W1H لنگر clarity است: شش سؤال ساده که Who/Why/How را explicit می‌کند تا طراحی و research روی مسئلهٔ درست متمرکز شوند نه روی اولین راه‌حل.
عمق تصمیم‌گیری در تیم محصول
برای اینکه پنج W و H (چه کسی، چه، کجا، کی، چرا، چگونه) فقط در حد تعریف باقی نماند، آن را به آیین‌های واقعی تیم وصل کنید: پالایش بک‌لاگ، نقد طراحی، برنامه‌ریزی انتشار، و بازبینی کیفیت. هرگاه بحث به سلیقه شخصی کشیده شد، یک معیار مرتبط با همین مفهوم را روی میز بگذارید تا گفتگو از سلیقه به شواهد نزدیک شود. دو نمونه داخلی از اجرای خوب و بد را در فضای مستندات نگه دارید تا اعضای جدید سریع‌تر بیاموزند. این کار هزینه کمی دارد اما از تکرار اشتباهات جلوگیری می‌کند و زبان مشترک می‌سازد. مالک مفهوم را هم مشخص کنید تا مسئولیت پخش نشود و صفحه دانش با مثال‌های زنده محصول فصل‌به‌فصل غنی‌تر شود.
کیفیت درک یک واژه وقتی معلوم می‌شود که بتواند تصمیم فردا را عوض کند. اگر پس از خواندن هنوز نمی‌دانید چه رفتار متفاوتی باید داشته باشید، توضیح کامل نشده است. در بازبینی محتوا بپرسید: کدام ابهام رایج برطرف شد؟ کدام ریسک کم شد؟ کدام مسیر اشتباه بسته شد؟ پاسخ این سوال‌ها متن را از مقاله عمومی به راهنمای حرفه‌ای تبدیل می‌کند. تیم‌های بالغ دانش را در سیستم نگه می‌دارند نه فقط در ذهن افراد. پیوند دادن مفهوم به معیار پذیرش، چک‌لیست QA و سوالات مصاحبه استخدام، یادگیری را ماندگار می‌کند و از فراموشی بعد از یک اسپرینت جلوگیری می‌کند.
در تیم‌های کوچک و محیط‌های پرشتاب، وسوسه میانبر زیاد است: کپی الگوی خارجی بدون تطبیق، یا نادیده گرفتن مفهوم به‌خاطر فشار زمان. راه میانه این است که حداقل نسخه درست را تعریف کنید، در یک جریان واقعی بیازمایید، و فقط پس از دیدن اثر دامنه را گسترش دهید. مستند کوتاه یک‌صفحه‌ای با لینک نمونه اغلب بهتر از کارگاه طولانی بدون خروجی است. اگر فقط یک بهبود این هفته می‌سازید، آن را به چک‌لیست سه‌آیتمی تبدیل کنید و در نقد بعدی اجباری کنید تا عادت شود.
سنجش اثر و یادگیری مستمر
هر مفهوم طراحی وقتی ارزشمند است که حلقه بازخورد داشته باشد. قبل از اعمال گسترده فرضیه بنویسید: کدام رفتار کاربر یا شاخص عملیاتی باید تغییر کند؟ بعد از انتشار، داده کمی را کنار شواهد کیفی بگذارید؛ میانگین داشبورد به‌تنهایی کافی نیست. مصاحبه کوتاه، مشاهده پشتیبانی و بررسی مسیرهای پرتکرار اغلب علت ریشه‌ای را بهتر نشان می‌دهند. یافته را به بک‌لاگ برگردانید و دانش تیمی را به‌روز کنید تا یادگیری انباشته شود. این چرخه تفاوت تیم‌هایی است که فقط خوانده‌اند با تیم‌هایی که واقعاً می‌دانند.
شفافیت واژه‌ها اصطکاک بین‌نقشه‌ای را کم می‌کند. اگر طراحی، محصول، مهندسی و بازاریابی تعریف مشترکی نداشته باشند، هر کدام نسخه متفاوتی از واقعیت را بهینه می‌کنند. یک واژه دقیق مثل لنگر عمل می‌کند: جلسات کوتاه‌تر، سوءتفاهم کمتر در تحویل، و اولویت‌های قابل‌دفاع‌تر. علاوه بر تعریف، «غیرمثال» بنویسید؛ یعنی چه چیزی مصداق این مفهوم نیست. غیرمثال مرز را روشن و از تورم معنایی جلوگیری می‌کند. هدف نهایی سودمندی برای تصمیم محصول است؛ با این حال پوشش ابهام‌های واقعی نیازمند عمق کافی است تا خواننده تازه‌کار و متخصص هر دو مسیر کامل داشته باشند و محتوا برای آموزش پایدار و دیده شدن تخصصی شایسته باشد.
چک‌لیست اجرایی هفته اول
روز اول: تعریف یک‌جمله‌ای توافق‌شده و فهرست سه موقعیت واقعی محصول که مفهوم در آن‌ها صادق است. روز دوم: شناسایی یک جریان کاربر و علامت‌گذاری نقاطی که مفهوم باید تصمیم را عوض کند. روز سوم: نوشتن معیار پذیرش کوتاه مرتبط. روز چهارم: بازبینی یک پیاده‌سازی موجود و ثبت فاصله‌ها. روز پنجم: تصمیم برای اصلاح فوری یا ثبت بدهی تجربه با تاریخ بازبینی. این برنامه سبک، مفهوم را از صفحه واژه‌نامه به عادت تیمی می‌آورد و از فراموشی بعد از مطالعه جلوگیری می‌کند. در پایان هفته، یک پاراگراف درس‌آموخته به مستند اضافه کنید تا چرخه بعدی سریع‌تر شروع شود.
مقاومت رایج این است که «الان وقت عمیق شدن نداریم». واقعیت این است که سطحی ماندن معمولاً زمان بیشتری در باگ، دوباره‌کاری و بحث‌های تکراری می‌سوزاند. سرمایه‌گذاری کوتاه روی فهم مشترک، هزینه هماهنگی بلندمدت را کم می‌کند. اگر ظرفیت محدود است، به‌جای پوشش همزمان همه جنبه‌ها، روی پرریسک‌ترین سناریو تمرکز کنید و همان را درست انجام دهید. سپس با شواهد، بودجه یادگیری بیشتر بگیرید. این رویکرد برای سازمان‌هایی که تازه به بلوغ تجربه کاربری می‌رسند واقع‌بینانه‌تر از آرمان کامل‌گرایی است و همچنان استاندارد حداقل هزار کلمه توضیح کاربردی را با محتوایی مفید—نه پرکننده تهی—پاسخ می‌دهد.
پیوند به تحویل و کیفیت
مفهوم را در قالب سوال‌های مشخص به handoff و QA وصل کنید تا در لحظه ساخت فراموش نشود. برای هر جریان مهم، سه نسخه عادی، منتظر و شکست را مرور کنید و ببینید آیا درک شما از موضوع در هر سه نسخه اثر دارد یا نه. اگر اثر ندارد، یا مفهوم به آن جریان نامربوط است یا تعریف‌تان هنوز انتزاعی مانده است. این تست ساده صحت کاربردی توضیح را بالا می‌برد. همچنین در بازبینی‌های ماهانه انتشار، یک مورد را عمیق بررسی کنید و نتیجه را به کتابخانه الگو برگردانید تا دانش تجربی محصول رشد کند و صفحه آموزشی با واقعیت میدان هم‌خوان بماند.
عمق تصمیم‌گیری در تیم محصول
برای اینکه پنج W و H (چه کسی، چه، کجا، کی، چرا، چگونه) فقط در حد تعریف باقی نماند، آن را به آیین‌های واقعی تیم وصل کنید: پالایش بک‌لاگ، نقد طراحی، برنامه‌ریزی انتشار، و بازبینی کیفیت. هرگاه بحث به سلیقه شخصی کشیده شد، یک معیار مرتبط با همین مفهوم را روی میز بگذارید تا گفتگو از سلیقه به شواهد نزدیک شود. دو نمونه داخلی از اجرای خوب و بد را در فضای مستندات نگه دارید تا اعضای جدید سریع‌تر بیاموزند. این کار هزینه کمی دارد اما از تکرار اشتباهات جلوگیری می‌کند و زبان مشترک می‌سازد. مالک مفهوم را هم مشخص کنید تا مسئولیت پخش نشود و صفحه دانش با مثال‌های زنده محصول فصل‌به‌فصل غنی‌تر شود.
سوالات متداول
چارچوب پرسش: Who (چه کسی)، What (چه چیز)، Where (کجا)، When (کی)، Why (چرا)، How (چگونه)—برای شفاف کردن مسئله، brief، incident، یا story قبل از jump به راه‌حل.
نوشتن problem statement، آماده‌سازی user interview، debrief پس از تست، post-mortem باگ، و هم‌تراز کردن stakeholder روی scope.
5 Whys فقط روی علت ریشه‌ای Why تکرار می‌کند؛ 5W1H panorama کامل context می‌دهد قبل از deep why. مکمل هم هستند.
Why (انگیزه واقعی) و Who (segment دقیق—not «همه کاربران»). Without Why، design solution-first می‌شود.
Who: مدیران فروش B2B. What: گزارش pipeline غیرقابل اعتماد. Where: موبایل بین جلسات. When: پایان quarter. Why: تصمیم resource. How: export دستی—→ فرصت طراحی dashboard موبایل.