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

مدل مفهومی (Conceptual Model) چیست؟

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

یک آسانسور را در نظر بگیرید. دکمهٔ بالا یا پایین را می‌زنید، سوار می‌شوید، طبقه را انتخاب می‌کنید. این را کسی به شما یاد نداده؛ ساختمان‌ها سال‌هاست همین‌طور کار می‌کنند.

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

این مقاله دربارهٔ همین چند ثانیه است.

تعریف و سه لایه

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

منبع سه لایه را از هم جدا می‌کند:

• - مدل ذهنی: فرایندها و برداشت‌های درونی خودِ کاربر.
• - مدل بازنمایی‌شده: آنچه طراح از کارکرد سامانه به نمایش می‌گذارد.
• - تصویر سیستم: بازنمایی فیزیکی یا دیجیتالِ واقعی، شامل خود رابط.

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

اجزای یک مدل مفهومی

• - موجودیت‌ها — آدم‌ها، جاها، چیزها.
• - روابط — پیوندها و قواعد میان آن‌ها.
• - محدودیت‌ها — مرزها و آنچه ممکن نیست.

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

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

تلهٔ استعاره

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

استعاره وقتی خطرناک می‌شود که شیء قرضی محدودیتی داشته باشد که چیز دیجیتال ندارد — یا برعکس. آن‌وقت کاربر چیزی را باور می‌کند که واقعیت ندارد، و خودِ استعاره به منبع خطا تبدیل می‌شود:

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

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

با چه چیزهایی اشتباه گرفته می‌شود

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

درس واقعی آسانسور

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

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

اما هم‌زمان سه چیز در مدل کاربر شکسته:

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

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

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

وقتی مدل مفهومی وارداتی است

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

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

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

جمع‌بندی

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