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

به‌چالش‌کشیدن پیش‌فرض‌ها چیست؟

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

گام اول این روش این است: «هر پیش‌فرضی که دارید بنویسید.» و گام دوم: «هرکدام را برگردانید.»

مسئله این است که گام اول سخت‌ترین بخش کار است و گام دوم آسان‌ترین. و به‌نظرم راه‌حلش این است که ترتیبشان را برعکس کنید — چون خودِ برگرداندن، آشکارسازِ پیش‌فرض است.

تعریف

به‌چالش‌کشیدن پیش‌فرض‌ها روشی برای ایده‌پردازی است که به تیم کمک می‌کند از تفکر متعارف و باورهای نادرست رها شود: پیش‌فرض‌هایی که تصمیم‌های طراحی روی آن‌ها سوارند را شناسایی و به‌پرسش می‌کشید، و بعد برشان می‌گردانید یا حذفشان می‌کنید تا راه‌حل‌های تازه بیرون بیاید.

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

و نکتهٔ مهمش: همهٔ پیش‌فرض‌ها «بد» نیستند؛ فقط اعتبارشان باید آزمون شود — نه اینکه با ایمان کورکورانه به آن‌ها چنگ بزنیم. چون بسیاری از محدودیت‌هایی که از آن‌ها پیروی می‌کنیم واقعی نیستند؛ عادت‌های ذهنی‌اند.

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

پنج گام

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

توصیه‌های عملی و فایده‌ها

منبع شش توصیه می‌دهد: بدانید بعضی محدودیت‌ها به‌دلیلی واقعی‌اند — الزام‌های حقوقی و مقرراتی و ایمنی؛ و در تردید بپرسید «چه کسی می‌گوید این باید درست باشد؟» · از تنوع تیم استفاده کنید (توسعه، محصول، پشتیبانی، بازاریابی — هر کارکرد پیش‌فرض‌های متفاوتی دارد) · زمان‌بندی کنید (۱۵ دقیقه فهرست، ۱۵ دقیقه چالش، ۲۰ دقیقه ایده) · پرسش‌های «احمقانه» را تشویق کنید و «مدافع امر بدیهی» باشید · همه‌چیز را بینایی کنید · و پیگیری با اقدام. و تأکید می‌کند که این روش دارویی برای تیم‌های گیرکرده نیست؛ باید مرتب به‌کار رود.

و پنج فایده‌اش: ایده‌های نوآورانه‌تر · هم‌راستایی بهتر با کاربر (چون «شما کاربرتان نیستید») · کاهش خطر با آشکار‌کردن زودهنگام پیش‌فرض‌های نادرست · خلاقیت بیشتر میان رشته‌ها · و آگاهی عمیق‌تر تیم و دلبستگی کمتر به تصمیم‌های موروثی.

ترتیب گام یک و دو را برعکس کنید

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

اما گام دوم راهی می‌دهد که گام اول ندارد. چون وقتی یک تصمیم را برمی‌گردانید، مقاومتی که حس می‌کنید خودِ پیش‌فرض است. «اگر نوار ناوبری نداشتیم چه؟» — و آن حس فوریِ «خب معلوم است که باید داشته باشیم» دقیقاً همان چیزی است که دنبالش بودید. پیش‌فرض خودش را در لحظهٔ نقض‌شدن نشان می‌دهد.

پس روش عملی‌تر این است:

• - فهرست تصمیم‌ها را بنویسید، نه فهرست پیش‌فرض‌ها. تصمیم‌ها مرئی‌اند: در طرح هستند، در سند هستند، قابل شمردن‌اند.
• - هرکدام را برگردانید و به احساس خودتان گوش بدهید. جایی که «این مسخره است» یا «این ممکن نیست» بیرون می‌آید، یک پیش‌فرض ثبت‌نشده وجود دارد.
• - و همان جمله را بنویسید — نه ایدهٔ برگردانده‌شده را، بلکه دلیلِ مقاومت را. آن جمله، پیش‌فرض شماست، و اکنون نوشته شده.

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

محدودیت واقعی یا عادت؟ آزمونش دو جزء دارد

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

و آزمونی که به‌نظرم کار می‌کند دو جزء دارد:

• - یک نامِ اجراکننده. کی این را الزام می‌کند؟ یک نهاد ناظر، یک شبکهٔ پرداخت، بازبینی فروشگاه اپلیکیشن، یک بند قرارداد. اگر نمی‌توانید نام ببرید، محدودیت نیست.
• - و یک پیامد مشخص برای نقض. اگر این کار را بکنیم چه می‌شود؟ «جریمه»، «رد‌شدن در بازبینی»، «قطع سرویس» پیامدند. «خوب نیست» پیامد نیست.

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

و راه‌حلش ساده و تقریباً بی‌هزینه است: هر محدودیت را با تاریخ بنویسید. «این محدودیت از فروردین ۱۴۰۳ است، منبعش قرارداد با فلان، پیامد نقضش فلان.» چون محدودیت‌ها تاریخ انقضا دارند و هیچ‌کس بازبینی‌شان را در تقویم نمی‌گذارد.

حکایت کامیون، تصویر گمراه‌کننده‌ای از این روش می‌دهد

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

آن حکایت به این دلیل تعریف می‌شود که دلپذیر است: می‌گوید جواب ساده بود و متخصصان نادان بودند. اما به‌چالش‌کشیدن پیش‌فرض در عمل معمولاً این‌طور نیست:

• - بیشتر برگرداندن‌ها به هیچ‌چیز نمی‌رسند. «اگر ورود لازم نبود چه؟» در بیشتر محصول‌ها جواب «آن‌وقت نمی‌شود» است، و این جواب درستی است.
• - و ایدهٔ برگردانده‌شده اغلب اول بدتر است، بعد بهتر. بی چند دور کار، شبیه یک ایدهٔ بد به‌نظر می‌رسد — و در جلسه‌ای که انتظار «لحظهٔ لاستیک‌ها» را دارد، همان‌جا کشته می‌شود.

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

گام پنجم را باید به یک دفتر ماندگار تبدیل کرد

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

و شکل مفیدش یک دفتر پیش‌فرض‌های ماندگار است با سه ستون:

• - پیش‌فرض — به‌صورت یک جملهٔ کامل.
• - چه شد وقتی به‌پرسشش کشیدیم — نامعتبر بود، معتبر بود، یا نتیجه‌ای نگرفتیم.
• - و تاریخ.

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

محافظی که منبع نمی‌گذارد

این بخش هم افزودهٔ مترجم است، و به‌نظرم لازم است چون این روش یک شکل سوءاستفاده دارد که خیلی رایج است: «به‌چالش‌کشیدن پیش‌فرض» می‌تواند علیه یافتهٔ پژوهش به‌کار رود.

یعنی کسی که یافته‌ای را نمی‌پسندد، آن را «یک پیش‌فرض» می‌نامد و همان‌جا از دستور کار خارجش می‌کند — با کلمات خودِ این روش. و تفکیکش روشن است:

• - پیش‌فرض، باوری بی‌منبع است. برای همین باید به‌پرسش کشیده شود.
• - یافته منبع دارد. می‌شود روشش را نقد کرد — نمونه کم بود، پرسش سوگیرانه بود، بافت متفاوت بود — اما نمی‌شود با تغییر نامش به «پیش‌فرض» کنارش گذاشت.

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

در بافت فارسی: پرسودترین برگرداندن

این بخش هم افزودهٔ مترجم است و سه نکته دارد.

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

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

سه: و پرسودترین برگرداندن در بازار ما هیچ فرضی نیست — توصیف یک بخش واقعی از بازار است. این چهار پرسش را برگردانید:

• - «اگر کاربر گوشی هوشمند نداشت چه؟»
• - «اگر اینترنت پایدار نداشت چه؟»
• - «اگر کارت بانکی مناسب این درگاه نداشت چه؟»
• - «اگر این کار را به‌جای شخص دیگری انجام می‌داد چه؟»

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

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

جمع‌بندی

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