انتزاعی سازی در طراحی مفهومی

منظور از انتزاعی‌سازی (Abstraction) چیست؟

اگر کلمه‌ی انتزاعی را در وبسایت‌ها یا کتاب‌ها جستجو کنید با مجموعه‌ای از توضیحات پیچیده و غیرقابل فهم روبه‌رو شوید که به موضوع درس‌مان کمکی نمی‌کنند. در چهارچوب بحث طراحی مفهومی، منظور از انتزاعی سازی این است که از صورت مسأله‌ی طراحی یک چکیده‌ی مفید استخراج کنیم که روی کلیّات تمرکز دارد و شامل جزئیات نمی‌شود. این صورت مسأله‌ی کلّی باعث می‌شود که طراحان با جزئیات و موانع کمتری روبه‌رو شوند و به راهکارهای بهتری برسند. برای این که کاملاً مفهوم انتزاعی سازی را درک کنید از یک مثال استفاده می‌کنیم.

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

(صورت مسأله ی اول) کارگر اول روی میز X (میز بلندتر) و کارگر دوم روی میز Y (میز کوتاه‌تر) کار می‌کند. باید ابزاری طراحی شود که قطعه کار (قطعه‌ی A) را از روی میز X بلند کند و طی یک حرکت مستقیم روی میز Y قرار دهد. کارگر دوم حدود ۲۰ ثانیه روی قطعه کار می‌کند، سپس ابزار باید مجدداً قطعه کار را بلند کرده و روی میز X قرار دهد.

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

با حذف پاره‌ای از جزئیات در صورت مسأله‌ی اول می‌توانیم به یک چکیده‌ی انتزاعی‌تر دست پیدا کنیم. به این صورت مسأله توجه کنید:

(صورت مسأله ی دوم) باید ابزاری طراحی شود که قطعه کار از روی میز X بلند کند و روی میز Y قرار دهد، سپس بعد از چند ثانیه دوباره آن را روی میز X قرار دهد تا عملیات پایانی انجام شود.

در صورت مسأله‌ی جدید اولاً به بازه‌ی زمانی ۲۰ ثانیه اشاره نشده است، چون تأثیری در کشف راهکار ندارد و دوماً “حرکت مستقیم قطعه کار” حذف شده است تا راهکارهای انعطاف‌پذیرتری در اختیارمان قرار بگیرد. برای پاسخ به صورت مسأله‌ی جدید، علاوه بر این که راهکار قبلی به ذهن می‌رسد، می‌توانیم از طرحی شبیه زیر استفاده کنیم که در آن قطعه از روی میز X برداشته می‌شود و طی حرکت دورانی (که مستقیم نیست) روی میز Y قرار می‌گیرد و نهایتاً به میز X باز می‌گردد.

هنوز هم می‌توانیم صورت مسأله را انتزاعی‌تر بنویسیم:

(صورت مسأله ی سوم) ابزاری باید طراحی شود که قطعه کار A را بین میزهای X و Y جابه جا کند تا انجام عملیات توسط کارگران تسهیل شود.

در این صورت مسأله “برداشتن قطعه کار” هم حذف شده است و استفاده از ابزارآلاتی مثل نوار نقاله، ساده‌تر به ذهن متبادر می‌شود.

به عنوان آخرین نمونه، موضوع میزهای X و Y را حذف می‌کنیم تا به یک صورت مسأله‌ی انتزاعی‌تر برسیم:

(صورت مسأله ی چهارم) به راهکاری نیاز است تا قطعه کار A در ارتفاع مناسب برای کارگران قرار بگیرد.

برای این صورت مسأله می‌توانیم به جای دو میز از یک میز با ارتفاع قابل تنظیم استفاده کنیم (راهکار چهارم)؛ همچنین می‌توانیم به سادگی ارتفاع صندلی کارگر دوم را بلندتر در نظر بگیریم تا دسترسی بهتری به قطعه کار داشته باشد.

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

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

تبدیل فهرست الزامات به یک صورت مسأله‌ی انتزاعی

همانطور که گفتیم اکثر فرایندهای طراحی (با اقتباس از فرایند عمومی حل مسأله) با تعریف مسأله شروع می‌شوند و معمولاً فرمت استانداردی را برای تشریح مسأله پیشنهاد می‌کنند. در فرایند طراحی پال و بیتز، این فرمت همان فهرست الزامات یا Requirements List است که در فاز اول بررسی کردیم.

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

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

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

قدم اول: حذف ترجیحات شخصی

منظورمان از ترجیحات شخصی، آن دسته از مفاد فهرست الزامات است که جنبه‌ی عمومی ندارند و صرفاً بنا به سلیقه‌ی افراد در فهرست الزامات (یا تعریف اولیه‌ی مسأله) قرار گرفته‌اند، مثلاً در فهرست الزامات یک تلفن همراه، مواردی مثل قرارگیری تمام دکمه‌ها در سمت راست یا استفاده از نسبت ۱۰ به ۴ برای عرض و طول می‌توانند ترجیحات شخصی باشند، یا در مثال جابه‌جایی قطعه A (بخش قبلی همین درس)، مستقیم بودن حرکت قطعه کار بین دو میز یک ترجیح شخصی است، مگر این که بنا به یک محدودیت قابل توجه بوده باشد (مثل کم بودن فضای عرضی یا ضوابط ایمنی).

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

قدم دوم: حذف الزاماتی که مستقیماً روی عملکردهای اصلی یا محدودیت‌های اصلی تأثیرگذار نیستند.

در انتزاعی سازی تمرکزمان روی موضوعاتی است که مستقیماً روی عملکردهای کلیدی محصول مؤثر هستند، مثلاً در مثال بخش قبل، عملکرد اصلی ابزار این بود که قطعه کار را در اختیار کارگران قرار دهد و موضوعاتی مثل نیروی محرکه‌ (که مثلاً برقی، دستی یا گازوئیلی باشد) یا روش کنترل دستگاه یا ارتفاع مناسب برای فعالیت کارگران، ارتباط چندانی با عملکرد اصلی ندارند و لذا در راستای انتزاعی‌سازی حذف می‌شوند.

قدم سوم: تبدیل اطلاعات کمی به کیفی و توضیحات ضروری.

برای انتزاعی‌تر شدن مسأله‌ی طراحی بهتر است حتی‌المقدور از اعداد فاصله بگیریم و از توصیفات کیفی استفاده کنیم، مثلاً اگر قرار است که محصول در دو اندازه‌ی ۶ در ۱۲ سانتی متر و ۸ در ۱۶ سانتی‌‌متر طراحی شود، بهتر است بنویسیم که محصول در دو اندازه‌ی کوچک و متوسط طراحی می‌شود، یا اگر تصمیم بر این است که بازوی روباتیک دستگاه با سرعت نیم متر در دقیقه حرکت کند، بهتر است بنویسیم که با سرعت یکنواخت و آهسته حرکت می‌کند.

قدم چهارم: عمومی‌سازی هدفمند نتایج به دست آمده از مراحل قبلی.

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

قدم پنجم: نوشتن صورت مسأله‌ی طراحی به نحوی که بیانگر راهکارهای دقیقی نباشد.

در مراحل قبلی، بخشی از فهرست الزامات حذف شده است و بعضی نکات ترکیب شده‌اند. در قدم پنجم باید نتیجه‌ی این اقدامات را در قالب یک صورت مسأله‌ی توصیفی بازنویسی کنیم. این صورت مسأله باید به صورت Solution Neutral باشد، یعنی راهکار مشخصی ارائه ندهد و دست طراحان را برای پیدا کردن راهکارهای خلاقانه باز بگذارد. برای این که درک بهتری از این مسأله داشته باشید، مطالعه‌ی نمونه‌های زیر مفید است (این موارد از کتاب پال و بیتز الگوبرداری شده‌اند).

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

اگر قرار است ابزاری برای قرار گرفتن یک چرخ دنده روی شفت طراحی کنیم، عبارت “طراحی شفت پله‌دار برای قرارگیری چرخ‌دنده” مناسب نیست چون دقیقاً به راهکار مشخصی ارائه می‌کند. بهتر است بنویسیم “طراحی ابزاری که چرخ‌دنده را روی شفت مقید می‌کند”.

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

در مورد مثالی که در مورد جابه‌جایی قطعه‌ی A در بخش اول درس طرح کردیم، این صورت مسأله می‌تواند مناسب باشد: “پیدا کردن بهترین راهکار برای این که قطعه کار در شرایط ایمن و زمان مناسب در اختیار کارگران واحد ساخت قرار بگیرد”.