مهندسی زمینه؛ مهارتی که طراحان محصول به آن نیاز دارند.
دو نفر میتوانند از یک ابزار هوش مصنوعی بخواهند «یک صفحهٔ ثبتنام طراحی کن» و دو خروجی کاملاً متفاوت بگیرند. تفاوت همیشه از توانایی ابزار نیست. اغلب یکی فقط شکل نهایی را خواسته و دیگری توضیح داده کاربر چه کسی است، چرا ثبتنام میکند، چه نگرانیای دارد، محصول چه محدودیتی دارد و موفقیت این مرحله چگونه سنجیده میشود.
من مدتها این تفاوت را فقط «پرامپت بهتر» میدیدم. اما هرچه بیشتر با ابزارهای AI در طراحی کار کردم، متوجه شدم موضوع بزرگتر از انتخاب چند کلمهٔ دقیق است. ما باید زمینهای بسازیم که ابزار بتواند داخل آن تصمیمهای منسجم بگیرد. به این کار معمولاً مهندسی زمینه یا Context Engineering گفته میشود.
برای من مهندسی زمینه یعنی تبدیل دانشی که در ذهن تیم پراکنده است به مجموعهای روشن از هدفها، قواعد، دادهها و محدودیتها؛ چیزی که هم انسان و هم ابزار بتوانند از آن استفاده کنند.
درخواست خوب فقط توضیح ظاهر نیست
فرض کنید میخواهیم صفحهای برای رزرو وقت طراحی کنیم. اگر فقط دربارهٔ رنگ و ساختار کارتها توضیح بدهیم، شاید خروجی زیبایی بگیریم. اما تصمیمهای مهم هنوز بیپاسخ ماندهاند:
- کاربر برای چه خدمتی وقت میگیرد؟
- آیا انتخاب متخصص مهم است یا اولین زمان آزاد؟
- امکان لغو تا چه زمانی وجود دارد؟
- اگر پرداخت ناموفق بود، رزرو نگه داشته میشود؟
- کاربر با چه زبان و تقویمی راحتتر است؟
- چه اطلاعاتی قبل از تأیید باید نمایش داده شود؟
اینها جزئیات فرعی نیستند؛ خود تجربهاند. ابزار بدون این زمینه معمولاً از الگوهای عمومی استفاده میکند و جاهای خالی را با حدس پر میکند. ممکن است خروجی در نگاه اول درست بهنظر برسد، اما با واقعیت محصول فاصله داشته باشد.
زمینه از پنج بخش ساخته میشود
برای آماده کردن زمینه، من اطلاعات را در پنج لایه جمع میکنم.
۱. هدف
میخواهیم چه تغییری ایجاد کنیم؟ «طراحی صفحهٔ رزرو» هدف کافی نیست. «کم کردن تردید کاربر پیش از انتخاب زمان و کاهش رزروهای ناقص» جهت روشنتری میدهد.
۲. کاربر و موقعیت
کاربر کیست و در چه شرایطی از محصول استفاده میکند؟ عجله دارد؟ اولین بار است؟ روی موبایل است؟ اصطلاحات حوزه را میشناسد؟ یک persona طولانی همیشه لازم نیست؛ چند واقعیت اثرگذار کافی است.
۳. قواعد و محدودیتها
قانون کسبوکار، محدودیت فنی، دسترسپذیری، لحن برند، زبان و ساختار سیستم طراحی باید معلوم باشند. اگر یک دکمه در محصول فقط سه اندازه دارد، خروجی نباید اندازهٔ چهارمی اختراع کند.
۴. وضعیت و داده
صفحه در حالت خالی، خطا، بارگذاری و موفقیت چه میکند؟ داده از کجا میآید؟ چه چیزی قطعی و چه چیزی موقت است؟ طراحی فقط تصویر لحظهٔ ایدهآل نیست.
۵. معیار نقد
از کجا بفهمیم خروجی خوب است؟ سرعت انجام کار، کاهش خطا، فهم بهتر، اعتماد یا هماهنگی با سیستم؟ اگر معیار نداریم، تنها چیزی که میتوانیم بسنجیم ظاهر است.
این پنج لایه باعث میشوند ابزار نه فقط «چیزی شبیه محصول»، بلکه خروجی نزدیکتری به منطق واقعی آن بسازد.
فایل زمینه، حافظهٔ مشترک تیم است
مهندسی زمینه فقط برای صحبت با مدل نیست. در تیمهای محصول اطلاعات اغلب در جلسهها، فایلهای پراکنده و ذهن آدمها باقی میماند. طراح چیزی از تحقیق میداند، مدیر محصول هدف تجاری را میشناسد و توسعهدهنده محدودیت سیستم را. وقتی این دانش ثبت نشده باشد، حتی بدون AI هم تصمیمها ناهماهنگ میشوند.
یک فایل زمینهٔ خوب میتواند شامل این موارد باشد:
- مسئله و نتیجهٔ مورد انتظار
- کاربران اصلی و سناریوهای مهم
- واژگان و لحن محصول
- اجزای مجاز سیستم طراحی
- قواعد کسبوکار و سطح دسترسیها
- نمونهٔ دادهٔ واقعی یا ناشناسشده
- حالتهای مرزی و خطاهای شناختهشده
- تصمیمهای قبلی و دلیل آنها
لازم نیست این فایل طولانی باشد. مهم این است که اطلاعات اثرگذار، قابلدسترسی و بهروز باشند. هر بار که تیم چیزی یاد میگیرد، زمینه هم باید تغییر کند.
زمینهٔ زیاد هم میتواند مشکلساز باشد
یکی از اشتباههای من این بود که تصور میکردم هرچه اطلاعات بیشتری بدهم خروجی بهتر میشود. گاهی انبوهی از متن، اولویتها را محو میکند. ابزار همهچیز را میبیند اما نمیفهمد کدام بخش برای تصمیم فعلی مهمتر است.
برای همین زمینه را لایهبندی میکنم:
- ثابت: هویت برند، اصول محصول و سیستم طراحی
- مخصوص پروژه: کاربر، مسئله، محدودیت و معیار موفقیت
- مخصوص وظیفه: چیزی که همین حالا باید ساخته یا نقد شود
این ساختار کمک میکند اطلاعات ضروری نزدیک درخواست باشند و جزئیات کماهمیتتر مزاحم تصمیم نشوند.
به ابزار فقط نقش سازنده ندهیم
وقتی زمینه آماده شد، معمولاً اولین درخواست ما تولید راهحل است. اما میتوانیم نقشهای مفیدتری هم تعریف کنیم. من دوست دارم ابزار ابتدا نقش منتقد را بازی کند:
- کدام فرض بدون شواهد است؟
- چه کاربری در این جریان فراموش شده؟
- چه اتفاقی در حالت خطا میافتد؟
- کدام تصمیم با قواعد سیستم طراحی ناسازگار است؟
- اگر متن طولانی یا داده ناقص باشد چه چیزی میشکند؟
بعد از پاسخ، زمینه را اصلاح میکنم و تازه سراغ تولید میروم. این رفتوبرگشت کمک میکند مشکل را قبل از تبدیل شدن به صفحه پیدا کنیم.
میتوان از ابزار خواست دو دیدگاه مخالف ارائه کند، از زاویهٔ کاربر تازهکار و حرفهای نقد کند یا راهحل را در برابر معیارهای مشخص امتیاز دهد. مهم این است که معیارها از تیم بیایند، نه از حدس مدل.
مهندسی زمینه بخشی از طراحی سیستم است
اگر AI قرار است بهطور جدی وارد محصول یا فرایند تیم شود، زمینه نباید فقط در یک گفتوگوی شخصی باقی بماند. باید مشخص شود کدام داده مجاز است، چه کسی آن را بهروز میکند، چه قوانینی همیشه باید رعایت شوند و خروجی چگونه بررسی میشود.
این موضوع به طراحی سیستم نزدیک میشود. همانطور که برای رنگ، تایپوگرافی و کامپوننتها قاعده داریم، برای تصمیمهای هوشمند هم به اصول نیاز داریم: چه لحنی استفاده شود، چه چیزی هرگز حدس زده نشود، چه اقدامی تأیید بخواهد و عدمقطعیت چگونه نشان داده شود.
طراح محصول در اینجا نقش مهمی دارد، چون میتواند دانش کاربر، قواعد رابط و منطق سیستم را کنار هم بگذارد. مهندسی زمینه فقط مهارت نوشتن برای ماشین نیست؛ مهارت مرتب کردن فکر تیم است.
یک قالب ساده برای شروع
برای یک وظیفهٔ طراحی میتوان با این قالب کوتاه شروع کرد:
مسئله: کاربر کجا و چرا گیر میکند؟
هدف: بعد از این تغییر چه چیزی باید بهتر شود؟
کاربر: چه کسی، در چه شرایطی و با چه سطح دانشی؟
محدودیت: زمان، فناوری، قانون، محتوا و سیستم طراحی چه میگویند؟
وضعیتها: مسیر موفق، خطا، خالی، بارگذاری و بازگشت چیست؟
معیار نقد: خروجی با چه سؤالهایی بررسی میشود؟
وظیفه: دقیقاً چه چیزی باید تولید، مقایسه یا نقد شود؟
این قالب جای تحقیق و گفتوگو با تیم را نمیگیرد؛ نتیجهٔ آنها را قابلاستفاده میکند.
اگر بخواهم خلاصه کنم
خروجی ضعیف همیشه نتیجهٔ ابزار ضعیف نیست. گاهی ما از سیستم خواستهایم بدون شناخت کاربر، محصول و محدودیتها تصمیم بگیرد. یک پرامپت جذاب شاید پاسخ زیباتری بسازد، اما زمینهٔ خوب پاسخ قابلاعتمادتر میسازد.
بهنظر من مهندسی زمینه به یکی از مهارتهای اصلی طراح محصول تبدیل میشود، چون مرز میان تحقیق، سیستم طراحی، محتوا و فناوری را به هم وصل میکند. این مهارت حتی اگر فردا ابزارها عوض شوند باقی میماند: توانایی ساختن تصویری روشن از مسئله برای کسی که باید دربارهٔ آن تصمیم بگیرد.
اگر بخواهم در یک جمله بگویم: قبل از اینکه از AI راهحل بخواهیم، باید دنیایی را که قرار است در آن تصمیم بگیرد برایش قابلفهم کنیم.
برای مطالعه بیشتر
- Context Engineering: The Secret Skill Every UX Designer Needs to Learn in 2026
- Context Engineering Is Reimagining UX for AI
- پیوند مهندسی زمینه و طراحی تجربه
نوشتهٔ محمد عبدی، طراح محصول و تجربهٔ کاربری.