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

مشخصات طراحی (Design Specifications) چیست؟

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

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

این نوشته دربارهٔ آن است: مشخصات چیست، منبع چه فهرستی برایش می‌دهد، و کدام بخش‌ها واقعاً ارزش نوشتن دارند.

تعریف

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

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

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

هفت نقشی که منبع برایش می‌شمارد

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

چه‌کسی می‌نویسد و شامل چه چیزهایی است

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

و شش دستهٔ محتوایی که می‌تواند اضافه شود:

• - ۱. طراحی بصری: پالت رنگ · تایپوگرافی (قلم، اندازه، سبک برای هر عنصر) · آیکون‌نگاری و مشخصات بصری‌شان.
• - ۲. چیدمان: سیستم شبکه‌ای · فاصله‌گذاری (اندازهٔ دقیق حاشیهٔ درونی و بیرونی) · واکنش‌گرایی و نحوهٔ سازگاری با اندازه‌های مختلف.
• - ۳. طراحی تعامل: مشخصات دکمه و فیلد و منو · ریزتعامل‌ها و رفتار عناصر تعاملی مثل انیمیشن و گذار · و پاسخ سیستم به کنش کاربر.
• - ۴. محتوا: متن دقیق و لحن و سبک · مشخصات تصویر و ویدیو و صدا.
• - ۵. دسترس‌پذیری: رهنمودها و انطباق با استانداردهایی مثل WCAG.
• - ۶. مشخصات فنی: قالب و اندازهٔ فایل‌ها، مرورگرهای پشتیبانی‌شده و مانند آن.

مشخصات، شرط‌بندی روی چیزی است که عوض نمی‌شود

این بخش افزودهٔ مترجم است.

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

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

درمانش ساده و ارزان است: هر بند یک برچسب قطعیت بگیرد. سه سطح کافی است:

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

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

آنچه فایل طراحی نمی‌تواند بگوید

این بخش هم افزودهٔ مترجم است، و فهرست شش‌دستهٔ منبع را بازچینی می‌کند.

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

پس قاعدهٔ اول: چیزی که از فایل درمی‌آید، در سند تکرار نمی‌شود. عددها در سیستم طراحی و توکن‌ها زندگی می‌کنند، نه در نوشته.

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

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

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

«پرهیز از خزش دامنه» خطرناک‌ترین بند منبع است

و بخش سوم مترجم، دربارهٔ نقش ششم آن فهرست.

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

تفکیکی که این تعارض را حل می‌کند:

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

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

در بافت فارسی: ارقام، تقویم، و جدول واژه‌ها

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

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

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

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

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

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

جمع‌بندی

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