سپنتا پویا — طراح محصول

تابلوی بازطراحی‌شدهٔ پارکینگ توسط نیکی سیلیان‌تنگ
نویسنده: Yu Siang Teo · منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · تیر ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

طراحی بد در برابر طراحی خوب؛ پنج مثال که از آن‌ها درس بگیریم

💡 این متن بازنویسی آزاد است: مفاهیم و درس‌های مقالهٔ اصلی با نگارش مستقل فارسی بازگو شده و ترجمهٔ کلمه‌به‌کلمه نیست. بیشتر تصاویر مقالهٔ اصلی حق نشر اختصاصی دارند و اینجا بازنشر نشده‌اند — برای دیدن همهٔ نمونه‌های تصویری به مقالهٔ اصلی (لینک در پایین صفحه) سر بزنید.

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

۱. سرریز اطلاعات (Information Overload)

تابلوهای پارکینگ سنتی لس‌آنجلس نمونهٔ کلاسیک این مشکل‌اند: ستونی از چند تابلوی جدا با متن‌های متراکم — «پارک ممنوع از ۸ تا ۱۰ صبح روزهای کاری»، «پارک یک‌ساعته از ۱۰ تا ۶ عصر»، «به‌جز با مجوز منطقه‌ای»... راننده‌ای که با سرعت دنبال جای پارک می‌گردد، باید همهٔ این جمله‌ها را بخواند، با هم ترکیب کند و در چند ثانیه نتیجه بگیرد که الان، در این لحظه، پارک‌کردن مجاز هست یا نه. نتیجهٔ طبیعی: سردرگمی، جریمه و عصبانیت.

تابلوی گیج‌کنندهٔ پارکینگ در لس‌آنجلس با چند تابلوی متنی متراکم
تابلوی سنتی پارکینگ لس‌آنجلس — © Jorge Gonzalez، لایسنس CC BY-SA 2.0

طراحی به اسم نیکی سیلیان‌تنگ (Nikki Sylianteng) این مسئله را از زاویهٔ درست دید. او فهمید سؤال واقعی راننده فقط یک چیز است: «الان می‌توانم اینجا پارک کنم یا نه؟» پس به‌جای متن، از یک نوار زمانی بصری استفاده کرد: بازه‌های مجاز به یک شکل و بازه‌های ممنوع به شکلی دیگر، در یک نگاه قابل‌تشخیص. طرح او حتی برای افراد کوربین‌رنگ هم کار می‌کند، چون فقط به رنگ تکیه نکرده و از الگو و برچسب هم کمک گرفته است.

تابلوی بازطراحی‌شدهٔ پارکینگ با نوار زمانی بصری سبز و قرمز
بازطراحی تابلوی پارکینگ — © Nikki Sylianteng، لایسنس CC BY-NC-SA 4.0

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

۲. ناوبری گوشتِ مرموز (Mystery Meat Navigation)

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

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

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

۳. افزودن اصطکاک به کنش‌های کاربر

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

اما اصطکاک ذاتاً بد نیست؛ جای درست و غلط دارد. نمونهٔ درستش اسکرول کشسانی (elastic scrolling) در iOS اپل است: وقتی به انتهای صفحه می‌رسید، محتوا کمی کش می‌آید و برمی‌گردد. این مقاومتِ لحظه‌ای یک پیام روشن دارد: «تمام شد؛ پایین‌تر چیزی نیست.» اصطکاکی کوچک که نه‌تنها مزاحم نیست، بلکه اطلاعات می‌دهد.

درس این مقایسه: اصطکاک را برای کنش‌هایی نگه دارید که می‌خواهید کاربر درباره‌شان مکث کند (مثل حذف حساب کاربری!)، و مسیر کنش‌های اصلی و پرتکرار را تا جای ممکن هموار کنید.

۴. طراحی «هوشمندانه‌ای» که کاربردپذیری را نادیده می‌گیرد

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

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

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

۵. انیمیشن‌های زائد

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

حالا نمونهٔ درست: انیمیشن تأیید کد در فرم‌های Stripe. وقتی کد تأیید را وارد می‌کنید و سیستم در حال بررسی است، انیمیشن ظریفی وضعیت را نشان می‌دهد و در پایان، موفقیت یا خطا را اعلام می‌کند. این انیمیشن دقیقاً در لحظه‌ای ظاهر می‌شود که کاربر به‌هرحال باید منتظر بماند، و همان انتظار را با بازخوردِ وضعیت پر می‌کند. حرکت اینجا کارکرد دارد: اطمینان‌بخشی.

درس این مقایسه: هر انیمیشن باید دلیل وجودی کارکردی داشته باشد — نشان‌دادن وضعیت، هدایت توجه، یا نرم‌کردن یک تغییر ناگهانی. اگر انیمیشنی فقط «قشنگ» است و کاربر را از اطلاعاتش دور نگه می‌دارد، حذفش کنید.

۶. متن خطایی که مقصر را کاربر می‌داند

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

طراحی بد: «خطا: ورودی نامعتبر است.» این جمله سه کار غلط را با هم انجام می‌دهد: نمی‌گوید کدام فیلد، نمی‌گوید چه چیزی درست است، و لحنش کاربر را متهم می‌کند. حالت بدترش پیامی است که کد خطای داخلی سیستم را نشان می‌دهد — چیزی که برای کاربر نه معنایی دارد و نه کاری با آن می‌شود کرد.

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

یک نکتهٔ لحنی هم هست که در فارسی مهم‌تر می‌شود: از ساختار متهم‌کننده پرهیز کنید. «اشتباه وارد کردید» با «شماره باید ۱۶ رقم باشد» یک اطلاعات را منتقل می‌کنند، ولی اولی کاربر را در موضع دفاعی می‌گذارد. جزئیات بیشتر این بحث در نوشتار رابط آمده.

۷. فرمی که اطلاعاتی می‌خواهد که لازم نیست

این هم افزودهٔ مترجم است. هر فیلد اضافه در فرم، درصدی از کاربران را می‌ریزاند — و در فرم‌های فارسی‌زبان این هزینه معمولاً دست‌کم گرفته می‌شود.

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

طراحی خوب: فقط چیزی را بخواهید که برای همین گام لازم است، و بقیه را به لحظه‌ای موکول کنید که واقعاً نیاز می‌شود — همان کاری که در افشای تدریجی بحث شد. برای هر فیلد یک پرسش بپرسید: اگر این را نداشته باشیم، چه کاری نمی‌توانیم انجام دهیم؟ اگر جواب روشنی ندارید، فیلد باید حذف شود.

و اگر فیلدی به‌دلیل الزام قانونی اجباری است، همان‌جا بگویید چرا. «برای احراز هویت بانکی لازم است» یک جملهٔ کوتاه است که مقاومت کاربر را محسوس کم می‌کند؛ سکوت در این مورد، کاربر را به این نتیجه می‌رساند که دارید داده جمع می‌کنید.

چرا طراحی بد این‌قدر تکرار می‌شود؟

این بخش هم در منبع نیست و به پرسشی جواب می‌دهد که پس از دیدن این مقایسه‌ها پیش می‌آید: اگر تفاوت این‌قدر روشن است، چرا نسخهٔ بد این‌همه ساخته می‌شود؟ دلیل‌ها معمولاً فردی نیستند، ساختاری‌اند:

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

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

جمع‌بندی؛ شش اصل از پنج مقایسه

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

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

منبع

این نوشته بازنویسی آزادی است بر اساس مقالهٔ Bad Design vs. Good Design: 5 Examples We Can Learn From نوشتهٔ Yu Siang Teo، منتشرشده در وب‌سایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF). مفاهیم و درس‌ها از مقالهٔ اصلی است و نگارش فارسی مستقل انجام شده است.

بیشتر تصاویر مقالهٔ اصلی (اسکرین‌شات وب‌سایت‌ها و انیمیشن‌ها) دارای حق نشر اختصاصی‌اند و در این بازنویسی نیامده‌اند. دو تصویر تابلوی پارکینگ با لایسنس آزاد استفاده شده‌اند: © Jorge Gonzalez (CC BY-SA 2.0) و © Nikki Sylianteng (CC BY-NC-SA 4.0).

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

مشاهدهٔ مقالهٔ اصلی با همهٔ تصاویر
سپنتا پویا

مترجم: سپنتا پویا

طراح ارشد محصول. مقالات تخصصی UI/UX را با حفظ ساختار و لحن نسخهٔ اصلی به فارسی برمی‌گردانم.

دربارهٔ من

در این مقاله

  • - سرریز اطلاعات
  • - ناوبری گوشت مرموز
  • - اصطکاک در کنش‌ها
  • - خلاقیت در برابر کاربردپذیری
  • - انیمیشن‌های زائد
  • - متن خطای متهم‌کننده
  • - فرمی که زیادی می‌پرسد
  • - چرا طراحی بد تکرار می‌شود؟
  • - شش اصل نهایی

برچسب‌ها

  • طراحی رابط
  • کاربردپذیری
  • UX
  • ترجمه