منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

نقد طراحی (Design Critique) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

نقد طراحی (Design Critique) جلسه‌ای ساختاریافته است که در آن گروهی از هم‌تیمی‌ها یک طرح نیمه‌کاره یا آمادهٔ ارائه را کنار هم می‌گذارند و آن را در برابر هدفی که قرار بوده برآورده کند می‌سنجند. کلمهٔ کلیدی همین «هدف» است: در نقد طراحی قرار نیست بگوییم چه چیزی را دوست داریم، قرار است بگوییم این طرح تا چه اندازه کاری را که از آن انتظار می‌رفت انجام می‌دهد.

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

چرا اصلاً به جلسهٔ نقد نیاز داریم؟

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

اما صرفه‌جویی در هزینه تنها فایدهٔ آن نیست. جلسهٔ نقدِ منظم سه کار دیگر هم می‌کند که کمتر دیده می‌شوند:

• - فهم مشترک می‌سازد: وقتی مهندس، مدیر محصول و طراح با هم به یک جریان نگاه می‌کنند، اختلاف‌های پنهان دربارهٔ اینکه «اصلاً داریم چه مشکلی را حل می‌کنیم» زود بیرون می‌زند — همان اختلاف‌هایی که معمولاً وسط پیاده‌سازی و با هزینهٔ چند برابر آشکار می‌شوند.
• - طراح را از اثرش جدا می‌کند: در تیمی که هفته‌ای یک بار نقد می‌کند، شنیدن «این بخش کار نمی‌کند» به یک اتفاق عادی تبدیل می‌شود، نه یک حملهٔ شخصی. این عادی‌شدن، خودش یک دستاورد فرهنگی بزرگ است.
• - دانش را در تیم پخش می‌کند: طراح تازه‌کاری که در ده جلسهٔ نقد نشسته باشد، ده برابر بیشتر از خواندن مستندات یاد می‌گیرد؛ چون استدلال‌ها را می‌شنود، نه فقط نتیجه‌ها را.

نقد، واکنش و دستور: سه چیز کاملاً متفاوت

مفیدترین تفکیکی که می‌توانید به تیمتان یاد بدهید، همین سه‌تایی است. فرض کنید طراح صفحهٔ تسویه‌حساب را نشان می‌دهد:

• - واکنش (Reaction): «این دکمهٔ قرمز را دوست ندارم.» این جمله دربارهٔ گویندهٔ آن اطلاعات می‌دهد، نه دربارهٔ طرح. قابل بحث نیست، چون سلیقه است.
• - دستور (Direction): «دکمه را آبی کن.» این یک راه‌حل است که بی‌آنکه مشکلی را نام ببرد، از راه رسیده. طراح یا باید اطاعت کند یا مقاومت — و هر دو بد است.
• - نقد (Critique): «هدف این صفحه این بود که کاربر بدون مکث خرید را تمام کند. الان دکمهٔ «حذف سبد» و دکمهٔ «پرداخت» هم‌وزن‌اند و چشم نمی‌داند کدام کنش اصلی است؛ به نظرم سلسله‌مراتب بصری اینجا با هدف صفحه هم‌راستا نیست.» این جمله یک مشکل مشخص را به یک هدف مشخص وصل می‌کند و راه‌حل را باز می‌گذارد.

نقد خوب تقریباً همیشه همین شکل را دارد: مشاهده + هدف + پیامد. اگر عضوی از تیم نتوانست جمله‌اش را در این قالب بگوید، معمولاً یعنی هنوز نمی‌داند دقیقاً چه چیزی آزارش می‌دهد — و پرسیدن «کدام هدف را تهدید می‌کند؟» بهترین سؤال برای بازکردن آن گره است.

نقش‌ها: چه کسی چه کاری می‌کند؟

جلسهٔ نقدی که نقش‌ها در آن روشن نباشد، ظرف ده دقیقه به گفت‌وگوی آزاد تبدیل می‌شود. سه نقش کافی است:

• - ارائه‌دهنده: طراحِ کار. وظیفه‌اش این نیست که از طرح دفاع کند؛ وظیفه‌اش این است که زمینه بدهد — چه مشکلی، برای چه کسی، با چه محدودیتی، و امروز دقیقاً روی چه چیزی بازخورد می‌خواهد.
• - تسهیل‌گر: کسی که جلسه را در مسیر نگه می‌دارد. مهم‌ترین کارش دو چیز است: قطع‌کردن بحث‌هایی که به راه‌حل‌های زودرس می‌پرند، و باز کردن جا برای کسانی که ساکت مانده‌اند. در تیم‌های کوچک، این نقش می‌تواند بین اعضا بچرخد.
• - منتقدان: بقیهٔ حاضران. بهترین ترکیب، ترکیب متنوع است: طراح، مهندس فرانت‌اند، مدیر محصول، و اگر ممکن است کسی از پشتیبانی که هر روز صدای کاربر را می‌شنود. هر کدام یک نوع مشکل می‌بینند که دیگری نمی‌بیند.

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

ساختار یک جلسهٔ شصت‌دقیقه‌ای

قالب زیر برای گروه‌های سه تا هشت‌نفره خوب جواب می‌دهد:

• - ۱. زمینه‌دهی (۵ تا ۱۰ دقیقه): ارائه‌دهنده مسئله، کاربر هدف، محدودیت‌ها و معیار موفقیت را می‌گوید. اگر پرسونا یا یافته‌های تحقیق کاربر پشت این طرح هست، همین‌جا مطرح می‌شود.
• - ۲. طرح پرسش (۲ دقیقه): «امروز روی جریان ثبت‌نام بازخورد می‌خواهم، نه روی رنگ‌ها.» این جملهٔ کوتاه، بیشترین تأثیر را در کیفیت جلسه دارد.
• - ۳. مرور خاموش (۵ دقیقه): همه در سکوت طرح را می‌بینند و یادداشت می‌کنند. این مرحله جلوی «اثر لنگر» را می‌گیرد؛ وقتی اولین نفر بلند حرف می‌زند، ذهن بقیه ناخودآگاه به همان سمت می‌رود.
• - ۴. نقد (۳۰ دقیقه): نوبتی، هرکس مشاهده‌هایش را در قالب مشاهده+هدف+پیامد می‌گوید. ارائه‌دهنده فقط وقتی حرف می‌زند که سؤال روشن‌کننده‌ای پرسیده شده باشد.
• - ۵. جمع‌بندی (۱۰ دقیقه): تسهیل‌گر مضمون‌های تکرارشونده را بلند می‌خواند و تیم آن‌ها را اولویت‌بندی می‌کند. خروجی جلسه یک فهرست اولویت‌دار است، نه یک صفحهٔ پر از یادداشت پراکنده.

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

قاعده‌های زمین بازی

چند قاعدهٔ ساده که بهتر است پیش از شروع، جایی نوشته و دیده شوند:

• - دربارهٔ کار حرف بزنید، نه دربارهٔ آدم: «این جریان سه گام اضافه دارد»، نه «تو زیادی پیچیده‌اش کردی».
• - هر ایراد را به یک هدف وصل کنید: بازخوردی که به هیچ هدفی وصل نمی‌شود، سلیقه است.
• - راه‌حل ندهید، مگر بخواهند: پیشنهاد راه‌حل فضای طراحی را زودتر از موعد می‌بندد. اول مشکل را روشن کنید.
• - ارائه‌دهنده دفاع نمی‌کند: جملهٔ «بگذار توضیح بدهم چرا این‌طوری‌ست» را نگه دارید برای بعد از جلسه. اگر طرح فقط با توضیح شفاهی قابل‌فهم است، خودش یک یافتهٔ مهم است.
• - سکوت را پر نکنید: بازخورد بی‌کیفیت اغلب از احساس اجبار به حرف‌زدن می‌آید. «چیزی به ذهنم نمی‌رسد» جواب کاملاً قابل‌قبولی است.

کجا خراب می‌شود؟

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

• - سایهٔ بالادست: وقتی مدیر ارشد در جلسه است و اول از همه نظر می‌دهد، عملاً جلسه تمام شده است. راه‌حل: یا او آخر صحبت کند، یا نظرش را مثل بقیه در قالب مشاهده و هدف بیان کند.
• - طراحی با کمیته: جلسه‌ای که به رأی‌گیری ختم می‌شود، میانگین سلیقه‌ها را تولید می‌کند، نه بهترین طرح را. نقد ورودی می‌دهد؛ تصمیم مالک دارد.
• - بازخورد مبهم: «یک جای کار می‌لنگد» بی‌فایده است مگر تسهیل‌گر آن را باز کند: «کدام گام؟ چه انتظاری داشتی و چه دیدی؟»
• - زمان‌بندی غلط: نقد یک ماکاپ پیکسل‌کامل که فردا باید تحویل شود، دیر است؛ نقد یک ایدهٔ خام در جمع بیست‌نفره، زود. نقد را در مرحله‌ای بگذارید که هنوز تغییر ارزان است — معمولاً روی وایرفریم یا پروتوتایپ کم‌وفا.
• - جلسهٔ بی‌پیگیری: اگر هیچ‌کس نداند کدام بازخورد اعمال شد و چرا، مشارکت در جلسهٔ بعدی افت می‌کند. یک پیام کوتاه بعد از جلسه («این سه مورد را اعمال کردم، این یکی را به این دلیل نه») کافی است.

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

نقد در تیم‌های دورکار و فارسی‌زبان

این بخش در منبع اصلی نیست و از تجربهٔ کار با تیم‌های ایرانی می‌آید. دو موضوع را جدی بگیرید:

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

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

جمع‌بندی

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

و اگر قرار باشد فقط یک چیز از این متن بماند، همین باشد: هر بازخوردی که به یک هدف وصل نشود، سلیقه است — و سلیقه، هر قدر هم از دهان آدم مهمی بیرون بیاید، مبنای خوبی برای طراحی نیست.