مستندات «برنامه‌های کاری» معمولاً به گونه‌ای به پایان می‌رسند که تقریباً هیچ شباهتی به محصول نهایی ندارند. به این دلایل:
ویژگی‌های کاربردی خیالی و فانتزی هستند
آنها بازتاب دهنده واقعیت نیستند. یک برنامه تا قبل از آن که سازنده‌ها آن را بسازند، طراحان آن را طراحی کنند و مردم آن را استفاده کنند، واقعی نیست. ویژگی‌های کاربردی کلماتی بر روی کاغذ هستند.
ویژگی‌های کاربردی برای دلجویی کردن هستند
آنها برای این هستند که همه افراد احساس کنند درگیر هستند که البته چیز مفیدی نیست. آنها هرگز برای گرفتن تصمیمات درست، برآورد هزینه و سایر چیزهایی که برای ساخت یک برنامه عالی مورد نیازند، نیستند.
ویژگی‌های کاربردی به توافقات غیر واقعی منتهی می‌شوند
بسیاری از افراد موافق‌اند که چند بند نوشته شده بر روی کاغذ یک توافق واقعی نیست. همه افراد یک چیز را می‌خوانند ولی چیزهای متفاوتی در ذهن‌شان شکل می‌گیرد. این مسأله ناچار در آینده رخ خواهد داد: «صبر کن، من چیز دیگری تصور می‌کردم.» «ها؟ این چیزی نیست که ما توصیف کرده بودیم.» «بله همین بود و همه ما هم آن را تأیید کرده بودیم، شما حتی آن را امضا کردید.» و این کاملاً معمولی است.
ویژگی‌های کاربردی شما را وامی‌دارد که مهم‌ترین تصمیم‌ها را زمانی بگیرید که کمترین اطلاعات را دارید
وقتی می‌خواهید چیزی را بسازید کمترین اطلاعات را درباره آن دارید. هر چه بیشتر بسازید و بیشتر از آن استفاده کنید، بیشتر آن را می‌شناسید. در این زمان است که باید تصمیم‌های مهم بگیرید، زمانی که اطلاعات بیشتری دارید.
ویژگی‌های کاربردی باعث افزایش ویژگی‌ها می‌شود
در زمان نوشتن ویژگی‌های کاربردی هیچ برگشتی وجود ندارد. نوشتن چیزهای مختلف و اضافه کردن آن به یک متن هیچ هزینه‌ای ندارد. می توانید با اضافه کردن ویژگی های مطلوب یک نفر، خوشحالش کنید. پس طراحی را برای متن فوق به اتمام می‌رسانید نه انسان ها. و این گونه می‌شود که سایتی پر از ویژگی‌ها می‌سازید که در بالای صفحاتش 30 تا قفسه دارد.
ویژگی‌های کاربردی نمی‌گذارد رشد کنید، تغییر کنید و مجدداً ارزیابی کنید
بر روی ویژگی‌ها توافق می‌شود و سپس کنار گذاشته می‌شوند. حتی اگر در زمان توسعه بفهمید که این ایده‌ای اشتباه است باز هم به آن می‌چسبید. ویژگی‌های کاربردی با این واقعیت کاری ندارد که زمانی که ساختن چیزی را آغاز می‌کنید همه چیز تغییر می‌کند.
بنابراین به جای نوشتن ویژگی‌های کاربردی چه باید کرد؟ یک بدل مختصرتر بنویسید که شما را به سمت واقعیت هدایت کند. یک صفحه درباره این که برنامه چه کار باید بکند بنویسید. از زبان ساده و عادی استفاده کنید و به سرعت آن را آماده کنید. اگر آن توصیف بیشتر از یک صفحه طول بکشد، خیلی پیچیده است. این فرایند نباید بیشتر از یک روز طول بکشد.
سپس ساختن ظاهر برنامه را آغاز کنید. این ظاهر می‌تواند بدل «ویژگی‌های کاربردی» باشد. تعدادی طرح‌های کاغذی ساده و سریع بسازید. بعد نوشتن HTML آن طرح‌ها را آغاز کنید. برخلاف بندهای نوشته که هر کسی می‌تواند تفسیر متفاوتی از آن داشته باشد، طراحی‌های ظاهر برنامه چیزی است که هر کسی می‌تواند بر روی آن به توافق برسد.
وقتی که همه با یک صفحه یکسان کار کنند، پریشانی از بین می‌رود. نمایی بسازید که هر کسی بتواند آن را ببیند، استفاده کند، روی آن کلیک کند و آن را «احساس» کند، پیش از آن که بخواهید نگران کدهای پشت آن باشید. تا می‌توانید خود را به تجربه‌های کاربران نزدیک کنید. ویژگی‌های کاربردی را فراموش کنید. آنها شما را می‌دارد که تصمیم‌های مهم و حیاتی را در ابتدای فرایند بگیرید. از مرحله ویژگی‌های کاربردی بگذرید، این کار باعث می‌شود منعطف شوید و تغییرات برای شما ارزان می‌شود.
ویژگی‌های بی‌کاربرد
«ویژگی‌ها» چیزی نزدیک به «بی‌کاربرد» است. من تا به حال هیچ ویژگی‌های کاربردی ندیده‌ام که به اندازه کافی بزرگ باشد که هم مفید و هم دقیق باشد. همچنین فراوان کارهای کاملاً چرندی را دیده‌ام که بر اساس ویژگی‌ها بنا شده‌اند. این روش تنها بدترین روش نوشتن نرم‌افزار است، زیرا بر اساس تعریف، نرم‌افزار نوشته می‌شود تا بر تئوری منطبق شود، نه واقعیت.
لینوس تروالدز، خالق لینوکس (نقل از Linux: Linus On Specifications)
با موانع مقابله کنید
من پی برده‌ام که افرادی که پیش از آغاز هر نوع طراحی، بر مستنداتِ نیازمندی‌هایِ فراوان اصرار می‌کنند، واقعاً «موانعی» هستند که فقط فرایند را کند می‌کنند (و معمولاً این افراد در طراحی هیچ همکاری‌ای نمی‌کنند و فاقد تفکر نوآورانه هستند).
تمام کارهای خوب ما با چندین مفهوم در ذهن درباره بهبود یک سایت، ایجاد یک نمونه اولیه (ایستا)، ایجاد کمی تغییرات در طراحی و بعد از آن ساختن یک نمونه زنده از برنامه با داده‌های واقعی انجام شده است. بعد از کار کردن با این نمونه، ما معمولاً یک پروژه واقعی در حال کار و یک نتیجه خوب داریم.
Mark Gallagher، شرکت توسعه دهنده اینترانت (نقل از Signal vs. Noise)
جلوگیری از «ویژگی‌های کاربردی» شروع خوبی است، ولی نباید در آن متوقف شد. تا می‌توانید همه جا از کاغذبازی جلوگیری کنید. تا زمانی که یک سند واقعاً چیز واقعی معنی‌داری نیست، آن را نسازید.
ننویسید، بسازید. اگر مجبورید چیزی را توضیح بدهید، به جای نوشتن متن طولانی خسته‌کننده، سعی کنید قالبی از آن را بسازید. یک نمای ظاهری یا یک نمونه اولیه، در انتها به یک محصول تبدیل می‌شود. در عوض یک تکه کاغذ در انتها فقط مناسب سطل است.
این هم یک مثال: اگر یک مستند قطور برای این ساخته شده است که هیچگاه مستقیماً به طراحی منجر نشود، خود را با تولید آن به رنج و سختی نیاندازید. اگر مستندی به عنوان یک سند آغاز شده و در انتها به یک طراحی واقعی منجر می‌شود، آن را انجام دهید.
مستنداتی که جدا از برنامه هستند، هیچ ارزشی ندارند. آنها شما را به هیچ کجا نمی‌رسانند. هر چیزی که انجام می‌دهید باید رشد کرده و در انتها به چیزی واقعی تبدیل شود. اگر مستندی قبل از تبدیل شدن به چیزی واقعی متوقف شود، مُرده است.
هیچ‌کس آن را نخواهد خواند
من حتی نمی‌توانم تعداد ویژگی‌های چندین صفحه‌ای محصولات یا مستندات نیازمندی‌های تجاری را که در کنار میز برنامه‌نویس‌های گروهمان پوسیده، خاک خورده و نخوانده رها شده را بشمارم در حالی که در همان زمان ما کد می نوشتیم، درباره مشکلات بحث می کردیم، سؤال می پرسیدیدم و کاربران را می سنجیدیم. من حتا با برنامه نویسانی کار کرده ام که ساعتها ایمیل های طولانی و پر از توضیحات یا استانداردهای کد نویسی می نوشتند که البته آنها هم هیچگاه خوانده نشدند.
برنامه‌های وبی با مستندات کپی شده پیش نمی‌روند. توسعه نرم‌افزار فرایندی نوبتی و تکراری است که شامل تعامل، تصمیم‌های شتاب‌زده و موضوعات پیش‌بینی نشده که در طول کار مشخص می‌شود است. هیچکدام از این‌ها را نمی‌توان یا نباید در کاغذ محصور کرد.
هرگز وقت خود را برای نوشتن مجلدات رویایی تلف نکنید، هیچ‌کس آن را نخواهد خواند.
اگر احساس می کنید باید ویژگی جدید یا مفهومی را توضیح بدهید، داستان کوتاهی درباره آن بنویسید. وارد جزئیات فنی یا طراحی نشوید. آن را به شیوه ای انسانی بیان کنید، همانطور که در یک مکالمه عادی انجام می دهید.
لازم نیست انشا بنویسید.فقط بگویید روال کارها چطور است. و اگر بتوانید خلاصه داستان را در صفحاتی که می سازید قرار دهید که دیگر نور علی نور.
به جای در آغوش گرفتن جزئیات به تجربه ها بچسبید. به استراتژی فکر کنید نه تاکتیک. تاکتیک ها فقط به کار می آیند که ساختن آن قسمت از برنامه را آغاز کنید. الان فقط داستانی تعریف کنید که سر صحبت را باز کرده باشید و در مسیر درست حرکت کنید.
لورم ایپسوم دولور دوست مورد اعتماد طراحان است. متن الکی کمک می کند که مردم بفهمند که طراحی وقتی آماده شد چه شکلی خواهد شد. ولی متن الکی خطرناک هم می تواند باشد.
لورم ایپسوم نحوه دیده شدن متن اصلی را تغییر می دهد. متن را به یک عنصر گرافیکی بصری تقلیل می دهد. شکلی از یک متن به جای آن چیزی که واقعاً باید باشد: اطلاعات ارزشمندی که افراد باید بدانند یا بخوانند.
متن الکی یعنی تغییرات اجتناب ناپذیری که وفتی متن واقعی وارد می شود را نخواهید دید. یعنی نخواهید دانست که فرم پر شده در سایت چطور دیده خواهد شد. متن الکی مانعی است بین شما و واقعیت.
باید متن واقعی داشته باشید تا بدانید طول یک فیلد چقدر باید باشد. برای دانستن نحوه بزرگ یا کوچک شدن جدول ها به متن واقعی نیاز دارید. برای این که بدانید برنامه شما واقعاً چه شکلی است به متن واقعی نیاز دارید.
هر چقدر که می توانید سریعتر از متن واقعی و کلمات مرتبط استفاده کنید. اگر سایت یا برنامه شما نیاز به ورود اطلاعات دارد، اطلاعات واقعی وارد کنید. و واقعاً تایپ کنید نه این که از جایی دیگر متن را از جایی دیگر بجسبانید. اگر نام است، یک نام واقعی تایپ کنید. اگر نام شهر است، نام یک شهر واقعی را تایپ کنید. اگر رمز عبور است و دوبار تکرار شده است، دوبار آن را تایپ کنید.
به نظر می رسد ساده تر است که به سرعت فرمها را با آشغال هایی مثل «asdsadklja» یا «123usadfjasld» یا «snaxn2q9e7» پر کنید تا سریعتر تمام شوند اما باور کنید که صحیح نیست. این کاری نیست که مشتری شما انجام خواهد داد. آیا عاقلانه است که شما از میانبر بروید در حالی که مشتریانتان باید راهی دراز بپیمایند؟ وقتی شما با این شیوه سریع متن های الکی وارد می کنید، نمی فهمید که پر کردن آن فرم واقعاً چه حسی دارد.
همان کاری را بکنید که مشتریانتان انجام می دهند تا آنها را بهتر درک کنید. وقتی آنها را بهتر درک کنید و همان حسی را داشته باشید که آنها دارند، بهتر طراحی می کنید.
لورم ایپسوم آشغال
بدون داشتن هیچ تصوری از این که محتوا «ممکن» است چه شکلی باشد، اهمیت طراحی را از دست می دهید. با این فرض که «فقط یک نوشته است»، معنا مبهم می شود، فهم پذیری به خطر می افتد چون هیچ کس نخواهد دانست که باید این متن ها را بخواند. لورم ایپسوم آشغالی که به جای محتوای واقعی استفاده می کنید، باعث می شود فرصت ها تبدیل به تهدید شوند. متن ها کوتاه می شوند چون قرار نیست از آنها استفاده شود. همچنین احتمالاً انبوهی از فضاهای سفید دوست داشتنی باید در میان آنها قرار دهیم.
Tom Smith، طراح و برنامه نویس (نقل از I hate Lorem Ipsum and Lorem Ipsum Users)
به محصول خود به عنوان یک انسان فکر کنید. دوست داری چه شخصیتی داشته باشد؟ مؤدب؟ عبوس؟ سخاوتمند؟ مجکم؟ خشک و بی روح؟ جدی؟ شُل و وارفته؟ می خواهید بیمار روانی دیده شود یا قابل اعتماد؟ یا همه چیز دان؟ متواضع؟ دوست داشتنی؟
یکبار که تصمیم گرفتید همانطور که محصول را می سازید، همیشه رفتارهای آن شخصیت را در نظر داشته باشید. از آنها برای نوشتن، رابط کاربری و مجموعه ویژگی ها استفاده کنید. هر زمانی که تغییری ایجاد می کنید از خودتان برسید که آیا آن تغییر با شخصیت برنامه متناسب است یا نه؟
محصولتان صدایی دارد و 24 ساعت شبانه روز با مشتریها حرف می زند.
