
برای سالها وقتی از طراحی تجربه حرف میزدیم، تقریباً همیشه یک تصویر ذهنی داشتیم؛ یک انسان روبهروی صفحه نشسته، چیزی رو میبینه، تصمیم میگیره، کلیک میکنه، فرم پر میکنه، خرید میکنه، ثبتنام میکنه یا از محصول خارج میشه. تمام زبان UX هم بر همین فرض ساخته شده بود؛ کاربر چی میبینه؟ چی میفهمه؟ کجا گیج میشه؟ کجا اعتماد میکنه؟ کجا تبدیل میشه؟
اما در ۲۰۲۶ این فرض دیگر کامل نیست.
امروز همیشه این انسان نیست که مستقیماً وارد سایت یا محصول ما میشه. گاهی یک مدل زبانی، یک AI agent، یک موتور جستوجوی مولد، یک سیستم recommendation، یک crawler هوشمند، یک دستیار خرید، یک bot سازمانی یا یک ابزار اتوماسیون، قبل از انسان به محصول ما میرسه. اون ماشین قراره محتوای ما رو بخونه، ساختار رو بفهمه، تفاوت رو تشخیص بده، قیمت و محدودیتها رو استخراج کنه، به کاربر پیشنهاد بده یا حتی به نمایندگی از کاربر یک action انجام بده.
اینجا جاییست که Machine Experience Design یا به اختصار MX Design معنی پیدا میکنه.
MX Design یعنی طراحی تجربه برای زمانی که ماشین هم یکی از مخاطبان محصولست؛ نه به این معنی که انسان حذف میشه، بلکه به این معنی که انسان ممکنه از طریق ماشین با برند، محصول و سرویس ما ارتباط بگیره.
Nielsen Norman Group در مقالهای درباره AI agents میگه تعریف کاربر در حال گسترشه؛ چون agentها هم هدف دارن، با interface برخورد میکنن، تلاش میکنن کاری رو انجام بدن و interface یا به اونها کمک میکنه یا شکستشون میده.
این تغییر فقط یک بحث تکنیکال نیست. این تغییر، تعریف برند، محصول، محتوا، UX، SEO و حتی اعتماد را عوض میکنه.
UX کلاسیک روی این سؤال تمرکز داشت: آیا انسان میتونه این تجربه رو بفهمه و با اون کار کنه؟
MX سؤال دیگری اضافه میکنه: آیا ماشین هم میتونه این تجربه رو درست بخونه، بفهمه، ارزیابی کنه و امن عمل کنه؟
فرض کن یک کاربر از AI assistant خودش میپرسه بهترین ابزار برای مدیریت پروژههای ساختمانی و تولید محدوده کار پیدا کن که برای مدیر پروژه مناسب باشه، خروجی ساختاریافته بده و برای شرکتهای مدیریت دارایی قابل استفاده باشه. در دنیای قدیمی، کاربر در گوگل سرچ میکرد، چند سایت باز میکرد، صفحه اصلی رو میدید، شاید دموی محصول رو نگاه میکرد و بعد تصمیم میگرفت. در دنیای جدید، ممکنه AI assistant این کار رو انجام بده. یعنی قبل از اینکه انسان اصلاً سایت تو رو ببینه، ماشین داره تصمیم میگیره که برند تو رو وارد لیست پیشنهادها بکنه یا نه. اگر سایت تو از نظر بصری زیبا باشه اما محتواش مبهم، ساختارش نامنظم، دادههاش ناقص و مزیتش غیرقابل استخراج؛ برای ماشین تقریباً نامرئی یا بیاعتماد میشه. پس در MX، محصول فقط نباید دیده شه؛ باید قابل فهم، قابل استخراج، قابل اعتماد و قابل اجرا باشه.
چند تغییر همزمان باعث شده MX از یک ایده عجیب به یک ضرورت طراحی تبدیل شه.
اول، AI دیگر فقط یک chatbox نیست. به سمت agentهایی میره که میتونن هدف بگیرن، برنامهریزی کنن، ابزارها رو صدا بزنن، دادهها رو بخونن و کار انجام بدن. NN/g مثالهایی مثل ترکیب تقویم، رزرو پرواز، بررسی نسخه دارویی و پیدا کردن محصول با قیمت مشخص رو مطرح میکنه؛ یعنی agentها فقط جواب نمیدن، تلاش میکنن task انجام بدن.
دوم، جستوجو در حال تغییره. کاربر دیگر فقط keyword وارد نمیکنه؛ سؤال میپرسه، مقایسه میخواد، خلاصه میخواد، پیشنهاد میخواد. Google در توضیح AI Overviews و AI Mode میگه این قابلیتها برای سؤالهای پیچیدهتر، مقایسهها و exploration استفاده میشه و ممکنه از تکنیکهایی مثل query fan-out استفاده کنن؛ یعنی چندین جستوجوی مرتبط انجام بدن تا پاسخ نهایی بسازن.
سوم، بازار از AI hype خسته شده. در گزارش State of UX 2026، NN/g میگه ۲۰۲۶ در حال تبدیل شدن به سال AI fatigue است؛ کاربران و تیمهای محصول از قابلیتهای سطحی AI، ابزارهای بیربط و featureهایی که فقط برای ترند بودن اضافه شدهان خسته شدهان. نتیجه اینه که AI فقط زمانی ارزش داره که واقعاً در workflow جا بیفته و مسئله واقعی حل کنه.
بنابراین MX به معنیه AI اضافه کنیم چون مد شده نیست. برعکس، MX یعنی محصول رو طوری طراحی کنیم که در اکوسیستم AI قابل فهم، قابل اعتماد و قابل استفاده باشه.

Machine Experience Design یعنی طراحی محتوا، رابط، داده، ساختار، actionها، APIها و سیگنالهای اعتماد به شکلی که سیستمهای ماشینی بتونن محصول یا برند رو درست کشف کنن، درست تفسیر کنن، درست ارزیابی کنن و در صورت مجاز بودن، درست با آن تعامل کنن.
UX یعنی: برای انسان واضح باشه.
MX یعنی: برای ماشین هم قابل فهم باشه.
CX یعنی: کل تجربه مشتری در همه touchpointها منسجم باشه.
BX یا Brand Experience یعنی: معنا، شخصیت و اعتماد برند در همه برخوردها حس شه
MX همه اینها رو به یک لایه جدید وصل میکنه: آیا ماشین میتونه همین معنا، ساختار، اعتماد و action رو بدون حدس زدن بفهمه؟
نکته مهم اینه که MX جای UX رو نمیگیره. همونطور که Mobile UX جای Desktop UX رو نگرفت، بلکه یک لایه جدید به طراحی اضافه کرد، MX هم یک لایه جدیده. ما هنوز برای انسان طراحی میکنیم؛ اما باید بپذیریم که مسیر انسان به محصول، همیشه مستقیم نیست. گاهی انسان از طریق AI به محصول میرسه.
خیلی از سایتها و محصولها از بیرون خوب به نظر میرسن، اما برای ماشین مبهماند. مثلاً یک لندینگ پیج رو تصور کن که بالاش نوشته: کار در آینده، تغییر کرد
برای انسان شاید جذاب باشه اما ماشین چی میفهمه؟ این محصول چیه؟ برای چه کسیه؟ دقیقاً چه کاری انجام میده؟ SaaSه؟ ابزار منابع انسانیه؟ مدیریت پروژهست؟ AI اتومیشنه؟ قیمت داره؟ API داره؟ برای شرکته یا شخص؟
در UX، این جمله ممکنه از نظر احساسی خوب باشه اما در MX، این جمله تقریباً بیمصرفه.
یا فرض کن یک دکمه در UI روش نوشته: بزن بریم. برای انسان شاید قابل فهم باشه، چون context تصویری رو میبینه. اما برای agent، این دکمه چه اکشنی داره؟ ثبتنام میکنه؟ پرداخت رو شروع میکنه؟ فرم رو submit میکنه؟ داده رو حذف میکنه؟
اگر label، role، state و نتیجه action واضح نباشه، ماشین باید حدس بزنه و هرجا ماشین حدس بزنه، ریسک خطا بالا میره.
اصل طلایی در Machine Experience :
Don’t make the machine guess.
ماشین نباید حدس بزنه محصول تو چیه، صفحه درباره چیه، action چه میکنه، داده چقدر معتبره، قیمت مربوط به چه پلنیه یا آخرین آپدیت چه زمانی بوده.

برای اینکه MX رو عملی بفهمیم، میتونیم اون رو به چند لایه تقسیم کنیم.
این پایهایترین لایهست. یعنی ساختار صفحه، محتوا و اینترفیس باید معنا داشته باشه، نه فقط ظاهر.
تو وب، این یعنی استفاده درست از headingها، HTML semantic، labelهای فرم، alt text، hierarchy واضح، navigation قابل فهم و محتوای متنی که فقط داخل تصویر یا animation قفل نشده باشه.
Schema.org هم دقیقاً از همین منطق میاد: ایجاد یک vocabulary مشترک برای structured data در صفحات وب، ایمیلها و جاهای دیگه؛ تا موتورهای جستوجو و applicationها بتونن معنی اطلاعات رو بهتر بفهمن. خود Schema.org میگه این vocabulary شامل entityها، رابطهها و actionهاست و با فرمتهایی مثل JSON-LD قابل استفادهست.
این یعنی اگر صفحه محصول داری، فقط متن تبلیغاتی کافی نیست. باید entityهای اصلی روشن باشن: نام محصول، دستهبندی، کاربرد، مخاطب، ویژگیها، قیمت، محدودیتها، FAQ، founder یا company، reviewها، case studyها و تاریخ بهروزرسانی.
Structured data یعنی بخشی از محتوای تو به شکلی نوشته شه که ماشین بتونه اون رو با اطمینان بخونه.
Google Search Central توضیح میدهه که Google از structured data برای فهم محتوای صفحه و اطلاعات مربوط به افراد، کتابها، شرکتها و چیزهای دیگر استفاده میکنه. همچنین توصیه میکنه داده ساختاریافته با متن قابل مشاهده در صفحه هماهنگ باشه.
در UX معمولی، ممکنه بگی کاربر که صفحه رو میبینه، خودش میفهمه. اما در MX، این کافی نیست. باید بپرسی آیا سیستم هم دقیقاً همون چیزی رو میفهمه که ما میخواهیم؟
اگه قیمت در یک تصویر باشه، اگه ویژگیها در carousel پنهان باشنه، اگه FAQ با JavaScript دیر load شه، اگه اطلاعات کلیدی در ویدیو باشه اما transcript نداشته باشه، ماشین ممکنه تصویر ناقصی از محصول بسازه.
این لایه از همه مهمتر و آیندهدارتره. چون MX فقط درباره خوانده شدن نیست؛ درباره عمل کردن هم هست.
یک agent ممکنه فقط سایت تو رو summarize نکنه. ممکنه بخواد کاری انجام بده: رزرو کنه، قیمت بگیره، فایل بسازه، محصول رو compare کنه، issue ثبت کنه، invoice دانلود کنه، زمان جلسه بگیره یا وضعیت سفارش رو چک کنه.
اینجا interface بصری کافی نیست. ماشین به actionهای واضح، permissionهای مشخص، endpointهای امن و errorهای قابل فهم نیاز داره.
در دنیای agentها، پروتکلهایی مثل Model Context Protocol یا MCP دقیقاً به همین نیاز نزدیک هستند. طبق specification رسمی MCP، سرورها میتونن سه نوع قابلیت ارائه کنن: Resources برای context و data، Prompts برای workflowها و templateها، و Tools برای functionهایی که مدل میتونه اجرا کنه.
از دید طراحی، این یعنی Product Designer فقط دکمه طراحی نمیکنه باید فکر کنه:
این action برای انسان چه شکلیه؟
همین action برای agent چطور معرفی میشه؟
agent از کجا میفهمه این action مجازه؟
چه confirmationی لازم داره؟
چه دادهای باید قبل از اجرا validate بشه؟
اگر action خطرناکه، human approval کجا وارد میشه؟
وقتی ماشین قراره درباره تو به کاربر پیشنهاد بده، اعتماد حیاتی میشه. ماشین باید بدونه کدوم منبع رسمیه، کدوم اطلاعات جدیده، کدوم claim قابل اثباته و کدوم action حساسه.
برای انسان، اعتماد ممکنه از طراحی بصری، لوگو، tone of voice و حس کلی برند بیاد. برای ماشین، اعتماد بیشتر از نشانههای ساختاری میاد:
تاریخ انتشار و بهروزرسانی
نویسنده یا سازمان منتشرکننده
منبع claimها
consistency بین صفحات
دادههای قابل verify
سیاست privacy و security
مستندات API
محدودیتها و disclaimers
reviewهای واقعی
case studyهای دقیق
canonical source برای اطلاعات برند
در جستوجوی AI هم همین موضوع حساس شده. بحثهای ۲۰۲۶ درباره AI Overviews نشان میده ناشران و رسانهها نگراناند که محتوایشان توسط خلاصههای AI استفاده شه ولی کلیک و اعتبار کافی دریافت نکنه. در بریتانیا، CMA پیشنهادهایی درباره امکان opt-out ناشران از استفاده محتواشون در AI Overviews مطرح کرد، چون خروجیهای AI میتونه روی ترافیک و درآمد ناشران اثر بگذاره. پس MX فقط تکنیک نیست؛ موضوع مالکیت محتوا، attribution، اعتماد و کنترل هم هست.
برند همیشه برای انسانها ساخته شده، اما حالا باید برای ماشینها هم قابل توصیف باشه. یک brand designer معمولاً روی logo، color، typography، imagery، tone، composition و احساس برند کار میکنه اما در MX، سؤال جدید اینه که:
اگر یک AI بخواد برند تو رو در سه جمله به کاربر معرفی کنه، چی میگه؟
آیا همون چیزی رو میگه که تو میخوای یا از چند صفحه پراکنده و مبهم یک برداشت سطحی میسازد؟
در عصر AI، برند فقط چیزی نیست که دیده میشه؛ چیزیه که summarized میشه. یعنی ممکنه اولین برخورد کاربر با برند تو، نه homepage تو باشه، نه تبلیغ تو، نه پست لینکدین تو؛ بلکه یک پاسخ AI باشه که میگه این شرکت یک ابزار X برای Y است که بیشتر برای Z استفاده میشه.
اگه برند تو positioning واضح نداشته باشه، ماشین positioning رو برات میسازه و این خیلی خطرناکه.

خیلیها ممکن است MX رو با SEO اشتباه بگیرن. اما این دو یکی نیستن.
SEO بیشتر میپرسه چطور در نتایج جستوجو دیده شم؟
MX میپرسه چطور توسط ماشینها درست فهمیده شم و درست مورد استفاده قرار بگیرم؟
SEO بخشی از MX: در SEO، ممکنه تمرکز روی keyword، ranking، backlinks، سرعت سایت و crawlability باشه. در MX، علاوه بر اینها، به مواردی مثل semantic clarity، action discoverability، agent permissions، structured workflows، API readability، trust signals، machine-readable brand positioning و evaluation برای agentها هم توجه میکنیم.
Google البته در مستندات AI features میگه برای ظاهر شدن در AI Overviews و AI Mode requirement خاصی فراتر از اصول پایه SEO وجود نداره و لازم نیست فایل یا markup مخصوص AI ساخته شه؛ اما همون صفحه تأکید میکنه که محتوای مهم باید در فرم متنی در دسترس باشه، structured data با متن visible هماهنگ باشه و best practiceهای فنی رعایت شن.
این نکته خیلی مهمه: MX به معنی دنبال کردن trickهای عجیب برای فریب AI نیست. MX یعنی محصول و محتوا واقعاً واضح، ساختاریافته، قابل دسترس و قابل اعتماد باشه.
فرض کن یک سایت SaaS صفحهای دارد با این hero که پتانسیل کامل تیم خود را با ورکفلو هوشمند باز کنید که ظاهر صفحه عالیه، انیمیشن داره، gradient داره، mockup داره و testimonial هم داره. اما مشکل کجاست؟
معلوم نیست محصول دقیقاً چه کاری انجام میده
مخاطب نامشخصه
industry نامشخصه
قابلیتها با کلمات کلی توضیح داده شده
pricing مبهمه
use caseها واقعی نیست
FAQ نداره
دادهها در تصویر هستن
case studyها جزئیات ندارن
دکمهها label دقیق ندارن
schema وجود نداره
مستندات API پنهانه
محدودیتهای محصول گفته نشده
تاریخ بهروزرسانی محتوا مشخص نیست
برای انسان ممکنه صفحه زیبا باشه و کارآمد اما برای ماشین، صفحه نامطمئنه.
حالا نسخه MX-friendly همون صفحه میتونه اینطور باشه:
AcmeFlow یک پلتفرم اتوماسیون گردشکار هوش مصنوعی برای شرکتهای ساخت و ساز در بازار متوسطه که به مدیر پروژه این امکان رو میده تا توضیحات پروژه رو به حوزههای ساختاریِ کار تبدیل کنه، وظایف رو بر اساس طبقهبندیِ تجاری مسیریابی کنه، اسناد آماده تایید رو تولید کنه و بازبینیها رو در تیمها پیگیری کنه.
بعد صفحه ادامه میده:
مناسب کیه و کی نیست؟
چه inputهایی میگیره؟
چه outputهایی تولید میکنه؟
چه integrationهایی داره؟
چه محدودیتهایی داره؟
قیمت چگونه محاسبه میشه؟
امنیت و permissionها چطور کار میکنه؟
نمونه واقعی چیه؟
آخرین آپدیت چه زمانی بوده؟
مستندات برای developer یا agent کجاست؟
این صفحه ممکن است از نظر visual حتی سادهتر باشه اما برای انسان و ماشین هر دو قابل فهمتره.
در ابتدا کپیرایت بیشتر برای قانع کردن انسان بود. در MX کپیرایت همچنان باید قانعکننده باشه، اما همزمان باید نقش دیتا رو هم بازی کنه یعنی هر جمله مهم باید قابل استخراج باشه.
مثلاً جمله روبهرو از نظر مارکتینگ خوبه، اما از نظر MX ضعیفه: ما کسبوکار شما را متحول میکنیم
اما این جمله بهتره: ما به تیم مدیریت دارایی کمک میکنیم Scope of Work، RFP و Bid Breakdown رو از روی Project Description تولید و استانداردسازی کنه.
جمله دوم شاید کمتر شاعرانه باشه، اما سه چیز داره:
۱. مخاطب مشخص: تیمهای property management
۲. کار مشخص: تولید SOW، RFP، Bid Breakdown
۳. input مشخص: Project Description
ماشین از این جمله میتونه entity و relationship استخراج کنه. انسان هم سریعتر میفهمه با چه چیزی طرفه.
در MX، شفافیت از زیرکی مهمتره.
در UX کلاسیک، کاربر خودش action رو انجام میده.
در MX، کاربر ممکنه action رو delegate کنه.
مثلاً به AI میگه: برام سه ابزار مناسب مدیریت پروژه ساختمانی پیدا کن، قیمت رو مقایسه کن، اگر trial داره؛ ثبتنام کن و یک گزارش خلاصه بده.
اینجا کاربر مستقیماً وارد funnel تو نشده. agent وارد قیف شده پس funnel جدید اینطور میشه:
Human intent → AI interpretation → Machine discovery → Product evaluation → Action attempt → Human confirmation → Conversion
این یعنی Product Designer نباید فقط User flow انسانی بکشه؛ باید Agent flow هم طراحی کنه.
سؤالهای جدید Product Designer:
agent چطور محصول رو discover میکنه؟
از کجا میفهمه محصول برای این intent مناسبه؟
چه دادههایی برای مقایسه لازم داره؟
آیا قیمت و محدودیتها واضحاند؟
آیا trial signup برای agent قابل انجامه؟
کجا نیاز به human confirmation داره؟
اگر agent اشتباه فهمید، محصول چطور جلوی خطا رو میگیره؟
آیا سیستم log و audit داره؟
آیا کاربر میتونه کاری رو که agent انجام داده review کنه؟
اینها دیگه فقط سؤال developer نیستند؛ اینها سؤالهای طراحی محصولاند.
در تجربه ماشینی microcopy فقط برای آروم کردن انسان نیست؛ برای کاهش خطای ماشین هم هست.
یک error message مثل مشکلی پیش آمد؛ برای انسان نامناسبه اما برای ماشین فاجعهست. بهتره اینطور نمایش داده شه: فاکتور تولید نمیشه چون آدرس صورتحساب وجود نداره لطفا یک آدرس صورتحساب اضافه و دوباره امتحان کنید. این پیام برای انسان و agent واضحه: مشکل چیه، کدام فیلد جا مونده، اکشن بعدی چیه.
برای یک اکشن حساس، به جای: مطمئنی؟ بهتره بنویسیم: این اقدام ۱۸ فایل پروژه رو برای همیشه از فضایکار مشترک حذف میکنه و قابل واگرد نیست. فقط سرپرست فضای کار میتونه این اقدام رو تأیید کنه. این جمله هم به انسان کمک میکنه، هم به agent. چون action، object، consequence، reversibility و permission در اون روشنه.
در تجربه ماشینی، هر action باید این اطلاعات رو داشته باشه:
نام اکشن
آبجکت
ورودی مورد نیاز
خروجی مورد انتظار
سطح ریسک
reversibility
permission
confirmation rule
error recovery
Design Systemها معمولاً شامل color، typography، components، spacing، interaction states و guidelines هستن اما در تجربه ماشینی سیستمدیزاین باید یک لایه semantic هم داشته باشه. مثلاً یک دکمه فقط نباید primary یا secondary باشه.
باید معلوم باشه:
این button چه action category داره؟
آیا action destructive هست؟
آیا نیاز به confirmation داره؟
آیا action async هست؟
success state چیه؟
error state چیه؟
آیا برای agent قابل اجراست؟
آیا permission خاصی میخواد؟
همینطور form componentها:
فیلد چه entityای رو دریافت میکنه؟
format معتبر چیه؟
validation rule چیه؟
کدوم خطاها ممکنه؟
چه مثالهایی مجازند؟
آیا داده sensitive هست؟
در آینده، سیستمدیزاین فقط برای designer و frontend developer نیست. میتونه منبعی باشه برای AI agentها، code generatorها، QA automation، documentation و حتی customer support botها. یعنی سیستمدیزاین از یک library بصری به یک System of Meaning تبدیل میشه.

در گذشته برندها روی این کنترل داشتن که کاربر در سایت، تبلیغ، شبکه اجتماعی یا بستهبندی چه چیزی ببینه. اما در دنیای AI، یک لایه واسطه وارد شده: AI ممکنه برند رو خلاصه کنه، مقایسه کنه، پیشنهاد بده یا حتی رد کنه.
پس سؤال برندینگ این نیست که فقط ما درباره خودمان چی میگیم؟ بلکه این هم هست ماشینها درباره ما چی میفهمن و چی میگن؟
اگه brand positioning مبهم باشه، AI ممکنه تو رو اشتباه دستهبندی کنه، claimهای تو زیاد اما بیمدرک باشه، AI ممکنه تو رو کمتر معتبر بدونه، در کانالهای مختلف inconsistent باشی، AI ممکنه تصویر متناقض بسازه، مزیت رقابتیات فقط در ویدیو یا pitch deck باشه و روی وب قابل خوندن نباشه، ممکنه اصلاً وارد پاسخ نشه.
برای برندها، تجربهماشینی یعنی ساختن یک حقیقت نام تجاری متعارف:
ما دقیقاً کی هستیم؟
برای چه کسی هستیم؟
چه مسئلهای رو حل میکنیم؟
چه چیزی ما رو متفاوت میکنه؟
چه شواهدی داریم؟
چه چیزهایی نیستیم؟
کدام صفحه منبع رسمی این اطلاعاته؟
کدام اطلاعات قدیمی شده؟
آیا tone of voice ما برای AI هم قابل تشخیصه؟
برندهایی که این کار رو نکنن، اجازه میدن ماشینها هویتشون رو از روی تکههای پراکنده اینترنت بسازن.
تجربهماشینی نباید باعث شه طراحی انسانی قربانی شه.
یکی از خطرها اینه که برندها اونقدر برای ماشین optimize کنن که محتوا خشک، بیروح، شبیه database و بیاحساس شه. این همون اشتباهیه که در بعضی دورههای SEO هم دیدیم: محتوا برای crawler (خزنده) نوشته میشه، نه برای انسان.
تجربهماشینی درست باید دوگانه نباشه. نباید بگیم یا انسان یا ماشین. باید بگیم قابل خواندن برای انسان + قابل خواندن توسط ماشین
متنی خوبه که انسان رو قانع کنه و ماشین رو هم گیج نکنه.
ساختاری خوبه که زیبا باشه و semantic هم باشه.
برندی قویه که احساس داشته باشه و قابل خلاصه شدن هم باشه.
محصولی خوبه که انسان بتونه باهاش کار کنه و agent هم بتونه با اجازه انسان ازش استفاده کنه.
در ۲۰۲۶، با زیاد شدن AI fatigue، تجربههایی برنده میشن که AI رو بیسروصدا، مفید، قابل اعتماد و انسانی استفاده کنن؛ نه اونهایی که فقط روی همه چیز برچسب AI میزنن.
برای اینکه تجربهماشینی از یک مفهوم مبهم به یک روش طراحی تبدیل شه، میتونیم چند اصل عملی تعریف کنیم.
ماشین context انسانی نداره. شوخی، استعاره، شعار و تصویرسازی ممکنه کمک کنه، اما نباید جای توضیح دقیق رو بگیره. به جای دیزاینی که برندها رو به جلو می برد بنویس ما هویت های بصری ممتاز، سیستم های برند و رابطهای محصول رو برای استارتآپهای فناوری طراحی میکنیم.
صفحه درباره چیه؟ محصول؟ شخص؟ سرویس؟ مقاله؟ case study؟ قیمت؟ مستندات؟ اگر خودت نتونی entity اصلی صفحه رو در یک جمله بگی، ماشین هم احتمالاً نمیتونه.
دکمهها و flowها باید action واضح داشته باشن. “Continue” همیشه کافی نیست. Continue به کجا؟ چه چیزی submit میشه؟ چه چیزی ساخته میشه؟ چه چیزی تغییر میکنه؟
بهترین، سریعترین، مطمئنترین، premium، enterprise-grade بدون سند برای ماشین هم ضعیفه. case study، عدد، تاریخ، مشتری، benchmark، review و example لازمه.
اگه اطلاعات کلیدی فقط داخل screenshot، infographic یا ویدیو باشه، ممکنه درست خوانده نشه. transcript، caption، متن قابل انتخاب و structured summary لازمه.
Error message باید به agent و انسان بگه: مشکل چیه، چرا رخ داده، چه چیزی لازمه، قدم بعدی چیه.
اگه agent میتونه action انجام بده، باید مرزها روشن باشه. چه کاری بدون تأیید انجام میشه؟ چه کاری نیاز به approval داره؟ چه کاری ممنوعه؟ چه چیزی audit میشه؟
برای برند، محصول، pricing، policy و documentation، صفحه canonical داشته باش. اگه اطلاعات در چند جا متفاوت باشه، ماشین ممکنه اشتباهترین نسخه رو برداره.
همونطور که user testing داریم، باید agent testing هم داشته باشیم. از agent بپرس:
این محصول چیه؟
برای چه کسی مناسبه؟
چه تفاوتی با رقبا داره؟
قیمتش چقدره؟
چطور میشه ثبتنام کرد؟
محدودیتهاش چیه؟
آیا میتونی یک action مشخص رو انجام بدی؟
اگه جوابها اشتباهه، مشکل فقط AI نیست؛ احتمالاً تجربه تو برای ماشین مبهمه.
برای بررسی یک محصول یا برند از نظر Machine Experience، این سؤالها رو بپرس:
۱. آیا AI میتونه از روی سایت ما دقیقاً بفهمه چه محصولی داریم؟
۲. آیا مخاطب اصلی ما واضحه؟
۳. آیا مزیت رقابتی ما قابل استخراجه یا فقط در شعار پنهان شده؟
۴. آیا صفحات اصلی heading structure درست دارن؟
۵. آیا محتوای مهم به شکل text قابل خواندنه؟
۶. آیا structured data معتبر داریم؟
۷. آیا structured data با متن visible یکیه؟
۸. آیا pricing، limitations و use cases واضحه؟
۹. آیا FAQ واقعی داریم یا فقط سؤالات تبلیغاتی؟
۱۰. آیا case studyها شواهد کافی دارن؟
۱۱. آیا تاریخ آخرین آپدیت مشخصه؟
۱۲. آیا actionهای مهم label دقیق دارن؟
۱۳. آیا error messageها قابل حل هستند؟
۱۴. آیا API یا integration docs قابل فهمه؟
۱۵. آیا permission model مشخصه؟
۱۶. آیا agent میتونه بدون حدس زدن بفهمه چه کاری مجازه؟
۱۷. آیا brand positioning در همه کانالها consistent هست؟
۱۸. آیا AI وقتی برند ما رو summarize میکنه، همون چیزی رو میگه که ما میخواهیم؟
۱۹. آیا اطلاعات قدیمی یا متناقض در وب داریم؟
۲۰. آیا برای human override و review مسیر مشخص داریم؟
اگر جواب بیشتر این سؤالها نه هسنش، مشکل فقط SEO نیست؛ مشکل MX است.
Machine Experience Design نقش طراح رو بزرگتر میکنه، نه کوچکتر. طراح آینده فقط صفحه نمیچینه. طراح آینده باید معنا رو طراحی کنه؛ معنا برای انسان، معنا برای ماشین، معنا برای برند، معنا برای سیستم، معنا برای agent و معنا برای تصمیمگیری.
Product designer باید بفهمه agentها چطور task انجام میدهن.
Brand designer باید بفهمه AI چطور برند رو summarize میکنه.
UX writer باید بفهمه microcopy چطور error و action رو قابل فهم میکنه.
Design system designer باید componentها رو از حالت visual library به semantic system تبدیل کنه.
UX researcher باید فقط رفتار انسان را نبینه؛ باید ببینه وقتی انسان از طریق AI عمل میکنه، decision journey چطور تغییر میکنه.
به همین دلیل MX یک skill جانبی نیست. یک تغییر نگرشه.
ممکنه در آینده بخشی از UIها کمتر دیدهشن، چون کاربر مستقیم با agent حرف میزنه اما این به معنی مرگ طراحی نیست. برعکس، وقتی interface پنهانتر میشه، طراحی عمیقتر میشه.
در گذشته، طراح میپرسید این صفحه چطور دیده میشه؟ حالا باید بپرسه این سیستم چطور فهمیده میشه؟
این تغییر بزرگیه؛ ممکنه کاربر هیچوقت pricing page تو رو باز نکنه، اما agent باید pricing رو بفهمه. ممکنه کاربر feature list تو رو نخونه، اما agent باید قابلیتها رو مقایسه کنه. ممکنه کاربر فرم رو خودش پر نکنه، اما agent باید بدونه کدوم فیلد لازمه. ممکنه کاربر homepage تو رو نبینه، اما AI باید برند تو رو درست معرفی کنه. پس طراحی از سطح visual به سطح semantic، procedural و trust-based حرکت میکنه.
نتیجهگیری:
آینده طراحی، طراحی برای فهمه.
Machine Experience Design یک مد زودگذر نیست، چون از یک تغییر بنیادی میاد: ماشینها دیگه فقط پشتصحنه نیستند. اونها در discovery، evaluation، recommendation و execution نقش دارن.
در گذشته، ماشینها بیشتر index میکردن، امروز summarize میکنن، فردا action انجام میدهن و هر مرحله از این مسیر، نیاز به طراحی داره.
برندها و محصولاتی که فقط زیبا هستن اما قابل فهم نیستن، در دنیای AI ضعیف میشن. محصولاتی که فقط keyword دارن اما trust ندارن، ضعیف میشن. تجربههایی که فقط انسان رو در نظر میگیرن و agentها رو نادیده، بخشی از مسیر جدید کاربر رو از دست میدن اما برندهایی که هم برای انسان روشناند و هم برای ماشین، برنده میشن؛ چون آینده طراحی فقط این نیست که کاربر چه چیزی میبینه، آینده طراحی اینه که سیستمها از ما چه میفهمن.
در این آینده، بهترین طراح کسی نیست که فقط interface زیبا بسازه؛ بهترین طراح کسیه که تجربهای بسازه که انسان بهش اعتماد کنه، ماشین اونرو درست بفهمه و برند در هر دو جهان معنای خودش رو از دست نده.
[1]: https://www.nngroup.com/articles/ai-agents-as-users/ "AI Agents as Users - NN/G"
[2]: https://developers.google.com/search/docs/appearance/ai-features "AI Features and Your Website | Google Search Central | Documentation | Google for Developers"
[3]: https://www.nngroup.com/articles/state-of-ux-2026/ "State of UX in 2026 - NN/G"
[4]: https://schema.org/ "Schema.org - Schema.org "
[5]: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data "Intro to How Structured Data Markup Works | Google Search Central | Documentation | Google for Developers"
[6]: https://modelcontextprotocol.io/specification/2025-11-25 "Specification - Model Context Protocol"
[7]: https://www.theguardian.com/media/2026/jan/28/uk-media-groups-should-be-allowed-opt-out-of-google-ai-overviews-cma-proposals "UK media groups should be allowed to opt out of Google AI Overviews, CMA says | Digital media | The Guardian"