منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · ترجمه: ۶ شهریور ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

تفکر محصول (Product Thinking) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

یک تیم را دو بار تصور کنید: همان آدم‌ها، همان سه ماه، همان بودجه. تنها تفاوت این است که بار اول از قابلیتی شروع می‌کنند که باید ساخته شود، و بار دوم از نتیجه‌ای که باید به‌دست بیاید. فهرست کار این دو تیم از هفتهٔ اول از هم جدا می‌شود.

تعریف

تفکر محصول مجموعه‌ای از فرایندهای ذهنی و روش‌های طراحی است که طراح در برخورد با یک مسئله و حل آن به کار می‌گیرد.

از این نظر به تفکر طراحی شبیه است. جای شروعش اما فرق دارد.

تفکر محصولِ اثرگذار از شناختن مسئلهٔ مخاطب آغاز می‌شود. بعد راهبرد تعیین می‌شود و هدف‌ها روشن می‌شوند.

مقصدش حل مسئلهٔ واقعی از راه ساختن راه‌حلی معنادار است. طراحی که این کار را مرتب انجام می‌دهد، راه‌حل‌هایی می‌سازد که برای مشتری ارزش می‌آفریند.

تا اینجا شبیه هر توصیهٔ خوب دیگری در طراحی به نظر می‌رسد. تفاوتش در ترتیب پرسش‌هاست، و آن ترتیب پیامد عملی دارد.

محصول اول، قابلیت دوم

در کار طراحی، غرق‌شدن در قابلیت‌ها ساده است. جلسه‌ها دربارهٔ قابلیت‌اند، تخمین‌ها دربارهٔ قابلیت‌اند، و فهرست کار هم فهرست قابلیت است.

قابلیت بی‌اهمیت نیست. اما اغلب یک پله پایین‌تر از دلیلی می‌ایستد که کاربر محصول را برایش انتخاب کرده است.

آن دلیل ساده است. کاربر محصول را می‌خرد تا مسئله‌ای واقعی در زندگی خودش حل شود.

گوشی هوشمند نمونهٔ روشنی است. گوشی می‌تواند اپلیکیشن اجرا کند، ولی کار اصلی‌اش ارتباط است.

اپلیکیشن تجربهٔ ارتباط را بهتر می‌کند. بدون تماس و پیام اما، خودِ اپلیکیشن ارزش چندانی ندارد.

پس ترتیب فکر معلوم است: اول محصول، بعد قابلیت. طراح باید اول محصول را ببیند.

نام این ترتیب را نیکل بلاسه گذاشت، طراح محصول و تعامل در Xing، که آن را «تفکر محصول» خواند.

ساختار تفکر محصول

گام اول، تعیین همان مسئله‌ای است که کاربر دنبال حلش است. این گام از بقیه سخت‌تر است و بیشتر از بقیه هم دست‌کم گرفته می‌شود.

اگر مسئله واقعاً وجود نداشته باشد، یا راه‌حل شما حلش نکند، محصول برای کاربر بی‌ارزش است. محصولِ بی‌کاربر هم سرنوشت روشنی دارد.

میان این دو خطا تفاوت مهمی هست. راه‌حل غلط را بعد از انتشار می‌توان اصلاح کرد، ولی مسئلهٔ ناموجود بعد از انتشار چاره‌ای ندارد.

پیدا کردن مسئلهٔ واقعی هم آسان نیست. حتی با پژوهش فراوان، ممکن است مسئله‌ای را ببینید که وجود ندارد.

نقطهٔ شروع درست همیشه یکی است: گفت‌وگو با کسی که ممکن است کاربر شود. نیازهای کاربر از همین گفت‌وگو بیرون می‌آید.

کاربر لازم نیست مسئله‌اش را خوب بیان کند؛ این وظیفهٔ او نیست. پس مشاهدهٔ واقعی هم به گفت‌وگو اضافه می‌شود.

خودِ ساختار سه طبقه دارد و هر طبقه دو پرسش:

• - ۱. کاربر: مسئله‌ای که باید حل شود چیست، و مخاطبی که برایش حل می‌کنید کیست؟
• - ۲. کاری که باید انجام شود: چرا این کار را می‌کنید و چشم‌انداز پشتش چیست، و از چه راهی انجامش می‌دهید؟
• - ۳. خروجی‌ها: چه هدفی می‌گذارید و دقیقاً به چه چیزی می‌رسید، و این هدف به چه قابلیتی تبدیل می‌شود؟

قابلیت در طبقهٔ سوم نشسته است، و در پرسش آخرِ همان طبقه. جایش تصادفی نیست.

یک قالب چهارخطی همین ساختار را در یک جمله می‌بندد. این محصول برای مخاطب است؛ کمکش می‌کند این مسئله را حل کند؛ از راه این راهبرد؛ و انتظار داریم به این نتیجه برسد.

پرکردن این چهار جای خالی، شرط ورود به بحث قابلیت است. بعد از آن می‌توانید سراغ انتخاب قابلیت بروید، و پیش از آن هر انتخابی زود است.

چه چیزی به فرایند طراحی اضافه می‌کند

سودش را می‌توان در چند جملهٔ کوتاه گفت. قابلیت‌هایی می‌سازید که برای کاربر اهمیت دارند.

محصول را در بافتش می‌بینید، نه به‌عنوان جمعِ قابلیت‌ها و تلاش‌های طراحی. پس مطمئن‌تر می‌شوید که مسئله‌ای معنادار را هدف گرفته‌اید.

ریسک شکست محصول هم کمتر می‌شود. هیچ روشی این ریسک را صفر نمی‌کند و ادعایش هم درست نیست.

یک اثر کم‌دیده‌تر، تغییر شکل پرسش‌های طراح است. طراحی که از نتیجه شروع می‌کند، پرسش‌های دیگری از ذی‌نفعان می‌پرسد.

مهم‌ترین اثرش اما اجازهٔ «نه» گفتن است. وقتی قابلیتی خواسته می‌شود که راه‌حل اصلی را پشتیبانی نمی‌کند، طراح جایی برای ایستادن دارد.

نتیجهٔ جمعِ اینها محصول لاغرتر و اثرگذارتر است. کمینهٔ محصول پذیرفتنی و لین یو‌ایکس همین لاغری را از دو زاویهٔ دیگر می‌بینند.

اولویت هم روشن است: راه‌حل باید مسئله را حل کند. قابلیتی که راه‌حل را تقویت کند خوب است، ولی اگر مسئله حل نشود، بقیهٔ محصول تزئین است.

طراحی تعامل و طراحی دیداری می‌توانند چیز زیبایی بسازند. آن زیبایی روی محصولی که سودمند نیست، هدر می‌رود.

یک انتقاد جدی هم به این اصطلاح وارد است. برای بعضی‌ها تفکر محصول فقط واژهٔ تازه‌ای است و چیزی بیش از تفکر طراحی نمی‌آورد.

حتی اگر این انتقاد درست باشد، اصطلاح یک کار دیگر هم می‌کند: ابزار متقاعدسازی است. اگر «تفکر محصول» برای مدیر یا کارفرمای شما ملموس‌تر است، همان را به کار ببرید.

جهت استنتاج: قابلیت پایین‌دستِ نتیجه است

این بخش افزودهٔ من است، چون «اول محصول، بعد قابلیت» در منابع رایج یک توصیهٔ ترتیبی است و من فکر می‌کنم تفاوت جای دیگری است: در جهت استنتاج.

به همان دو تیم برگردیم. هر دو یک فهرست از قابلیت‌های ممکن روی میز دارند و فهرست‌ها یکی است.

تیم اول از قابلیت شروع می‌کند. پرسش اولش این است: «این را بسازیم یا نه؟»

تیم دوم از نتیجه شروع می‌کند. پرسش اولش این است: «چه چیزی باید عوض شود؟»

تفاوت این دو در پاسخ نیست. در مجموعهٔ پاسخ‌های مجاز است.

برای تیم اول، هر قابلیتی که کسی بخواهد یک پاسخ مجاز است. رد کردنش به سلیقه و قدرت بستگی پیدا می‌کند.

برای تیم دوم، قابلیت فقط وقتی مجاز است که از نتیجه بیرون بیاید. رد کردنش استدلال دارد، نه مخالف.

پس «نه» در تیم دوم ارزان‌تر است. «نه» آنجا خصلت یک آدم نیست، خروجی یک استنتاج است.

هر پرسشِ پاسخ‌داده‌شده در این زنجیره، مجموعهٔ پاسخ‌های مجاز را کوچک‌تر می‌کند. نتیجه بخشی از فهرست را حذف می‌کند، مخاطب بخش دیگری را، و راهبرد بخش سوم را.

سودِ زنجیره در حذف است، نه در افزودن. زنجیره‌ای که هیچ قابلیتی را از فهرست بیرون نمی‌کند، فقط یک سند تشریفاتی است.

یک آزمون کوتاه هم دارد. یک قابلیت را از فهرست بردارید و رو به بالا حرکت کنید: راهبرد، مسئله، نتیجه.

اگر به نتیجه رسیدید، آن قابلیت استنتاج دارد. اگر نرسیدید، آن قابلیت توجیه دارد و استنتاج ندارد.

فرق توجیه و استنتاج در زمان است. استنتاج پیش از تصمیم شکل می‌گیرد و توجیه بعد از تصمیم نوشته می‌شود.

در سند نهایی این دو شبیه هم به نظر می‌رسند، چون هر دو یک زنجیرهٔ کامل نشان می‌دهند. تفاوتشان را فقط از ترتیب زمانی جلسه‌ها می‌توان فهمید.

اینجا محل اتصال این بحث به اولویت‌بندی ویژگی‌ها است. اولویت‌بندی، مرتب‌کردن فهرستِ مجاز است؛ تفکر محصول تعیین می‌کند چه چیزی به آن فهرست راه پیدا کند.

سه جایی که تفکر محصول شکست می‌خورد

این بخش افزودهٔ من است، چون فهرست سودهای یک روش، حالت‌های خرابی‌اش را نشان نمی‌دهد و در عمل همین حالت‌ها بیشتر دیده می‌شوند.

هر سه شکست زیر، سندی کامل و بی‌نقص تولید می‌کنند. به همین دلیل هم سخت پیدا می‌شوند.

• - ۱. زنجیرهٔ معکوس: قابلیت اول انتخاب می‌شود و نتیجه بعد از آن برایش نوشته می‌شود. نشانه‌اش این است که نتیجه دقیقاً به اندازهٔ همان قابلیت است، نه بزرگ‌تر.
• - ۲. نتیجهٔ غیرقابل‌ابطال: «تجربهٔ بهتر» یا «رضایت بیشتر» هیچ قابلیتی را رد نمی‌کند. نتیجه‌ای که هیچ گزینه‌ای را حذف نکند، یک جای خالیِ پرشده است. سنجه‌های کلیدی عملکرد برای همین به نتیجه چسبانده می‌شوند.
• - ۳. مسئلهٔ واقعیِ بی‌هزینه: کاربر مسئله را در مصاحبه تأیید می‌کند، ولی برای حلش هیچ کاری نکرده است. مسئله‌ای که کسی برای حلش پول یا وقت نمی‌دهد، از نظر محصول مسئله نیست.

مورد سوم پرتکرارترین است، چون تأیید گرفتن از کاربر آسان است. کشف پیوسته راه مهارش را نشان می‌دهد: به‌جای پرسیدن، دنبال رفتاری بگردید که کاربر همین حالا برای حل آن مسئله انجام می‌دهد.

هر سه شکست یک نشانهٔ مشترک دارند. زنجیره روی کاغذ کامل است و هیچ قابلیتی را رد نمی‌کند.

پس یک وارسیِ ساده کافی است. از سند تعریف محصول بپرسید کدام سه قابلیتِ خواسته‌شده را رد می‌کند. اگر پاسخی نداشت، سند کار نمی‌کند.

در بافت فارسی

چهار مسئله در تیم‌های فارسی‌زبان بیشتر از بقیه سراغم آمده‌اند.

۱. قرارداد، جهت استنتاج را قفل می‌کند. بخش بزرگی از کار تیم‌های اینجا پروژهٔ سفارشی است. مشتری قابلیت را نام می‌برد و قرارداد همان نام‌ها را فهرست می‌کند.

از لحظهٔ امضا، قابلیت دیگر خروجی استنتاج نیست؛ ورودی تعهد است. طراح هرچه هم درست فکر کند، جای خالی نتیجه را نمی‌تواند بالای سر آن فهرست بگذارد.

یک کار کوچک اما اثر دارد: همان چهار خط تعریف محصول را به پیوست قرارداد اضافه کنید. آن‌وقت تغییر قابلیت در میانهٔ کار، بحثی درون همان سند است و نه دعوا بر سر دامنهٔ کار.

۲. رقیب خارجی جای مسئله را می‌گیرد. «چون فلان اپ جهانی این را دارد» در جلسه‌های اینجا استدلال شمرده می‌شود. این جمله اما یک نتیجه نیست، یک ارجاع است.

آن محصول جهانی مسئله‌ای را در بافت دیگری حل کرده بود: زیرساخت پرداخت دیگری، شبکهٔ حمل دیگری، و عادت خرید دیگری. قابلیتش را می‌توانید ببینید، ولی مسئله‌اش را نمی‌بینید.

پس ارجاع را نگه دارید و جایش را عوض کنید. رقیب در بخش راهبرد مفید است، نه در بخش مسئله؛ بازارگرایی همین تفکیک را از سمت بازار توضیح می‌دهد.

۳. نتیجه اغلب اندازه‌پذیر نیست. بستن قابلیت به نتیجه به سنجه نیاز دارد، و سنجه به رخدادنگاری منظم. در بسیاری از تیم‌های اینجا این نگاری ناقص است یا با ابزار خودساخته انجام می‌شود.

پیامدش این است که بحث نتیجه به سلیقه برمی‌گردد. وقتی عددی نباشد، بلندترین صدا در جلسه برنده می‌شود.

راه عملی‌اش پذیرفتن یک سنجهٔ ناقص است. یک عدد صریح و اعلام‌شده، حتی با خطای شناخته‌شده، از هیچ عددی بهتر است؛ سنجه‌های تجربهٔ کاربری گزینه‌های ساده‌اش را فهرست می‌کند.

۴. «نه» گفتن هزینهٔ سازمانی دارد. در بسیاری از تیم‌ها نقش مدیر محصول تازه است و قابلیت از سمت مدیرعامل یا واحد فروش می‌رسد. طراحی که آن را رد کند، به‌عنوان مخالف شناخته می‌شود.

راه گریزش این است که «نه» را از دوش خودتان بردارید. رد کردن را به همان سند تعریف محصول بسپارید، سندی که مدیر خودش تأییدش کرده است.

آن‌وقت جملهٔ شما عوض می‌شود. «این قابلیت به نتیجه‌ای که خودمان نوشتیم نمی‌رسد» جای «من موافق نیستم» را می‌گیرد.

هیچ‌یک از این چهار مورد را با عدد نمی‌گویم، چون سنجش منتشرشده‌ای از این اثرها در بازار فارسی‌زبان ندیده‌ام. اینها مشاهده و استدلال‌اند، و راه آزمودنشان همان وارسی پایان بخش قبل است.

جمع‌بندی

• - تفکر محصول: فرایندهای ذهنی و روش‌هایی که طراح در برخورد با مسئله و حل آن به کار می‌گیرد
• - ترتیبش: اول محصول، بعد قابلیت · دلیل خرید کاربر حل یک مسئلهٔ واقعی است
• - ساختارش سه طبقه دارد: کاربر · کاری که باید انجام شود · خروجی‌ها
• - شش پرسش: مسئله · مخاطب · چشم‌انداز · راهبرد · هدف · قابلیت
• - قالب چهارخطی: این محصول برای چه کسی · کدام مسئله · از چه راهی · با چه نتیجه‌ای
• - سودش: قابلیت مهم · دیدن محصول در بافت · ریسک کمتر · و اجازهٔ «نه» گفتن
• - جهت استنتاج تفاوت اصلی است: مجموعهٔ پاسخ‌های مجاز عوض می‌شود، نه خودِ پاسخ
• - آزمون: از یک قابلیت رو به بالا بروید · اگر به نتیجه نرسید، توجیه دارد و استنتاج ندارد
• - سه شکست: زنجیرهٔ معکوس · نتیجهٔ غیرقابل‌ابطال · مسئلهٔ واقعیِ بی‌هزینه
• - وارسی: سند تعریف محصول باید بتواند سه قابلیتِ خواسته‌شده را نام ببرد و رد کند
• - در فارسی: قرارداد جهت را قفل می‌کند · رقیب خارجی جای مسئله را می‌گیرد · نتیجه اندازه‌پذیر نیست · «نه» هزینهٔ سازمانی دارد