مدل دو الماس (Double Diamond) چطور در فرایند طراحی به ما کمک میکند؟

این مدل توسط شورای طراحی بریتانیا در سال 2005 ارائه شد و به صورت واضح به ما پروسه دیزاین رو نمایش می­ده. به خصوص در حیطه یواکس دیزاین این امکان رو فراهم می­ کنه که نیاز­های کاربر رو بفهمیم و بهشون پاسخ بدیم.این مدل شامل 4 مرحله است:1- Discover (کشف)2- Define (تعریف)3- Develop (توسعه)4- Deliver (تحویل و تست)مرحه اول، کشف (Discover)هر پروژه ­ای از یک نقطه شروع می­شه که این نقطه شروع، ممکنه برای هر پروژه متفاوت باشه. ممکنه ایده طراحی یک محصول جدید باشه یا توسعه و ارتقای یک محصول موجود. در این مرحله طراحان با تحقیقات مختلف باید دلایل به وجود آمدن مشکل رو پیدا کنند. این مرحله به­ صورت واگرا یا (Divergent) هست و باید از روش­ های مختلف برای جمع­ آوری اطلاعات و فهمیدن مشکل استفاده کرد.در این فاز تمرکز روی کاربران هست و هدف اینه که اولویت­ ها، انگیزه ­ها و مشکلاتشون رو بفهمیم. می تونیم از ترکیبی از متودهای یوزر ریسرچ استفاده کنیم تا بهترین نتیجه رو بگیریم. توی این مرحله باید حواسمون باشه که پیش­ فرض­ ها رو کنار بگذاریم و بدون جانبداری شروع به بررسی کنیم.درسته که این یک مرحله واگراست و قراره اطلاعات زیادی به دست بیاریم اما حواستون باشه زیاده­ روی نکنید. دریافت اطلاعات تمومی نداره و همیشه یه موضوعی برای کشف جزئیات بیشتر هست، پس بهتره یه دِدلاینی برای این کار در نظر بگیریم تا زیاد از حد در این مرحله غرق نشیم.مرحله دوم، تعریف (Define)حالا نوبت تعریف مشکل اصلی (core problem) هست.ممکنه به کمک اطلاعاتی که از مرحله قبل به دست آوردید، مشکلات و مسائل جدیدی پیدا کرده باشید که با تعریف اولیه که در ذهن داشتید متفاوت باشه. در این مرحله (تعریف) مهمه که مشخص کنید مشکل اصلی شما کدومه. مثلا ممکنه موضوعی که زیاد سراغش نرفته بودید پتانسیل بیشتری برای بهتر کردن تجربه کاربر داشته باشه. باید اطلاعات مرحله قبل رو طوری طبقه بندی و بررسی کنید تا به یک تعریف مشخص برسید.برای دسته بندی اطلاعات می­ تونید از پین بوردها و کاغذ های پست­ ایت استفاده کنید. تا راحت موارد مختلف رو نشون بدید و جابجا کنید.برای این کار می­ تونید از پلتفرم میرو هم استفاده کنید.در این مرحله اولویت بندی مهمه. در فاز اول خیلی واگرا نسبت به ایده­ ها برخورد کردیم حالا باید همگراتر عمل کنیم و یه تعریف درست داشته باشیم. خطرناکه که بخوایم همه مشکلات رو مثل یه پکیج در نظر بگیریم و بخوایم یه راه حل برای حل کردن همشون ارائه بدیم! چون در آخر یه راه حل ضعیف خواهیم داشت که میخواد همزمان چندتا مشکل رو حل کنه اما نتیجه نامطلوبی داره.مرحله سوم، توسعه (Develop):زمانی که به یک تعریف واضح از مسئله رسیدید وقتشه که در جستجوی راه حل­ های ممکن باشید.طوفان فکری و ایده­ پردازی با تیم یا حتی کاربر ­ها بهتون کمک می­ کنه ایده ­های زیادی جمع ­آوری کنید که به عنوان راه­ حل­ های بالقوه عمل می­ کنند. وقتی 3 ، 4 راه­ حل برای حل مشکل داشتید وقتشه ایده­ ها رو یه تست سریع بکنید. با ساخت یک پروتوتایپ (lo-fi prototyping) یا ماک ­آپ، تا به تارگت مارکتتون 3، 4 تا آپشنی که توسعه داید نشون بدید. هدف اینه که در کمترین زمان ممکن بازخورد بگیریم.وسوسه انگیزه که بخوایم خیلی مستقیم بریم سراغ راه حل. اما زود قضاوت نکنید و هنوز به خودتون اجازه ایده پردازی بدید. ایده­ ها رو با جملات سمی مثل اینکه " این ایده از نظر تکنیکی قابل انجام نیست یا خیلی هزینه داره و ... " سریع رد نکنید. نکته دیگه اینکه فکر ­ها و نظرات خارج از شرکت یا تیم طراحی با فکر­ های شما خیلی فرق داره. شنیدن نظرات دیگران می­ تونه به ایده­ های جدید و فکر­ های نو کمک کنه.مرحله چهارم، تحویل و تست (Deliver): انتخاب و توسعه راه­ حل نهاییدر مرحله آخر باید یه راه­ حل منسجم ارائه بشه. بعد از محدود شدن ایده­­ ها به سه چهار ایده در فاز قبل، حالا وقتشه بازخوردها رو بررسی کنیم. در این نقطه iterate و تکرار کردن مهمه و می­ تونه همراه با یه راند دیگه طوفان فکری باشه که با هدف توسعه یه راه­ حل منسجم انجام می­شه.اگر یکی دو ایده امیدوار کننده داشتید اون رو به یک پروتوتایپ لول بالاتر ارتقا بدید. بسته به اون محصول و سرویس پروتوتایپ hi- fi (قابل کلیک) اون رو بسنجید و با روش های مختلف تستش کنید. و باز هم نکته مهم اینه که تست­ هاتون بدون هرگونه پیش فرض انجام بشه.به این موضوع توجه کنید که آیا هنوز فانکشن­ های گیج کننده وجود داره؟ آیا کاربران فواید راه­ حل ارائه شده رو درک می­ کنند؟ بهتره عدم اطمینان رو در این فاز حل کنیم تا در مراحل بعدی توسعه. در این مرحله ممکنه یه ایده خلاقانه داشته باشید که خودتون عاشقش بشید اما احساساتتون رو کنار بگذارید چون باعث می­شه بازخورد کاربران رو نادیده بگیرید. مهم نیست ایده شما چقدر خلاقانه هست. تا زمانی که به نفع کاربر نباشه و کاربر درکش نکنه تمام پروسه توسعه بی ارزشه.مدل 2 الماس یه راهنمای مفید برای پردازش پروژه­ های هر تیمی است.بصری شدن این پروسه به هر فردی در تیم کمک میکنه متوجه بشن الان دقیقا در کدام مرحله حضور دارند و چه قدم هایی باقی مانده.و همچنین یه ابزار بصری خوب برای جلسات و گزارش دادن به ذینفعان پروژه است.یادتون باشه تمرین کردن بهترین نتیجه ­ها رو در بر داره. و اگر به خودتون و تیمتون زمان بدید و این پروسه ­ها رو انجام بدید به مرور توانایی تصمیم­ گیری­ های بهتری خواهید داشت. چون تصمیماتتون دیگه بر پایه فرضیات نخواهد بود بلکه بر اساس بازخوردهایی است که از کاربران نهایی محصول جمع آوری و ارزیابی شده.* رفرنس اصلی من برای نوشتن این مطلب رو اینجا می تونید ببینید. خوشحال میشم نظراتتون رو برام بنویسید.