Skip to content
بازگشت به وبلاگ طراحی و تجربه کاربری

آیا GenAI می‌تواند جای طراحی رابط و فرانت‌اند را بگیرد؟.

آیا GenAI می‌تواند جای طراحی رابط و فرانت‌اند را بگیرد؟

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

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

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

ساختن صفحه با ساختن محصول فرق دارد

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

فرض کنید ابزار صفحهٔ مدیریت پروژه‌ای می‌سازد. نسخهٔ نمایشی ممکن است عالی باشد، ولی سؤال‌های واقعی تازه شروع می‌شوند:

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

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

کدام بخش‌ها واقعاً سریع‌تر شده‌اند؟

من ارزش GenAI را کم نمی‌کنم. چند بخش به شکل جدی تغییر کرده‌اند:

شروع نمونهٔ اولیه

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

ساخت اجزای تکراری

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

ترجمهٔ طراحی به کد اولیه

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

کشف خطا و پیشنهاد اصلاح

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

مستندسازی

توضیح کامپوننت، نوشتن نمونهٔ استفاده و ساخت فهرست حالت‌ها سریع‌تر می‌شود؛ البته به شرط بازبینی.

این تغییرها واقعی‌اند و بی‌توجهی به آن‌ها منطقی نیست. سؤال این است که زمان آزادشده را کجا خرج کنیم.

سیستم طراحی، تفاوت نمونه و محصول را نشان می‌دهد

وقتی خروجی AI را بدون زمینه می‌گیریم، اغلب صفحه‌ای شبیه هزاران محصول دیگر می‌بینیم. رنگ، شعاع گوشه‌ها و فاصله‌ها شاید خوب باشند، اما زبان بصری و رفتاری محصول ما را نمی‌شناسند.

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

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

دسترس‌پذیری جایی است که ظاهر کافی نیست

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

GenAI می‌تواند پیشنهاد بدهد یا حتی بسیاری از قواعد را رعایت کند، اما QA واقعی لازم است. خروجی باید با ابزار و کاربر بررسی شود. یک aria-label تولیدشده لزوماً درست نیست؛ ممکن است وجود داشته باشد اما معنای مناسبی نداشته باشد.

من دسترس‌پذیری را مرحلهٔ آخر نمی‌بینم. اگر کامپوننت‌ها از ابتدا درست ساخته شوند، سرعت تولید AI هم امن‌تر می‌شود.

همکاری طراح و توسعه‌دهنده تغییر می‌کند

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

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

من این تقسیم را مفید می‌بینم:

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

چک‌لیست من برای خروجی تولیدشده

قبل از اینکه نمونهٔ AI را آمادهٔ استفاده بدانم، این سؤال‌ها را مرور می‌کنم:

  1. آیا مسئلهٔ درست را حل می‌کند یا فقط ظاهر درخواست را ساخته؟
  2. تمام حالت‌های اصلی و مرزی تعریف شده‌اند؟
  3. دادهٔ واقعی و متن طولانی چیدمان را خراب نمی‌کند؟
  4. از کامپوننت‌ها و tokenهای موجود استفاده شده؟
  5. رفتار روی موبایل، تبلت و دسکتاپ بررسی شده؟
  6. استفاده با کیبورد و صفحه‌خوان ممکن است؟
  7. خطا، loading، empty state و permission state وجود دارند؟
  8. کد قابل‌فهم، امن و قابل‌نگهداری است؟
  9. عملکرد صفحه و حجم دارایی‌ها مناسب است؟
  10. یک انسان مسئول نتیجه را بازبینی و تأیید کرده؟

اگر چند پاسخ مبهم است، محصول هنوز آماده نیست؛ حتی اگر تصویرش عالی باشد.

آیا شغل‌ها حذف می‌شوند؟

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

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

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

اگر بخواهم خلاصه کنم

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

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

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

برای مطالعه بیشتر


نوشتهٔ محمد عبدی، طراح محصول و تجربهٔ کاربری.