بسیاری برنامه‌ها با ذهنیت برنامه‌نویسی آغاز می‌شوند. این روش خوبی نیست. برنامه‌نویسی سنگین‌ترین جزء ساختن یک برنامه است. معنی این حرف این است که برنامه‌نویسی گران‌ترین و سخت‌ترین چیز برای تغییر است. به جای آن سعی کنید با طراحی ظاهر برنامه آغاز کنید.
طراحی نسبتاً کم حجم است. یک طرح کاغذی بسیار ارزان و تغییر دادن آن بسیار ساده است. تغییر (یا حتی دور ریختن) فایل‌های HTML هم هنوز نسبتاً ساده است. ولی این مورد برای برنامه‌نویسی درست نیست. ابتدا ظاهر را طراحی کردن شما را منعطف نگه می‌دارد. ابتدا برنامه‌نویسی کردن شما را در حصاری محدود می‌کند و هزینه‌های زیادی را به شما تحمیل می‌کند.
دلیل دیگر برای طراحی ظاهر در ابتدا، این است که این ظاهر، خود محصول است. مردم چیزی را که شما می‌فروشید می‌بینند. اگر ظاهر را به آخر کار موکول کنید، این شکاف نمایان می‌شود.
ما با طراحی ظاهر آغاز می‌کنیم بنابراین از همان ابتدا می‌توانیم محصول را ببینیم و احساس کنیم. این طراحی به طور پیوسته در طول کار بازبینی می‌شود. آیا فهم آن ساده است؟ آیا استفاده از آن ساده است؟ آیا مشکل منظور ما را حل می‌کند؟ این‌ها سؤال‌هایی است که شما وقتی می‌توانید به درستی به آنها پاسخ دهید که با صفحات واقعی سر و کار داشته باشید. نخست طراحی کردن شما را منعطف می‌کند و باعث می‌شود زودتر به چنین پرسش‌هایی برسید.
خودکار اُرنجی که Blinksale را آغاز کرد
زمانی که از نرم‌افزارهای صورت‌حساب‌گیری موجود در بازار ناامید شدم، تصمیم گرفتم که ببینم نرم‌افزار صورت‌حساب‌گیری مطلوب من چه شکلی باید باشد. یک خودکار اُرنجی را که در آن عصر تنها چیزی بود که دم دست بود، برداشتم و در کمتر از چند ساعت 75 درصد از طراحی ظاهر برنامه را کشیدم. آن را به همسرم راشل که در حال اتو کردن بود نشان دادم و پرسیدم: «نظرت چیست؟» با لبخندی پاسخ داد: «تو باید این کار را انجام بدهی، واقعی آن را.»
در دو هفته بعد از آن طرح‌ها را تصحیح کردم و تقریباً تمام صفحات ایستای html چیزی را که قرار بود نسخه اول Blinksale شود، ساختم. ما هیچ کار خاصی در پشت آن طرح‌های اولیه انجام ندادیم و مستقیماً سراغ طراحی html رفتن به ما کمک کرد تا از دانستن نحوه عملکرد پروژه «واقعی» هیجان زده شویم، با این که در آن لحظه واقعاً نمی‌دانستیم چه می‌کنیم.
وقتی که طراحی‌های html تمام شد، ما با ایده‌های Blinksale پیش برنامه‌نویس‌مان اسکات رفتیم. ظاهر برنامه طراحی شده از چند لحاظ برای ما مفید بود. اول از همه این که به اسکات یک منظره از برنامه نشان داد و این که او را نسبت به کاری که می‌خواستیم بکنیم هیجان زده کرد. آنها بیشتر از یک ایده بودند، چیزهایی واقعی. دوم این که به ما کمک کرد به دقت بفهمیم که تبدیل این طراحی به برنامه در حال کار به چه میزان کار و زمان اسکات نیاز داشت. زمانی که شما می‌خواهید یک پروژه اقتصادی را شروع کنید، هر چه زودتر بودجه مورد نیاز را بدانید بهتر است. طراحی ظاهر برنامه محکی شد برای محدوده اولیه پروژه. در پایان، طراحی ظاهر برنامه، همانطور که ما در توسعه برنامه پیش می‌رفتیم، به ما یادآوری می‌کرد که برنامه قرار است چه چیزی باشد. هر زمان که وسوسه می‌شدیم ویژگی‌های جدیدی به برنامه اضافه کنیم، نمی‌توانستیم به سادگی بگوییم «باشد، این را هم اضافه کنیم». ما مجبور بودیم به طراحی‌ها برگردیم و از خودمان بپرسیم که این ویژگی‌های جدید قرار است کجا قرار بگیرند و اگر جایی برای آنها نبود، آنها را اضافه نمی‌کردیم.
Josh Williams، پایه‌گذار Blinksale
طراحی هستهای، بر ماهیت اصلی صفحه –هسته صفحه- متمرکز می‌شود و بعد به سمت بیرون شروع به ساختن می‌کند. معنی این حرف است که در شروع کار از مسائل نهایی از قبیل راهبری/کارت (تب)ها، پایین‌نویس، رنگ‌ها، نوارهای کناری، نمادها و ... چشم‌پوشی کنید. در عوض از مرکز شروع می‌کنید و مهم‌ترین قطعات محتوا را طراحی می‌کنید.
چیزی که یک صفحه بدون آن زنده نخواهد ماند، مرکز آن است. برای مثال اگر شما صفحه‌ای را طراحی می‌کنید که قرار است مطالب یک بلاگ را نمایش دهد، آن مطلب وبلاگ، مرکز صفحه است، نه دسته‌بندی‌ها در نوار کناری و بالانوشت در بالای صفحه و پرسشنامه توضیحات در پایین، بلکه فقط مطلب وبلاگ. بدون مطلب ارسال شده، صفحه یک مطلب وبلاگ نیست.
فقط وقتی که این بخش کامل شد، می‌توانید به دومین قسمت مهم صفحه بپردازید. بعد از دومین قسمت مهم می‌توانید به سومین بپردازید و به همین ترتیب. طراحی هستهای این است.
طراحی هستهای از طراحی به شیوه «بگذار قالب را درست کنیم و محتوا را توی آن بریزیم» اجتناب می‌کند. در چنین شیوه‌ای ابتدا شکل صفحه ساخته می‌شود، بعد راهبری به آن افزوده می‌شود، بعد خرت و پرت‌های بازاریابی وارد می‌شود و در نهایت قسمت اصلی، هدف اصلی صفحه در فضاهای خالی چپانده می‌شود. این روش، عقبگرد است و چیزهایی با بیشترین اهمیت را به انتهای کار می‌اندازد.
طراحی هستهای فرایند را معکوس می‌کند و اجازه می‌دهد در اولین روزها بر روی چیزهایی که واقعاً مهم‌اند متمرکز شوید. اول چیزهای اساسی و مهم و بعد سایر چیزها. نتیجه، صفحه‌ای دوستانه‌تر، متمرکز و قابل استفاده برای کاربر است. همچنین این روش اجازه می‌دهد که با ارتباط بین طراح و برنامه‌نویس آغاز کنید و نمی‌گذارد که تا انتهای کار پیش بروید و بعد برگردید به اول کار.
برای هر صفحه، سه حالت را باید در نظر بگیرید:
حالت عادی معقول است. این صفحه جایی است که بیشترین زمان خود را در آن می‌گذرانید. ولی از وقت گذاشتن بر سایر حالت‌‌ها غفلت نکنید (برای بیشتر دانستن در این باره، مطالب بعدی را بخوانید).
چشم‌پوشی از مرحله تخته خالی یکی از بزرگترین اشتباهاتی است که ممکن است مرتکب شوید. خودتان هم می‌دانید که تخته خالی اولین تأثیر برنامه شما است و هرگز این موقعیت تکرار نمی‌شود.
مشکل این است که در حین طراحی، معمولاً ظاهر برنامه همراه با داده است. طراحان اغلب الگوها را با داده‌ها پر می‌کنند. هر فهرستی، هر مطلبی، هر ورودی، هر برآمدگی و هر شکافی دارای چیزهایی است. و معنی آن این است که صفحه به خوبی نمایش داده شده و کار می‌کند.
با این حال، حالت طبیعی برنامه، حالتی است که عاری از داده است. وقتی کسی ثبت نام می‌کند، با تخته خالی آغاز می‌کند. بسیار شبیه یک وبلاگ، پر کردن آن بر عهده آنها است: ظاهر کلی برنامه تا زمانی که مردم داده‌ها (مطالب ارسالی، پیوندها، توضیحات، ساعت‌ها، اطلاعات نوار کناری یا هر چیز دیگر) را وارد نکنند، شکل نمی‌گیرد.
متأسفانه مشتری درباره ارزش برنامه در همین مرحله تخته خالی تصمیم می‌گیرد: مرحله‌ای که کمترین میزان اطلاعات، طراحی و محتوا برای داوری درباره سودمند بودن برنامه وجود دارد. وقتی که در طراحی تخته خالی مفید و کافی مرتکب اشتباه می‌شوید، مردم نمی‌دانند که چه چیزی را از دست می‌دهند، زیرا همه چیز از دست رفته است.
با وجود این، هنوز هم اغلب طراحان و برنامه‌نویسان این موضوع را جدی نمی گیرند. آنها در اختصاص زمان برای طراحی مرحله تخته خالی مرتکب اشتباه می‌شوند زیرا زمانی که آنها برنامه‌نویسی می‌کنند یا از برنامه استفاده می‌کنند، برنامه پر از اطلاعاتی است که آنها برای مقاصد آزمون برنامه وارد کرده‌اند. آنها حتی به تخته خالی برخورد هم نمی‌کنند. مطمئن باشید، آنها چندین بار بیشتر به عنوان کاربر جدید وارد نمی‌شوند ولی اغلب اوقات آنها به شنا کردن در برنامه‌ای می‌گذرد که پر از داده‌ها است.
چه چیزهایی را باید در مرحله تخته خالی کمکی قرار داد.
اولین خاطره‌ها حیاتی هستند. اگر شما در طراحی تخته خالی هوشمند خطایی مرتکب شوید، تصویر و خاطره‌ای منفی از برنامه یا خدمات خود ایجاد می‌کنید.
شما هرگز اقبال مجدد نخواهید داشت
جنبه دیگری از طراحی Mac OS x که به گمان من به شدت متأثر از (استیو) جابز بوده است، نصب و اولین اجرای آن است. من فکر می‌کنم که جابز زیرکانه از اهمیت اولین خاطره‌ها آگاه است ... من گمان می‌کنم جابز به اولین تجربه افراد نگاه می‌کند و با خودش می‌گوید این ممکن است یک هزارم کل تجربه کاربر با این ماشین باشد، ولی مهم‌ترین یک-هزارم است، چون اولین یک-هزارم است و همین تجربه است که توقعات و اولین احساس‌ها را به وجود می‌آورد.
John Gruber، نویسنده و برنامه‌نویس وب (نقل از Interview with John Gruber)
بیایید بپذیریم که در حالت برخط خطا رخ می‌دهد. اصلاً فرقی نمی‌کند که چقدر با دقت برنامه را طراحی کنید یا این که چقدر آن را بیازمایید، مشتریان باز هم به خطا برمی‌خورند. پس با این از کار افتادگی‌ها چطور برخورد می‌کنید؟ با طراحی تدافعی.
طراحی تدافعی مثل رانندگی تدافعی است. رانندگانی که در یک مسیر حرکت می‌کنند همواره باید مراقب لغزندگی‌های سطح جاده، راننده‌های بی‌احتیاط و سایر مسائل خطرناک باشند. طراحان سایت باید همیشه به دنبال نقاط دردسرسازی باشند که باعث گیجی و ناامیدی بازدیدکنندگان می‌شود. دفاع خوب باعث ساخته شدن یا تغییر کردن تجربه کاربر می شود.
می‌توانیم برای همه چیزهای دیگری که درباره طراحی تدافعی باید بگوییم، کتاب دیگری بنویسیم. واقعیت این است که این کار را کرده‌ایم. عنوان آن «طراحی تدافعی برای وب» است و برای کسانی که می‌خواهند یاد بگیرند چگونه صفحات خطا و سایر نقاط بحرانی را اصلاح کنند، مرجعی عالی است.
به یاد داشته باشید: برنامه شما شاید در 90 درصد مواقع بسیار عالی کار کند، ولی اگر مشتریان را در زمان نیازشان رها کنید، بعید است آن را فراموش کنند.
آیا عملیات باید به شکل پیوند باشد یا دکمه؟ بستگی به عملیات دارد. آیا نمایش تقویم باید به شکل فهرست باشد یا شبکه‌ای؟ بستگی به محل نمایش و طول مدت زمان چقدر است. آیا هر پیوند راهبری سرتاسری باید در همه صفحات باشد؟ آیا در همه صفحات به نوار جستجوی سرتاسری نیاز دارید؟ آیا باید پایین‌نویس همه صفحات یکسان باشد؟ پاسخ این است: «بستگی دارد».
به این دلیل است که متن از سازگاری مهم‌تر است. خوب است اگر طراحی شما ایجاب می‌کند، برنامه شما ناسازگار باشد. به افراد چیزهایی را بدهید که مهم است. به افراد چیزهایی را که نیاز دارند در زمانی که به آنها نیاز دارند بدهید و چیزهای دیگر را که به آنها نیاز ندارند دور بریزید. بهتر است به جای سازگار بودن، خوب باشید.
ناسازگاری هوشمندانه
سازگار بودن ضروری نیست. در طول سالیان دانشجویان نمای کاربری (UI) و تجربه کاربری (UX) فکر می‌کردند که سازگاری در ظاهر برنامه یکی از قوانین بنیادی طراحی نمای برنامه است. شاید این موضوع در نرم‌افزار درست باشد ولی در وب درست نیست. چیزی که در وب مهم است این است که در هر صفحه کاربر به سرعت و به سادگی به مرحله بعد در فرایند هدایت شود.
در Creative Good ما آن را « ناسازگاری هوشمندانه» می‌نامیم، یعنی: هر صفحه در فرایند به کاربر دقیقاً همان چیزهایی را می‌دهد که در آن مرحله از فرایند به آن نیاز دارند. افزودن عناصر راهبری زائد فقط به این دلیل که با سایر قسمت‌های سایت سازگار باشید احمقانه است.
Mark Hurst، بنیان گذار Creative Good و سازنده Goovite.com (نقل ازThe Page Paradigm)
نوشته ها همان طراحی اند. بزرگترین طراحی ها نوشته می شوند. اگر فکر می کنید هر پیکسل، هر آیکون، هر فونت مهم است، پس باید بپذیرید که هر حرف هم مهم است. وقتی طراحی را می نویسید، خود را به جای کسانی بگذارید که طراحی شما را می خوانند. چه چیزی باید بدانند؟ چطور می توانید آن را موجز و آشکار بیان کنید؟
برای یک دکمه از عنوان «ارسال» یا «ذخیره» یا «بروزرسانی» یا «جدید» یا «ایجاد» استفاده می کنید؟ نوشتن یعنی این. سه جمله می نویسید یا پنج جمله؟ آیا از مثالهای کلی برای توضیح استفاده می کنید یا وارد جرئیات می شوید؟ آیا محتوای خود را با یکی از «جدید» یا «بروز شده» یا «اخیراً بروز شده» یا «تغییر کرده» برچسب می زنید؟ آیا می نویسید «پیام های جدیدی رسیده است: 5» یا «5 پیام جدید رسیده است»؟ «5» می نویسید یا «پنج»؟ «پیام ها» یا «مطالب»؟ همه این ها مهم اند.
باید به زبان مخاطبانتان صحبت کنید. این که شما برنامه نویس وب هستید دلیل نمی شود از اصطلاحات فنی استفاده کنید. به مشتری ها فکر کنید و این که آن دکمه ها و کلمات چه معنی ای برای آنها دارد. از سرواژه ها و کلماتی که اغلب آدمها نمی دانند استفاده نکنید. از زبان صنفی استفاده نکنید. شبیه یک مهندس که با مهندس دیگری صحبت می کند نباشید. کوتاه و شیرین صحبت کنید. فقط به قدر ضرورت بگویید نه بیشتر.
خوب نوشتن، خوب طراحی کردن است. به ندرت پیش می آید که کلمات همراه طراحی نباشند. آیکون ها با نام ها، عناصر فرم با مثال ها، دکمه ها و عناوین، دستورالعمل های مرحله به مرحله در یک فرایند، توضیح شفاف سیاست های بازگرداندن پول، همه این ها طراحی هستند.
صفحه‌های مدیریتی (صفحه‌های مدیریت اختیارات و ترجیحات، کاربران و غیره) معمولاً مزخرف و چرند هستند. علت این است که بیشتر زمان توسعه برنامه به نمای عمومی برنامه اختصاص می‌یابد.
برای جلوگیری از بیماری «صفحه‌های مدیریتی چرند»، برای کارهای مدیریتی (ویرایش، اضافه، حذف و ...)، صفحه‌های متفاوتی ایجاد نکنید. بلکه آنها را در نمای ظاهری عمومی برنامه قرار دهید.
اگر بخواهید دو ظاهر مختلف را نگهداری کنید (مثلاً یکی برای کارهای عادی و یکی برای کارهای مدیریتی) هر دو آسیب خواهند دید. در اثر این کار، شما یک مالیات را دو بار خواهید پرداخت. شما مجبورید خودتان را تکرار کنید و این باعث می‌شود که به‌هم‌ریختگی و نامرتبی شما بیشتر شود. هر چه با صفحات کمتری درگیر شوید، به نتیجه‌های بهتری می‌رسید.
نماهای ظاهری متفاوت، هرگز
برنامه همه چیز است. هر چیزی را که تغییر می‌کند، اضافه می‌شود یا متناسب می‌شود، می‌توان از قسمت مدیریت برنامه انجام داد. این کار به ما اجازه می‌دهد دقیقاً همان چیزی را که مشتری می‌بیند، ببینیم و بتوانیم در هنگام برخورد با مشکل یا سؤال به آنها کمک کنیم. همچنین مشتریان ما نگران ورود به نماهای ظاهری متفاوت برای انجام کارهای خود نیستند. آنها ممکن است یک دقیقه مشغول کار با قرار ملاقات‌ها با مشتریان باشند و چند دقیقه بعد بخواهند یک کارمند جدید را در سیستم ثبت کنند. آنها از پریدن به یک برنامه دیگر آزرده نخواهند شد. یکسان بودن نمای ظاهری برنامه باعث می‌شود سریع‌تر با برنامه سازگار شوند.
Edward Knittel، مدیر بازاریابی و فروش در KennelSource
