وقتی یک ابزار هوش مصنوعی در چند دقیقه صفحه‌ای قابل نمایش می‌سازد، بخش قابل توجهی از کار روزانه طراح وب تغییر می‌کند. ساخت چند پیشنهاد برای چیدمان، نوشتن متن اولیه دکمه‌ها و تبدیل طرح به کد دیگر الزاماً ساعت‌ها کار دستی نمی‌خواهد. با این حال، صفحه قابل نمایش هنوز پاسخ کامل یک پروژه نیست. باید بدانیم چه کسی از آن استفاده می‌کند، چه کاری انجام می‌دهد، چه اطلاعاتی کم دارد و در کدام مرحله ممکن است منصرف شود. آینده شغل طراحی وب را بهتر است از همین کارهای مشخص بررسی کنیم، بدون وعده مصونیت همیشگی یا پیش‌بینی حذف همه طراحان.
کدام کارها آسان‌تر می‌شوند؟
کارهایی که ورودی روشن و خروجی قابل بررسی دارند، جای مناسبی برای شروع هستند. برای نمونه، طراح ساختار یک صفحه معرفی خدمات را مشخص می‌کند و از مدل چند نسخه برای ترتیب بخش‌ها می‌خواهد. مدل پیشنهادهایی درباره عنوان، توضیح کوتاه، شاهد اعتماد و فرم تماس می‌دهد. طراح این پیشنهادها را کنار اطلاعات واقعی کسب‌وکار می‌گذارد و موارد بی‌ربط را حذف می‌کند. ارزش این فرایند در زیادشدن گزینه‌های اولیه است؛ تصمیم درباره گزینه مناسب هنوز به هدف صفحه و محدودیت‌های پروژه وابسته است.
در پیاده‌سازی رابط نیز مدل می‌تواند markup اولیه یا توضیح خطای CSS را تهیه کند. تیم طراحی محصول Anthropic استفاده از Claude Code برای تبدیل ایده طراحی به پیاده‌سازی را در شرح تجربه تیم‌های خودش مطرح کرده است. این تجربه نشان می‌دهد فاصله میان طرح و نمونه اجرایی در بعضی گردش‌های کار کوتاه‌تر می‌شود. از تجربه یک تیم نمی‌توان نتیجه گرفت که همه پروژه‌ها با یک دستور آماده انتشار خواهند شد؛ زیرساخت، اندازه پروژه و معیار پذیرش نتیجه فرق دارد.
تولید تصویر هم به تهیه پیش‌نویس کمک می‌کند، اما تصویر مناسب وب باید در جای واقعی خودش ارزیابی شود. ممکن است ترکیب‌بندی یک تصویر برای نمایش تمام‌صفحه خوب باشد و در کارت کوچک موضوعش گم شود. تصویر محصول باید با کالای واقعی مطابقت داشته باشد و تصویر توضیحی نباید ویژگی ساختگی را به مشتری نسبت دهد. برای هر خروجی، از ابتدا کاربرد، اندازه نمایش و محدودیت محتوایی را بنویسید. بررسی مجوز و شرایط استفاده ابزار نیز بخشی از تحویل حرفه‌ای است.
مسئله طراحی را قبل از دستور تعریف کنید
دستور «یک سایت زیبا بساز» مدل را با تصمیم‌های حل‌نشده روبه‌رو می‌کند. زیبایی برای سایت فروش تجهیزات صنعتی و صفحه ثبت‌نام یک رویداد فرهنگی معنی یکسانی ندارد. ورودی بهتر شامل مخاطب، اقدام اصلی، اطلاعات ضروری و شرایط استفاده است. مثلاً توضیح دهید مشتری ابتدا باید سازگاری محصول با دستگاه خود را بررسی کند و سپس درخواست قیمت بفرستد. این توضیح ترتیب صفحه و جای مشخصات فنی را تغییر می‌دهد، حتی اگر رنگ و فونت همان قبلی بماند.
یک Brief کوتاه به اندازه یک سند طولانی بی‌دقت مفید است. نام محصول، محدوده محتوا، زبان رابط، مسیر اصلی و خطاهای محتمل را ثبت کنید. اگر داده‌ای ندارید، آن را با حدس پر نکنید. به مدل بگویید قیمت، نظر مشتری و ادعای عملکرد را از خودش نسازد و بخش نیازمند تأیید را در خروجی مشخص کند. چنین محدودیتی جلوی تولید صفحه‌ای را می‌گیرد که در نگاه اول کامل است، ولی اطلاعاتش قابل استفاده نیست. موضوع تکمیل اطلاعات واقعی را جدا از ساخت ظاهر پیگیری کنید.
شناخت کاربر هم به صرف پرسیدن نظر مدل انجام نمی‌شود. مدل می‌تواند برای مصاحبه سؤال پیشنهاد دهد یا یادداشت‌های بی‌نام را دسته‌بندی کند، اما پاسخ خیالی کاربران جای مشاهده را نمی‌گیرد. اگر می‌خواهید بفهمید مشتری در انتخاب خدمت سردرگم می‌شود، چند مسیر واقعی انتخاب را ببینید و دلیل توقف را بپرسید. مقاله User Research برای طراحان وب ادامه مناسبی برای طراحی این بخش از فرایند است. خروجی تحقیق باید فرضیه‌های طرح را تغییر دهد، نه اینکه صرفاً برای توجیه طرح قبلی استفاده شود.
نمونه سریع را با محصول آماده اشتباه نگیرید
صفحه‌ای که با داده ثابت درست به نظر می‌رسد، درباره رفتار برنامه در زمان خطا اطلاعات کمی می‌دهد. فرم تماس باید هنگام ارسال، قطع ارتباط و دریافت پاسخ ناموفق رفتار مشخصی داشته باشد. فهرست محصولات ممکن است خالی باشد یا نام‌های طولانی داشته باشد. کاربر ممکن است صفحه را بزرگ‌نمایی کند و با صفحه‌کلید جلو برود. این حالت‌ها را در درخواست اولیه بیاورید و بعد در طرح بررسی کنید. خروجی مدل معمولاً همان حالت‌هایی را بهتر پوشش می‌دهد که به‌روشنی از آن خواسته‌اید.
برای بررسی نمونه، معیار پذیرش بنویسید: عنوان صفحه مشخص باشد، دکمه اصلی متن قابل فهم داشته باشد، خطا به فیلد مربوط وصل شود و در عرض کوچک محتوای مهم حذف نشود. معیارها باید از نیاز پروژه بیایند. عبارت‌هایی مانند «تجربه عالی» چیزی برای قبول یا رد خروجی نمی‌دهند. وقتی معیار روشن است، بازخورد شما هم دقیق‌تر می‌شود: به جای درخواست بازطراحی کلی، می‌گویید توضیح خطا بعد از ارسال دیده نمی‌شود یا ترتیب خواندن با ترتیب دیداری فرق دارد.
کد تولیدشده ممکن است کتابخانه‌ای اضافه کند که پروژه به آن نیاز ندارد، یا مسئله‌ای کوچک را با ساختاری بزرگ حل کند. قبل از پذیرش، وابستگی‌ها، مسیر داده و مسئولیت اجزا را بخوانید. اگر کسی در تیم نمی‌تواند تغییر را توضیح دهد، نگهداری آن دشوار خواهد شد. ابزار باید به شما کمک کند کد را بفهمید، اما توضیح خودش را هم با کد مقایسه کنید. گاهی توضیح درباره رفتار مورد انتظار درست است و پیاده‌سازی هنوز آن رفتار را انجام نمی‌دهد.
کیفیت بصری به تصمیم‌های مرتبط نیاز دارد
خروجی‌های اولیه مدل‌ها اغلب از الگوهای آشنا استفاده می‌کنند: عنوان بزرگ، کارت‌های مشابه و دکمه‌ای پررنگ. این الگوها در بعضی پروژه‌ها مناسب‌اند، اما انتخاب خودکارشان هویت هر برند را نشان نمی‌دهد. برای رسیدن به طراحی مشخص، نمونه مرجع را با دلیل معرفی کنید. توضیح دهید کدام ویژگی را می‌خواهید: تراکم کم اطلاعات، کنتراست زیاد، عکس‌های مستند یا حس آرام. کپی‌کردن ترکیب کامل یک سایت دیگر جای تعریف زبان بصری پروژه را نمی‌گیرد.
در رابط فارسی، کیفیت فقط انتخاب یک فونت فارسی نیست. اعداد، تاریخ‌ها، نام‌های انگلیسی و نشانی‌ها رفتار متفاوتی دارند. کنار هم قرارگرفتن متن راست‌به‌چپ و شناسه لاتین ممکن است ترتیب خواندن را به هم بزند. طول جمله فارسی نیز با متن نمونه انگلیسی برابر نیست. از مدل بخواهید نمونه محتوای فارسی واقعی استفاده کند و سپس همان متن را در اجزای کوچک، جدول و فرم بررسی کنید. اگر طراحی بر پایه چند کلمه کوتاه ساخته شده باشد، با محتوای واقعی به‌سرعت محدودیتش معلوم می‌شود.
Design System به این بازبینی نظم می‌دهد. وقتی فاصله‌ها، رنگ‌ها و وضعیت دکمه‌ها مشخص‌اند، می‌توان خروجی مدل را با قواعد مشترک تطبیق داد. لازم نیست هر بار درباره شعاع گوشه و رنگ خطا مذاکره کنید. مقاله راهنمای Design System درباره ثبت همین تصمیم‌ها توضیح می‌دهد. هرچه قواعد شما روشن‌تر باشند، تولید چند صفحه مرتبط آسان‌تر می‌شود و اختلاف بصری میان بخش‌های سایت کمتر از تصمیم‌های تصادفی اثر می‌گیرد.
مسئولیت داده و ادعا را مشخص کنید
برای دریافت پیشنهاد طراحی، معمولاً لازم نیست اطلاعات شناسایی مشتری، رمز یا قرارداد کامل را وارد ابزار کنید. نمونه بی‌نام و حداقل داده لازم را انتخاب کنید. اگر ابزار به فایل‌ها یا مخزن متصل است، بدانید کدام منابع را می‌خواند و چه مجوزی برای تغییر دارد. سیاست سازمان و شرایط سرویس باید این انتخاب را پوشش دهند. فرض نکنید همه ابزارهای هوش مصنوعی داده را به شیوه یکسان نگه می‌دارند یا هر طرح اشتراک تنظیمات برابر دارد.
در تولید محتوا، ادعای حساس را به منبع وصل کنید. اگر مدل برای یک محصول «سریع‌ترین» می‌نویسد، باید بپرسید مبنای مقایسه چیست. اگر شاهدی ندارید، توضیح قابلیت واقعی را جایگزین کنید. نظر مشتری و لوگوی شریک تجاری باید واقعی و مجاز باشند. این تصمیم‌ها روی اعتماد و مسئولیت کسب‌وکار اثر دارند و با زیباترشدن صفحه حل نمی‌شوند. یک چک‌لیست کوتاه تحریری برای نام‌ها، مشخصات محصول و وعده‌های صفحه، از چند دور اصلاح ظاهری مفیدتر است.
مهارت‌های طراح چگونه تغییر می‌کنند؟
بخشی از ارزش حرفه‌ای از سرعت ساخت اجزای منفرد به توان تعریف مسئله و ارزیابی نتیجه منتقل می‌شود. طراح باید بتواند انتخابش را توضیح دهد، محدودیت فنی را بفهمد و بازخورد کاربر را به تغییر مشخص تبدیل کند. این مهارت‌ها پیش از هوش مصنوعی هم لازم بودند، اما وقتی پیش‌نویس ارزان‌تر می‌شود، کیفیت تصمیم بیشتر به چشم می‌آید. یادگیری اصول HTML، CSS و دسترسی‌پذیری کمک می‌کند پیشنهادهای ابزار را با اطمینان بیشتری بخوانید و خطاهای ظاهراً کوچک را تشخیص دهید.
برای ساخت نمونه‌کار، فقط تصویر نهایی را نشان ندهید. مسئله، محدودیت و دو تصمیم مهم را ثبت کنید. توضیح دهید ابزار چه پیشنهادی داد، کدام قسمت را پذیرفتید و چه چیزی را پس از بررسی تغییر دادید. مشتری از این روایت می‌فهمد شما مسئول نتیجه‌اید و می‌توانید در پروژه بعدی هم تصمیم بگیرید. هیچ ابزار یا مهارتی تضمین درآمد و امنیت شغلی نمی‌دهد؛ نمونه‌کار روشن به ارزیابی توان واقعی شما کمک می‌کند و گفت‌وگو درباره هزینه را دقیق‌تر می‌سازد.
برای شروع، یک صفحه کوچک با مسئله واقعی انتخاب کنید و نتیجه مورد انتظارش را بنویسید. از ابزار برای پیشنهاد ساختار و پیش‌نویس استفاده کنید، سپس اطلاعات، حالت‌های رابط و سازگاری با قواعد پروژه را خودتان مرور کنید. زمان صرف‌شده برای تولید و اصلاح را جدا ثبت کنید تا ببینید کمک ابزار در کدام بخش بیشتر بوده است. این تجربه کوچک مبنای بهتری برای تصمیم درباره گردش کار بعدی می‌دهد تا پذیرفتن وعده‌های تبلیغاتی درباره آینده طراحی وب.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!