سپنتا پویا — طراح محصول

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

پیش‌فرض‌ها (Assumptions) در طراحی چیست؟

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

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

و بعد توصیه می‌کند پیش‌فرض‌ها را شناسایی و آزمون کنید — بی‌آنکه برای شناسایی روشی بدهد. حال آنکه آزمودنِ پیش‌فرضی که دیده‌اید کار سختی نیست؛ کار سخت دیدنش است.

تعریف

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

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

فایده‌هایشان

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

خطرهایشان

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

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

ده دستهٔ پیش‌فرض

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

روش دیدنِ پیش‌فرض نامرئی

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

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

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

این بخش هم افزودهٔ مترجم است. در فهرست فایده‌ها یک جابه‌جایی هست که ارزش تصحیح دارد: «تولید فرضیه» و «مدیریت خطر» فایدهٔ پیش‌فرض نیستند؛ فایدهٔ صریح‌کردن پیش‌فرض‌اند.

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

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

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

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

نمی‌شود همه را آزمود، پس باید تفکیک کرد

تفکیک پیش‌فرض‌ها بر پایهٔ وزن و هزینهٔ بررسی
نمودار از سپنتا پویا برای این ترجمه (sepantapouya.com)

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

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

  • - وزن زیاد، بررسی ارزان → همین حالا بررسی کنید. بی بحث. یک تماس، پنج تماس پشتیبانی، یک پرس‌و‌جو از داده. این خانه معمولاً خالی می‌ماند فقط به‌این‌دلیل که کسی فهرست را ننوشته.
  • - وزن زیاد، بررسی گران → این‌ها را با نمونهٔ اولیه بشکنید. اگر نمی‌شود ارزان آزمود، معماری را طوری بچینید که بعداً عوض‌کردنش ارزان باشد. این تنها راه معقول است.
  • - وزن کم، بررسی ارزان → در مسیر بررسی کنید. بدون جلسه.
  • - وزن کم، بررسی گران → بنویسید و رهایش کنید. نوشتنش کافی است؛ اگر روزی چیزی بر آن سوار شد، خانه‌اش عوض می‌شود.

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

بعضی پیش‌فرض‌ها در ابزار شما زندگی می‌کنند، نه در ذهنتان

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

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

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

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

پیش‌فرض‌های سیستماتیک تیم‌های ایرانی دربارهٔ کاربر
نمودار از سپنتا پویا برای این ترجمه (sepantapouya.com)

این بخش هم افزودهٔ مترجم است. برخی پیش‌فرض‌ها فردی نیستند؛ کل یک بازار مشترکاً دارندشان — و همان‌ها آزمون نمی‌شوند، چون همه‌جا هستند:

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

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

جمع‌بندی

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

منبع

این نوشته «بازنویسی آزاد» است از مطلب What are Assumptions? در وب‌سایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF؛ بدون نام نویسندهٔ مشخص). مفاهیم پایه — تعریف پیش‌فرض به‌عنوان باور طراح دربارهٔ کاربر و بافت استفاده و هدف‌های کاربر و منشأش در تجربهٔ گذشته و دانش صنعت و شهود، ویژگی درست‌دانستن بی شاهد مشخص و نکتهٔ نزدیک‌بودن پیش‌فرض به ذهن طراح، خطر گرفتنش به‌جای واقعیت و اثرش بر کل فرایند از تعریف مسئله تا ساخت راه‌حل، پنج فایده شامل کارآمدی و پرهیز از فلج تحلیلی و نقش نگه‌دارندهٔ موقت و خلاقیت و تولید فرضیه و مدیریت خطر و نقش در فرایند تکرارشونده و هم‌راستایی تیم با شرط بیان صریح، شش خطر شامل طراحی برای کاربر اشتباه و ساخت ویژگی بی‌ربط و هدر زمان و منابع و ازدست‌دادن بینش و سختی تکرار و آسیب به ادراک برند، مثال فرض ترجیح رابط کمینه بر پایهٔ روند صنعت، ده دستهٔ پیش‌فرض شامل نیاز و هدف و رفتار کاربر و بافت استفاده و ترجیح و آشنایی و فرهنگ و محدودیت فناوری و بازخورد و دسترس‌پذیری، و ضرورت آزمون پیش‌فرض‌ها با پژوهش و آزمون کاربر و روش‌های کمی و کیفی — از این منبع گرفته شده. منبع به Don Norman و Alan Dix و Frank Spillers و Kendra Shimmell و William Hudson ارجاع می‌دهد. متن فارسی، ساختار بخش‌ها و همهٔ تحلیل‌ها کاملاً مستقل نوشته شده‌اند.

متن مقالهٔ اصلی تحت هیچ لایسنس بازی منتشر نشده است؛ به همین دلیل اینجا ترجمهٔ کلمه‌به‌کلمه ارائه نشده و متن کامل انگلیسی (به‌همراه همهٔ تصاویر) در لینک زیر در دسترس است.

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

تصاویر: هر سه نمودار این صفحه طراحی مستقل مترجم است. تصویر نسخهٔ اصلی با لایسنس CC BY-SA 4.0 بنیاد طراحی تعامل منتشر شده؛ اینجا بازتولید نشده و در مطلب اصلی قابل مشاهده است.

مشاهدهٔ مقالهٔ اصلی
سپنتا پویا

مترجم: سپنتا پویا

طراح ارشد محصول. مقالات تخصصی UI/UX را با حفظ ساختار و لحن نسخهٔ اصلی به فارسی برمی‌گردانم.

دربارهٔ من

در این مقاله

  • - تعریف
  • - فایده و خطر
  • - ده دسته
  • - دیدن پیش‌فرض
  • - پیش‌فرض نوشته‌شده
  • - تفکیک و اولویت
  • - پیش‌فرض در ابزار
  • - در بافت فارسی

برچسب‌ها

  • پیش‌فرض
  • پژوهش کاربر
  • سوگیری
  • UX
  • ترجمه