ترجمه و ویراستاری:

آیدین ضیاپور

به عنوان مدیر محصول اطمینان دارم که شما از اهمیت ساخت پروتوتایپ محصول برای مصور سازی نیازمندی‌ها و شناسایی ریسک‌های پنهان محصول با خبر هستید. ۵۰ صفحه‌ مستندات نیازمندی‌ راه مطمئنی برای انتقال تمامی پیچیدگی‌های خاص یک محصول دیجیتال نیست. بنابر تجربه این مستندات باعث سر رفتن حوصله خوانندگان و یا حتی بدتر از آن برداشت اشتباه خواهد شد. اما با استفاده از یک نمونه اولیه شما هر داستان کاربر را به بخشی از یک محصول قابل لمس تبدیل خواهید کرد.

متدولوژی زیر یکی از ابزارهای مورد علاقه من بعنوان یک مدیر محصول است:

1. برای ساخت نمونه اولیه داستان‌های کاربر را اولویت بندی کنید
2. شروع به ساخت نمونه اولیه از داستان‌های کاربر کنید
3. نوت‌هایی برای تشریح بهتر هر بخش از نمونه اولیه برای گرفتن بازخوردهای مناسب قرار دهید

لیستی از داستان‌های کاربر ایجاد کنید

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

• به عنوان کاربر امکان ساخت اکانت جدید را داشته باشم
• به عنوان کاربر امکان انتخاب عکس از گالری تلفن را داشته باشم
• به عنوان کاربر امکان انتخاب سایز  کتاب تصویری را داشته باشم
• به عنوان کاربر امکان اضافه کردن افکت های تصویری به عکس های خود را داشته باشم
• به عنوان کاربر امکان پرداخت هزینه کتاب را با استفاده از کارت اعتباری داشته باشم
• به عنوان کاربر امکان دسترسی به تاریخچه سفارشات خود را داشته باشم
• به عنوان کاربر امکان دسترسی و خواندن قوانین و مقررات – حفظ حریم شخصی را داشته باشم

در این مرحله نباید نگران جزییات دقیق هر داستان کاربر باشید و سعی کنید تا فعالیت‌های کاربران را لیست کرده تا نقشه‌ای از جریان اصلی فعالیت کاربر را بدست آوریم و گپ‌های موجود را شناسایی کنیم.

 داستان‌های کاربر موجود را اولویت بندی کنید

بنابر تجربه ساخت نمونه اولیه برای داستان کاربری مانند مورد زیر ارزشی نخواهد داشت:

“به عنوان کاربر امکان دسترسی و خواندن قوانین و مقررات – حفظ حریم شخصی را داشته باشم”

مثال بالا یک داستان کاربر با ریسک پایین است چون فقط شامل موارد استاتیک و فقط خواندنی است.

برای ساخت مدل اولیه، من همیشه از داستان‌های کاربری ورود اطلاعات توسط کاربر یا درخواست پردازش داده وارد شده شروع می کنم، زیراکه اکثرا ریسک ها در چنین مواردی نهفته شده اند.

در مثال زیر به تشریح ریسک های بالقوه برای هر داستان کاربر پرداخته شده است:

داستان‌های کاربر با ریسک بالا را نمونه‌سازی کنید

پس از این که داستان‌های کاربر با ریسک بالا را شناسایی کردید‌ می توانید با ساخت نمونه اولیه آن ها را نمایش دهید. باید توجه داشته باشید که قصد شما از این مدل سازی کمک به درک بهتر نیازمندی ها است و قرار نیست خودتان را بعنوان گرافیست یا طراح رابط کاربری به دیگران اثبات کنید و قرار نیست در اجرا به طراحی اولیه شما وفاداری بالایی وجود داشته باشد.

حالا بیایید تا به نمونه اولیه ساخته شده از داستان های کاربر ۱ تا ۴ نگاهی بیندازیم. نمونه اولیه توسط UXPin ساخته شده که یک ابزار مناسب برای ساخت این دست نمونه‌های اولیه برای محصولات است اما استفاده از ابزار دیگر هم بلامانع است.

داستان کاربر ۱:‌ به عنوان کاربر امکان ساخت اکانت جدید را داشته باشم

این نمونه اولیه درعین سادگی یک آیتم بسیار مهم برای تیم فنی به همراه دارد – چون این نمونه بلافاصله نوع داده هایی که باید در back-end ذخیره شوند را برای آنها مشخص می کند:

• نام (تنها شامل حروف می باشد)
• ایمیل‌(شامل حروف  و اعداد می باشد)
• رمز عبور‌(می تواند شامل حروف و اعداد باشد – بر اساس قواعد امنیتی سازمان متغیر است)

بر اساس نیازمندی های بالا – ذینفعان احتمالا در مورد قواعد مرتبط با رمز عبور سوالاتی را مطرح می کنند. برای مثال – آیا رمز عبور می تواند فقط شامل حروف باشد؟ آیا می تواند شامل حروف و اعداد باشد؟ آیا می تواند شامل حروف و برخی کاراکترهای خاص نظیر علامت سوال باشد؟

با ارایه نمونه اولیه – امکان بحث بر روی بهترین قواعد موجود برای رمز عبور را خواهید داشت. اما از سوی دیگر بدون داشتن یک نمونه اولیه – توسعه دهندگان شناختی از نوع داده های مورد نیاز نداشته و طراحان نیز درکی از مقدار اطلاعات مورد نیاز برای نمایش نخواهند داشت.

داستان کاربر ۲:‌ به عنوان کاربر امکان انتخاب عکس از گالری تلفن همراه خود را داشته باشم

نمونه اولیه از داستان‌کاربر شامل ۲ تصویر بالا است که باید با ترتیب مشخصی نمایش داده شوند:

• کاربر بر روی آیکون دوربین در صفحه اول کلیک می کند
• صفحه دوم تمامی عکس های موجود در تلفن همراه کاربر را نمایش می‌دهد

علاوه بر این- نمونه اولیه یکی دیگر از جنبه های مهم تجربه کاربری را نمایش می دهد:

مطمئن شوید که کاربران می توانند به راحتی عکس های انتخابی خود را ببینند. در نمونه اولیه این نیازمندی با Check box هایی که در بالا سمت راست هر عکس قرار دارند، عملکرد امکان پذیر می شود. در حالی که نمونه اولیه از Check Box ها استفاده می‌کند – ممکن است طراح انتخاب دیگری برای پیاده سازی این خواسته با توجه به هویت بصری- اندازه صفحه و جریان فعالیتی کاربر در برنامه در نظر بگیرد.

به عنوان مثال یک پوشش شفاف می تواند بر روی هر عکس قرار گرفته یا رنگ حاشیه هر عکس پس از انتخاب شدن تغییر پیدا کند. با استفاده از نمونه اولیه می توانید بر روی چنین مسائلی هر چه سریع تر بحث کرده و تصمیمات گرفته شده را در محصول نهایی اعمال کنید.

از سوی دیگر این یک مزیت برای تیم فنی نیز محسوب می شود بدلیل اینکه از تعداد عکس هایی که هر بار باید آپلود شوند زودتر باخبر می شوند.

داستان کاربر ۳:‌ به عنوان کاربر امکان انتخاب سایز کتاب تصویری را داشته باشم

با وجود اینکه اولویت این داستان کاربر بالا نیست ولی ما یک نمونه سازی از آن  انجام دادیم، البته بهتر است همیشه برای ساخت نمونه اولیه از داستانهای کاربر با اولویت بالا استفاده کنید اما مواردی هستد که اولویت بالایی ندارند اما نمونه‌سازی آنها مفید به نظر می آید. با اینکه نمونه اولیه ساخته شده به هیچ عنوان شبیه یک نمونه کامل نیست اما حداقل توانستیم یک ایده اولیه برای طراحان، توسعه دهندگان و بازاریابان ایجاد کنیم. حالا تیم قادر است در مورد مسائل زیر صحبت کنند:

• ابعاد، قیمت و توضیحات مرتبط با عکس های چگونه باید نشان داده شوند؟
• چگونه می توانیم به کاربران در مشاهده عکس های انتخابی در سایزنهایی برنامه کمک کنیم؟
• آیا برنامه باید امکان پرینت عکس های انتخابی را به ترتیب آپلود آن ها داشته باشد؟ یا ما باید اجازه تغییر ترتیب آن ها را به کاربران بدهیم؟
• آیا ما باید یک مرحله اضافه در ساخت عکس کاور برای کاربران ایجاد کنیم؟ یا یکی از عکس ها را به صورت تصادفی به عنوان عکس کاور انتخاب کنیم؟

داستان کاربر ۴:  به عنوان کاربر امکان پرداخت هزینه برنامه را با استفاده از کارت اعتباری داشته باشم.

نمونه اولیه ساخته شده برای داستان کاربری چهارم اطلاعات پایه پرداخت را نمایش می‌دهند. این نمونه اولیه کمک می کند تا در مورد تک تک فیلدهای فرم بحث انجام شود و در صورت لازم تصمیم گرفته شود.

برای مثال:

• در فیلد مرتبط با کارت اعتباری چند رقم می تواند وارد کند؟  آیا تمامی کارتهای اعتباری را قبول می کنیم ( ویزا کارت، مستر کارت، آمریکن اکسپرس)؟ کارت های آمریکن اکسپرس دارای 15 عدد هستند در حالیکه ویزا و مستر کارت دارای 16 رقم هستند. باید در مورد این متغیرها تصمیم گیری کرد.
• آیا می خواهیم پی پال را هم در لیست کانال های پرداخت قرار دهیم؟ در صورت جواب مثبت چگونه می‌خواهیم این وضعیت را برای توسعه دهندگان در اسپرینت پیش رو اولویت بندی کنیم؟
• هنگامی که فیلدها خالی مانده و یا اطلاعات اشتباهی در آنها ثبت می شوند سیستم چه پاسخی باید به کاربر نشان دهد؟

بعلاوه این نمونه اولیه یک نیازمندی مهم دیگر را نیز نشان می دهد: “ذخیره سازی اطلاعات پرداخت کاربر”.

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

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

به محض اینکه تمام صفحات را درست کردید حالا نوبت اضافه کردن ارتباطات مابین محتوای کلیدی است:

• فراخوان‌هایی که منجربه مشاهده صفحه جدید شود
• آیکون ها و عکس هایی که منجربه باز شدن صفحات دیگر شوند
• فیلدهایی که به ورودی های کاربران واکنش نشان دهند

حالا نوبت به اشتراک گذاشتن نمونه اولیه ساخته شده برای گرفتن بازخورد است.

به نمونه اولیه ساخته شده کامنت و سوال اضافه کنید

هنگامی که نمونه اولیه را ساختید، به احتمال زیاد  باز سوالاتی برای طراحان، توسعه‌دهندگان و ذی‌نفعان مدیریتی وجود خواهد داشت. برای تفسیر نمونه اولیه معمولا این راه بسیار مفیدی است:

• محدودیت های منطقه ای:

برای مثال برای نمایش و جداسازی ارقام قیمت در آمریکا از نقطه (.) استفاده می شود. مثل 25.00$. با این حال در اتحادیه اروپا معمولاً از ویرگول(,) استفاده می‌شود. مثل 25,00$. با این توضیحات این بخش برای توسعه دهندگان روشن می شود.

• داستان‌های کاربری که داشتن آن ها باعث خوشحالی کاربر می شود:

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

• آیتم هایی که هزینه بر هستند:

در صورتیکه  فکر می کنید  پیاده سازی یک عملکرد در محصول هزینه‌بر است آن را در نمونه اولیه ذکر کرده و آن را نمایش دهید. از نمونه اولیه برای گفت و گو بر روی آیتم هایی که فکر می کنید پیاده‌سازی آنها با دردسر روبرو خواهید بود استفاده کنید. سپس می توانید بر اساس بازخوردهایی که گرفته اید نیازمندی ها محصول را نهایی کنید.

برای گرفتن بازخورد تلفیقی، نمونه اولیه خود را به اشتراک بگذارید

هنگامی که نوبت به بررسی بازخوردها می رسد شما باید مجموعه ای از جلسات را برای ارائه صفحات ساخته شده به ذی‌نفعان برگزار کنید.

به اشتراک گذاری لینکی از نمونه اولیه می تواند مزیت‎های زیر را به همراه داشته باشد:

• ذی‌نفعان می توانند با نمونه اولیه بدون عجله تعامل داشته و آن را ارزیابی کنند. پس بازخورد آنها شتاب زده نیست.

• ذی‌نفعان نمونه اولیه را با حداقل تعصب ارزیابی می‌کنند. در صورتی که عملکرد ارایه شده در نمونه اولیه به اندازه کافی واضح و مشخص نباشد به سرعت برای ذی نفعان آشکار می شود.

• وقتی که برای نمونه اولیه خود یک لینک به اشتراک می گذارید، امکان بررسی تمامی کامنت ها و سوالات برای ذی‌نفعان فراهم می شود. برای مثال داستان کاربر 4  را در نظر بگیرید. شما می توانید سوالاتی مرتبط با نیازمندی های قانونی و فنی در رابطه با اطلاعات پرداخت های کاربر در نمونه اولیه مرتبط با آن قرار دهید.

برای پروژه های پیچیده تر، بهتر است بازخوردها را در جلسات گروهی بررسی کنید. این کار به شما و ذی‌نفعان فرصتی برای تمرکز روی بازخوردهای گرفته شده می دهد.

• وقتی شما طراحی انجام شده را برای تیم ارسال می کنید، از آن ها بازخوردهایی با توجه به این آیتم ها بخواهید: چشم انداز محصول، تکامل ویژگی ها و جریان میان صفحات. به آن ها بگویید که  وسواس زیادی برای طراحی رابط کاربری به خرج ندهند چون ممکن است بعدا به کلی تغییر کند.

• هنگامی که به کامنت ها پاسخ می دهید، بپرسید چرا؟ اگر سوالات خود را به صورت مفیدی بپرسید، این کلمه می تواند کمک زیادی به شما بکند. چنین چیزی را امتحان کنید:

” نظری که دادی برام جالب بود. آیا بر اساس اطلاعات خاصی به این جمع بندی رسیدی یا به صورت غریزی پاسخ دادی؟ ” اگر جواب آن ها این بود که به صورت غریزی کامنت گذاشتم، یک بار دیگر داستان کاربر مرتبط را با او در میان بگذارید: ” اگر به عنوان کاربر می خواستم یک ( داستان کاربر) را انجام دهم آنگاه نیاز داشتم تا این (اکشن) اتفاق بیفتد به دلیل (تحقیقات کاربر و بازار).”

6- بازخوردها  را تحلیل کرده و نمونه های اولیه و داستان های کاربر  را به روز رسانی کنید

بعد از اینکه نظرات مختلف را جمع آوری و تحلیل کردید حالا وقت به روز رسانی داستانهای کاربر و نمونه اولیه ساخته شده است. پس از بررسی و تحلیل کامنتهای داده شده یک نکته جا مانده آشکار می شودکه در داستان های کاربر ابتدایی ذکر نشده است: “نیاز به ارسال ایمیل تاییدیه برای زمان هایی که سفارش ثبت و ارسال می شود.”

برای تمامی پلتفرم های e-commerce، ارسال ایمیل حاوی اطلاعات تراکنش برای اطلاع رسانی به مشتریان بسیار حیاتی است. بدون این داستان کاربر، تجربه کاربری برنامه با کاستی روبرو خواهد بود. بنابراین ما احتیاج داریم تا داستان های کاربر خود را به روز رسانی کنیم:

• به عنوان کاربر هنگام ثبت سفارش امکان دریافت ایمیل را داشته باشم.
• به عنوان کاربر هنگام ارسال سفارش امکان دریافت ایمیل را داشته باشم.

در این مثال، نمونه اولیه ساخته شده از ایمیل –  رعایت تمامی الزامات قانونی مرتبط با رسیدها و فاکتورهای سفارش رو گارانتی می کند. زیرا عدم رعایت الزامات قانونی عواقب جدی برای کسب و کار و آینده محصول در پی خواهد داشت. بنابراین این داستان کاربر را به عنوان داستان کاربر با ریسک بالا در نظر می گیریم.

آدرس متن انگلیسی