
اساساً انتقال یک مفهوم کار سادهای نیست. در بسیاری از مواقع، انتقال یک موضوع کاملاً مشخص به یک فرد ناآشنا (حتی با وجود مواردی مانند کتاب، مقاله، سمینار، کارگاه آموزشی و امثالهم) سخت یا زمانبر میشود. حالا تصور کنید یک فرد که کار یا شغلش خلق یک چیز جدید است چه چالشهایی برای انتقال مفاهیم مرتبط با کار خود به دیگران دارد. وارد هر صنعتی که میشویم، میتوانیم مسیر بلوغی را ببینیم که در آن و به صورت بطئی و تدریجی، روشها، ابزارها و مدیاهای متنوعی برای انتقال مفهوم به وجود آمده است.
این بلوغ تدریجی هم برای حل یک مشکل یا برطرف کردن یک نیاز به وجود آمده است: انتقال مفاهیم در کاری که خلاقیت در آن سهم بیشتری دارد و نمونه مشابه یا تکرارشونده زیادی ندارد، مشکلتر است. از این رو به روشهای متنوع و مناسبی برای انتقال مفهوم نیاز است.
بگذارید مثالی بزنم که تجربه بیشتری در آن هست یا حداقل برداشت من این است که افراد بیشتری با آن آشنا هستند.
فرض کنید یک مهندس معمار، برای یک مشتری، که سفارش طراحی و ساخت یک خانه ویلایی در یک زمین مشخص را داده است طرحی در سر دارد. خانهای با فضاهای متنوع، مواد و مصالح متعدد و چیدمان منحصر به فرد که از نظر خودش بسیار جذاب و خلاقانه است. حالا فکر کنید انواع روشهایی که این دوست معمار ما میتواند از آنها استفاده کند تا ایدهها و طرح خودش را به مشتری منتقل کند چیست؟
حالا سوال این است: کدامیک از روشهای بالا برای ارائه یک مفهوم خلاقانه که هنوز به واقعیت نپیوسته است مناسب است؟ فرق اصلی روشهای فوق چیست؟ آیا فرمول مشخصی برای اینکه در چه موقعیتی باید از چه روشی استفاده کرد وجود دارد؟
اجازه بدهید حالتهای بالا را کمی موشکافانهتر بررسی کنیم. از سناریوی اول تا سناریوی پنجم، برای اثرگذاری بیشتر، منابع بیشتر و زمان بیشتری صرف میشود. حالا اگر یک فرد خلاق بخواهد برای مخاطبش از یکی از روشها فوق استفاده کند،تصمیمگیری براساس پاسخ به یک سوال انجام میشود: در مرحلهای که هستیم چقدر باید برای انتقال یک مفهوم هزینه کرد؟ اگر بتوانیم با توجه به مراحل چرخه حیات یک محصول، پاسخ مناسب این سوال را بیابیم، احتمالا بهینه رفتار خواهیم کرد.
طبیعی است: جزئیات بیشتر، صرف زمان و هزینه بیشتر.
خب کجا ممکن است خطا کنیم؟
اشکال آنجا میتواند باشد که ما زمان و هزینه را صرف پرداختن به جزئیاتی کنیم که ممکن است اساساً به اجرا نرسند. در مثال فوق، اگر معمار جوان از همان قدم اول، با صرف زمان و هزینه قابل توجه، یک نسخه VR بسازد و مشتری که اساساً با ایده اصلی یا کلیت طرح موافقت نکرده ناگهان با جزییاتی مواجه شود که با سلیقه او همخوانی ندارد، چه اتفاقی میافتد؟
آیا اگر مشتری در نهایت تصمیمش این نباشد که از طرح معمار داستان ما استفاده کند، آیا صرف زمان و هزینهای که انجام شده است توجیه پیدا میکند؟
برای اینکه یک طراح (UI Designer، UX Designer، Product Designer، Designer و مشابه این نقشها) یک ایده طراحی را با ذینفعان پروژه در میان بگذارد و آرام آرام و طی مراحلی که زمان و هزینه در کنترل اوست خود را به پیادهسازی نهایی طراحی نزدیک کند سطوحی از پیادهسازی وجود داردکه در بستر زمان و به تدریج شکل گرفتهاند و قاعدتاً هرکدام پاسخگوی یک سطح از نیازهای انتقال مفهوم هستند. مشابه مثال معمار داستان ما و ابزارهای متداولی که ممکن است معماران برای انتقال مفهوم به ذینفع استفاده کنند، در صنعت نرمافزار نیز با گذر زمان و با پیشرفت ابزارهای طراحی، چهار سطح از ارائه مابین طراحان از یک طرف و ذینفعان طرح (دولوپرها، مدیران محصول، مشتری، سرمایهگذاران و امثالهم) از طرف دیگر به وجود آمده و به تدریج شکل گرفتهاند. چهار سطح دقت و جزئیات به ترتیب Mockup، Wireframe، Sketch و Prototype است که به ترتیب از Sketch تا Prototype دقت طراحیها زیاد میشود. اصطلاحی که مورد میزان دقت طراحی استفاده میشود fidelity است. معنای لغوی fidelity تعهد و وفادار بودن است. هرچه میزان fidelity بالاتر باشد، ارائه طرح به نمونه واقعی بیشتر نزدیک یا شبیه است. (شاید اصطلاحات High Fidelity، Low Fidelity، Pixel Perfect و امثال آنها را شنیده باشید.) در نمودار شماتیک زیر، تفاوت آنها به خوبی دیده میشود:

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

فرض کنید ایدهٔ پختهتری دارید یا در چندین مرحله با افراد مرتبط تبادل نظر کردهاید. حالا وقت آن است که جزئیات بیشتری را به تصویر بکشید و ضمن انتقال بهتر مفهوم، یک گام به پیادهسازی واقعی نزدیکتر شوید. قطعاً در این مرحله، wireframe گزینه بهتری خواهد بود. wireframe یک پله به اجرای واقعی نزدیکتر است. در عین حال به نسبت هزینه کمی که صرف آن شده است آوردهای بسیار تاثیرگذار دارد و ورودی خوبی برای پیادهسازی واقعی به همراه میآورد. پس با تبادل نظر با ذینفعان پروژه نهایتاً اعمال تغییرات احتمالی مدنظر آنان، هزینه زیادی متحمل نمیشویم.

حال زمان آن رسیده که طرحهای پیاده شده و اصلاح شدهٔ نسبتاً نهایی در فاز wireframe را جان ببخشید و تصویری از آنچه نهایتاً کاربر خواهد دید را پیاده کنید. در این مرحله، fidelity و time ارزش ارائه یک Mockup را دارد. به بیان دیگر، هزینهای که برای خلق این فاز میشود ارزش صرف کردن را دارد. آورده آن انتقال مفهوم دقیقتر به ذینفعان از یک طرف و صرف زمان برای چند قدم نزدیکتر شدن به اجرای واقعی محصول از طرف دیگر است. انتظار این است که پس از این ارائه، اصلاحات کمی روی طرحها اعمال شود.

حال فرض کنید مشتری با کلیات طرح موافقت کرده یا اینکه با شما قرارداد همکاری امضا کرده یا در ساختار یک پروژه، مدیر پروژه برای اطمینان و راستی آزمایی طرح شما، نیاز به نمونه واقعیتری پیدا میکند.
نمونهای که به کمک آن، روی گوشی یا دسکتاپ، بدون اینکه طرح شما به دادههای واقعی نرمافزار یا هرگونه سرویس نرمافزاری اتصال داشته باشد، بتوان هنر شما را لمس کرد و با طرحهای شما همانند محصول نهایی کار کرد. جابجایی بین صفحات را دید و نهایتاً، تجربهای که یک کاربر پس از تولید اپلیکشین پیدا خواهد کرد را قبل از تولید و صرف منابع و زمان لمس نمود. در این حالت، انتقال مفهوم User Experience درصد قابل توجهی نسبت به حالتهای قبل پیدا خواهد کرد. اینجا fidelity و time به بالاترین میزان خود میرسد. اما اگر ارزشش را داشته باشد، حتماً.

جمعبندی
در دنیایی که در انجام یک کار دقیقهها هم به حساب میآیند، باید در مصرف منابع و زمانمان هوشمندانه عمل کنیم. بارها دیده میشود که یک دوست طراح، برای انتقال یک مفهوم ساده، مستقیماً به سراغ خلق Prototype میرود یا برعکس زمانی که لازم است جزئیات بیشتری را منتقل کند و باعث گرهگشایی شود، از یک sketch ساده استفاده میشود و مطلب به درستی منتقل نمیشود یا سوتفاهم بین افراد مرتبط با پروژه به وجود می آورد.
همه حالات فوق برای انتقال مفهوم و در نهایت نزدیک شدن به اجرا و پیادهسازی طی میشوند. زمان و منابعمان را هوشمندانه مصرف کنیم.
پینوشت: اگر علاقمند هستین که با تیم ما کار کنید میتوانید از اینجا شروع کنید.