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

طراحی زمینه‌ای (Contextual Design) چیست؟

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

طراحی زمینه‌ای (Contextual Design) یک روش‌شناسی کامل طراحی کاربرمحور است که از یک ادعای ساده شروع می‌کند: برای اینکه بفهمید یک سیستم باید چه شکلی باشد، باید ببینید آدم‌ها کارشان را واقعاً چطور انجام می‌دهند — در محیط خودشان، با ابزارهای خودشان، با همهٔ میان‌برها و دور زدن‌هایی که هیچ‌وقت در جلسه تعریف نمی‌کنند.

این روش را Karen Holtzblatt (روان‌شناس) و Hugh Beyer (توسعه‌دهنده) از اواخر دههٔ ۱۹۸۰ در شرکت Digital Equipment Corporation ساختند و در کتاب ۱۹۹۷ خودشان، Contextual Design: Defining Customer-Centered Systems، به‌شکل کامل صورت‌بندی کردند.

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

پنج مدل کاری

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

• - ۱. مدل جریان (Flow): چه کسی با چه کسی حرف می‌زند تا کار پیش برود. نقش‌ها، تحویل‌ها، و آن کانال‌های غیررسمی‌ای که در چارت سازمانی نیستند ولی کار واقعاً از آن‌ها می‌گذرد.
• - ۲. مدل توالی (Sequence): گام‌های یک وظیفه به‌ترتیب، همراه با قصدِ پشت هر گام و نقطه‌ای که کار خراب می‌شود.
• - ۳. مدل مصنوع (Artifact): چیزهایی که آدم‌ها برای کنار آمدن با کار ساخته‌اند — یک فایل اکسل کناری، یک برگهٔ چاپ‌شدهٔ پر از یادداشت، یک دفترچه.
• - ۴. مدل فرهنگی (Cultural): فشارها و سیاست‌هایی که کار را محدود می‌کنند. چه چیزی مجاز است، چه انتظاری هست، و رضایت چه کسی باید حفظ شود.
• - ۵. مدل فیزیکی (Physical): فضایی که کار در آن اتفاق می‌افتد. نمایشگر کجاست، چه چیزی دور از دسترس است، چه کاری ایستاده انجام می‌شود.

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

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

هفت گام، از میدان تا نمونهٔ کاغذی

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

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

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

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

طراحی محیط کاربر: نقشهٔ ساختمان سیستم

این بخش، کم‌شناخته‌ترین و به‌نظر من کاربردی‌ترین سهم این روش است. «طراحی محیط کاربر» (User Environment Design) یک سند ساختاری است که سیستم را مثل نقشهٔ یک ساختمان می‌کشد: چه فضاهایی وجود دارد، هر فضا برای چه کاری است، در هر کدام چه کارهایی ممکن است، و از هر فضا به کجا می‌شود رفت — بدون اینکه هنوز هیچ تصمیمی دربارهٔ ظاهر رابط گرفته شده باشد.

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

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

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

نسخهٔ کامل و نسخهٔ سریع

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

خودِ بایر و هولتزبلات این را پذیرفتند و در ۲۰۰۵ نسخهٔ کوتاه‌شده‌ای به‌نام Rapid Contextual Design منتشر کردند. اینکه سازندگان یک روش خودشان نسخهٔ سبکش را بنویسند، اعتراف منصفانه‌ای است به اینکه نسخهٔ کامل از توان بیشتر پروژه‌ها بیرون است.

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

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

اشتباه‌هایی که روش را بی‌اثر می‌کنند

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

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

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

طراحی زمینه‌ای در تیم‌های فارسی‌زبان

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

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

جمع‌بندی

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

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

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