پیش از آنکه هزاران خط کد نوشته شود، محصول را بسازید، لمس کنید و بسنجید. این دقیقاً کاری است که وایرفریم و پروتوتایپ انجام میدهند: ایدهٔ ذهنی را به چیزی قابلدیدن و قابلآزمودن تبدیل میکنند، پیش از آنکه هزینهٔ واقعیِ توسعه روی میز بیاید. تیمهایی که این مسیر را رعایت میکنند، کمتر دوبارهکاری میکنند و محصولِ درستتری تحویل میدهند. در این راهنمای وبلاگ پبدپ، پلههای این مسیر را از طرح اولیه تا نمونهٔ تعاملی میپیماییم؛ اجرای حرفهای آن در سرویس طراحی وایرفریم و پروتوتایپ انجام میشود.
۱) چرا اصلاً این مسیر
یک طرح روی کاغذ، ارزان است؛ همان طرح بعد از کدنویسی، گران. وایرفریم و پروتوتایپ، راهِ ارزانِ اشتباهکردناند: پیش از ساخت، ایراد را میبینید و اصلاح میکنید. این، همان چیزی است که ریسک پروژه را بهشدت پایین میآورد.
۲) با جریان و هدف شروع کنید
قبل از هر جعبهای، بفهمید کاربر چه مسیری را باید طی کند و به چه مقصدی برسد. این را از یافتهٔ پژوهش کاربر و از معماری اطلاعات درست بگیرید؛ سرویس معماری اطلاعات همین پایه را میسازد. بدون نقشهٔ جریان، وایرفریم فقط نقاشیِ جعبه است.
۳) وایرفریم کمجزئیات، سریع و بیرحم
در مرحلهٔ اول، عمداً زشت و ساده بکشید: خاکستری، بدون رنگ و عکسِ واقعی. هدف، تمرکز روی ساختار و منطق است نه زیبایی. وقتی جزئیات بصری نباشد، همه روی سؤال مهم بحث میکنند: آیا این مسیر کار میکند؟
۴) جریان صفحهها را وصل کنید
صفحهها تنها نیستند؛ کاربر از یکی به دیگری میرود. بافلوها، منوها و مسیرهای بازگشت را روشن بچینید و حالتهای مختلف را فراموش نکنید: حالت خالی، حالت خطا و حالت بارگذاری. همان چیزی که اغلب نادیده گرفته میشود و بعد، مشتری را غافلگیر میکند.
۵) زود نشان دهید، زود بازخورد بگیرید
وایرفریم را در انباکسِ خودتان نگه ندارید. زود به کاربر و ذینفعان نشان دهید و نقد بگیرید. هرچه دیرتر بازخورد بگیرید، اصلاح گرانتر است. فرهنگ نمایشِ زودِ طرحهای ناقص، تیم را چابک میکند.
۶) به پروتوتایپ میانی برسید
وقتی ساختار تثبیت شد، کلیکپذیرش کنید: صفحهها را با لینک به هم وصل کنید تا جریان را بتوان طی کرد. اینجا دیگر بحثهای انتزاعی تمام میشوند؛ همه «حس» میکنند محصول چگونه کار میکند و کجا لنگ میزند.
۷) پروتوتایپ تعاملی، شبیهسازی واقعی
یک نمونهٔ تعاملی، حرکتها، بازخوردها و پر شدنِ فرمها را نشان میدهد. این نسخه، پیش از کدنویسی، همان چیزی است که با آن تست کاربرد انجام میدهید و به توسعهدهنده تحویل میدهید. هرچه به محصول نهایی نزدیکتر، فهم مشترک بیشتر.
۸) جزئیات بصری را دیر اضافه کنید
رنگ، لوگو، عکس و تایپوگرافی را به مرحلهٔ پایانی بگذارید، نه اول. اول منطق، بعد زیبایی؛ وگرنه همه سرِ رنگِ دکمه بحث میکنند و ساختارِ غلط از نظر میرود. طراحی بصری را روی اصول رابط کاربری سوار کنید.
۹) با تست کاربرد، اعتبار بگیرید
پروتوتایپ را به دست کاربر واقعی بدهید و ببینید کجا گیر میکند. تست کاربردپذیری روی نمونه، ارزانترین راه یافتن ایراد است. هر اشکالی که اینجا پیدا شود، یعنی یک فاجعهای که در کد رخ نداده است.
۱۰) سندگذاری برای تیم فنی
طرح، بدون توضیح، ناقص است. رفتار هر عنصر، حالتها، پیامها و قواعد را برای تیم توسعه بنویسید. این سند، اختلافِ برداشت را کم میکند و کیفیت پیادهسازی را بالا میبرد؛ پایهٔ همان تحویل در چرخهٔ توسعهٔ محصول.
۱۱) روی موبایل و دسکتاپ جدا فکر کنید
یک طرح، چند اندازه. مسیر انگشتی موبایل با دسکتاپ فرق دارد. وایرفریم را برای هر شکلبندی جدا بکشید تا هیچ نسخهای قربانی دیگری نشود؛ این دقت، در مرحلهٔ توسعه جلوی بسیاری از بازگشتها را میگیرد.
۱۲) نسخهگذاری و تغییرات
طرح، زنده است و عوض میشود. نسخهها را نگه دارید و دلیل هر تغییر را یادداشت کنید. این نظم، به تیم اجازه میدهد عقب برگردد، درس بگیرد و بحثهای تکراری را تکرار نکند.
۱۳) بازخورد را ثبت و اولویت کنید
همهٔ نقدها را جمع و بر پایهٔ اثر و هزینه دستهبندی کنید. هر ایرادی را که کاربر میگیرد، اصلاحِ فوری لازم نیست؛ اول آنچه مسیر اصلی را میبندد درست کنید. این فیلتر، تیم را از پراکندگی نجات میدهد.
۱۴) با سیستم طراحی همراستا شوید
اگر محصول شما سیستم طراحی دارد، وایرفریم و پروتوتایپ را با همان اجزا بسازید. این کار سرعت را چند برابر میکند و فاصلهٔ طرح تا پیادهسازی را به حداقل میرساند.
۱۵) تحویل به توسعه، نه رها کردنِ طرح
پروتوتایپِ خوب، نصف راهِ توسعه است. کنار تیم بنشینید، نمونه را زنده نشان دهید و به سؤالها پاسخ دهید. یک تحویل دقیق، ماهها دوبارهکاری را جلو میگیرد.
۱۶) مسیر، ارزشش را دارد
از وایرفریم تا پروتوتایپ، تنبلیِ زودرس را از پروژه بیرون میکند و جای آن را فهم مشترک و محصولِ درستتر میگیرد. این مسیر، پلِ میان ایده و واقعیت است؛ پلی که در سرویس وایرفریم و پروتوتایپ ما، محکم ساخته میشود.
سؤالات متداول
چقدر قبل از کدنویسی وقت بگذاریم؟ بهاندازهای که جریان و خطرهای اصلی روشن شوند؛ معمولاً چند برابرِ چیزی که تیمها غریزی صرف میکنند، ارزش دارد.
پروتوتایپ باید کامل باشد؟ نه؛ فقط آنقدر که سؤال واقعی را پاسخ دهد. کاملبودن، دشمنِ سرعت است.
ابزار مهم است؟ تا حدی؛ مهمتر از ابزار، روش و ترتیبِ درست است.
برای طی کردنِ این مسیر تا یک محصول تحویلیِ درست، پروژهٔ خود را برای ما تعریف کنید و نمونهکارها را در پورتفولیو ببینید.
فارسی
English
دیدگاهها
هنوز دیدگاهی برای این نوشته ثبت نشده است.
دیدگاه خود را بنویسید