چرا طراحی خوب یک مهارت فنی است

در طول سال‌ها با طراحان فوق‌العاده‌ای کار کرده‌ام. کسانی که پیوسته کاری تولید می‌کردند که واقعاً عرضه می‌شد — کاری که در QA از هم نمی‌پاشید، کاری که رفت‌وبرگشت‌های بی‌پایان با تیم توسعه ایجاد نمی‌کرد — همه یک ویژگی مشترک داشتند: مثل مهندس فکر می‌کردند.

و بهترین مهندس‌هایی که می‌شناسم؟ مثل طراح فکر می‌کنند.

شکاف کاذب

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

نتیجه: طراحان مکاپ‌هایی تحویل می‌دهند که فیزیک وب را نادیده می‌گیرند. مهندسان آن‌ها را طوری پیاده می‌کنند که نیت طراحی را نادیده می‌گیرد. هر دو طرف ناامید می‌شوند. محصول آسیب می‌بیند.

«فکرکردن فنی» برای طراحان یعنی چه

یعنی یادگرفتن کدنویسی نیست (هرچند کمک می‌کند). یعنی:

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

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

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

یک محدودیت واقعی، نه فرضی

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

«مثل طراح فکرکردن» برای مهندسان یعنی چه

یعنی به‌اندازه‌ی کافی آهسته‌کردن تا بپرسید: آیا این برای یک انسان معنا دارد؟

// غریزه‌ی اول یک مهندس:
const errorCode = response.status === 422
  ? "VALIDATION_ERROR"
  : "UNKNOWN_ERROR";

// کاری که یک طراح-مهندس انجام می‌دهد:
const errorMessage = response.status === 422
  ? "لطفاً فیلدهای هایلایت‌شده را بررسی کنید و دوباره تلاش کنید."
  : "مشکلی پیش آمد. صفحه را رفرش کنید یا با پشتیبانی تماس بگیرید.";

نسخه‌ی دوم حدود ۳۰ ثانیه بیشتر برای نوشتن هزینه دارد. تفاوت تجربه‌ی کاربری‌اش عظیم است.

همچنین یعنی اهمیت‌دادن به سلسله‌مراتب بصری در خروجی خودتان. پیام‌های خطا. لاگ‌های کنسول. مستندات. توضیحات pull request. همه‌ی این‌ها مسائل UX هستند.

اهرم

نتیجه‌ی عملی این‌جاست: اگر بتوانید فراتر از مرز فکر کنید، ۱۰ برابر مؤثرتر می‌شوید.

می‌توانید کار خودتان را spec کنید. می‌توانید پیش از این‌که مشکلات گران شوند، آن‌ها را بگیرید. می‌توانید بدون نیاز به مترجم، با رشته‌ی دیگر گفت‌وگو کنید.

در تیم‌های کوچک، این بسیار ارزشمند است. در یک استارتاپ، طراح-مهندس (یا مهندس-طراح) اغلب سلاح مخفی است.

از کجا شروع کنیم

اگر طراح‌اید: به‌اندازه‌ی کافی CSS یاد بگیرید تا نمونه‌های اولیه‌ی خودتان را بسازید. نه کد production — نمونه‌ی اولیه. CodePen دوست شماست. بلافاصله شروع می‌کنید طور دیگری طراحی کنید.

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

این هم‌پوشانی تهدیدی برای هیچ‌کدام از دو رشته نیست. این‌جایی است که بهترین کارها زندگی می‌کنند.

پرسش‌های پرتکرار

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

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

اگر دارید فکر می‌کنید یک تیم به کسی نیاز دارد که هر دو زبان را بفهمد — خدمات من را ببینید، یا تماس بگیرید.