تست رابط کاربری (UI) با روش جادوگر شهر اُز

در این مقاله می‌خواهیم به به یکی از روش‌ها برای تست رابط کاربری (UI) یعنی روش جادوگر شهر اُز بپردازیم. روش «جادوگر شهر اُز» به تیم‌ها کمک می‌کند تا طرح‌هایی که با فناوری‌های پیچیده کار می‌کنند را با هزینه کم آزمایش کنند. به جای ساخت کامل فناوری، طراحان می‌توانند با داشتن یک فرد که نقش سیستم را «بازی» می‌کند، پاسخ‌هایی را که فناوری ممکن است ارائه دهد، شبیه‌سازی کنند.

شما می‌توانید برای اطلاعات بیش‌تر، مقاله طراحی رابط کاربری در 5 مرحله را نیز مطالعه کنید.

روش جادوگر شهر اُز چیست؟

روش «جادوگر شهر اُز» یک روش تحقیقاتی هدایت‌شده است که در آن کاربر با رابطی تعامل می‌کند که به نظر مستقل عمل می‌کند، اما (به طور کامل یا بخشی) توسط یک انسان کنترل می‌شود.

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

این روش در آزمون‌های هدایت‌شده قابلیت استفاده (usability tests) به کار می‌رود. مشابه یک آزمون قابلیت استفاده هدایت‌شده‌ی سنتی، در مطالعه‌ی روش جادوگر شهر اُز نیز به یک تسهیل‌گر (facilitator) و یک کاربر هدف نیاز است. علاوه بر این، به فردی نیاز است که نقش «جادوگر» را بازی کند. این شخص پاسخ‌های رابط کاربری را انتخاب یا ایجاد می‌کند.

روش جادوگر شهر اُز شبیه به آزمون نمونه‌های اولیه کاغذی است (جایی که ممکن است فردی نقش رایانه را بازی کند). با این حال، در روش جادوگر شهر اُز، طراحی می‌تواند دیجیتالی باشد و فردی که پاسخ سیستم را تولید می‌کند برای کاربر قابل مشاهده نیست.

اگر بخواهیم به طور ساده‌تر توضیح دهیم باید بگوییم که در روش جادوگر شهر اُز، یک رابط کاربری (مثلاً وب‌سایت یا اپلیکیشن) به کاربر نمایش داده می‌شود که به نظر می‌رسد به طور مستقل عمل می‌کند. اما در واقع، یک فرد (جادوگر) پشت صحنه حضور دارد و با توجه به اقدامات کاربر، پاسخ‌های رابط را کنترل می‌کند. این فرد می‌تواند هر نوع بازخوردی را که می‌خواهد شبیه‌سازی کند، اعم از اینکه رابط کاربری به درستی کار کند، با خطا مواجه شود، یا به طور کامل از کار بیفتد.

در این تست تجربه کاربری به 3 نفر نیاز داریم:

تسهیل‌گر: تسهیل‌گر وظیفه‌ی هدایت آزمایش و نظارت بر روند آن را بر عهده دارد. او با کاربر تعامل دارد، سوالات می‌پرسد و بازخورد جمع‌آوری می‌کند. تسهیل‌گر باید با روش جادوگر شهر اُز و سیستم یا فناوری مورد آزمایش آشنا باشد.

کاربر هدف: کاربر هدف فردی است که با رابط کاربری تعامل دارد و آن را آزمایش می‌کند. باید نماینده‌ی گروه کاربری مورد نظر برای سیستم باشد و در انجام وظایف مربوط به سیستم تجربه داشته باشد.

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

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

ریشه‌های پیدایش روش جادوگر شهر اُز

روش جادوگر شهر اُز برای اولین بار در سال ۱۹۷۳ توسط دان نرمن و الن مونرو برای آزمایش یک دستیار سفر خودکار پایانه‌ی کامپیوتری فرودگاه مورد استفاده و مستندسازی قرار گرفت. نام این روش در سال ۱۹۸۳ توسط محقق جف کلی در رساله‌ی دکترای او در مورد رابط‌های زبان طبیعی در دانشگاه جانز هاپکینز ابداع شد. این مطالعات بنیادی، تعاملات کاربر با رابط‌های زبان طبیعی را زمانی که این فناوری در مراحل اولیه‌ی توسعه‌ی خود قرار داشت، مورد بررسی قرار داد.

چه زمانی از روش جادوگر شهر اُز استفاده کنیم؟

تست رابط کاربری (UI) با روش جادوگر شهر اُز زمانی مفید است که می‌خواهیم رابط‌های کاربری جدیدی را که توسط فناوری‌های پیچیده پشتیبانی می‌شوند، آزمایش کنیم. این فناوری‌های پیچیده با یک نمونه اولیه‌ی حاوی محتوای ایستا به سختی قابل آزمایشی هستند که معنادار باشند. چنین رابط‌های کاربری‌ای شامل موارد زیر می‌شوند:

رابط‌های کاربری مکالمه‌محور: مانند چت‌بات‌ها

رابط‌هایی که از الگوریتم‌های یادگیری برای ارائه محتوای پیشنهادی استفاده می‌کنند.

رابط‌هایی که به صورت لحظه‌ای به اطلاعات دسترسی پیدا کرده و نتایج را به کاربر نمایش می‌دهند.

به عنوان مثال، نویسندگان از روش جادوگر شهر اُز در پروژه‌های تحقیقاتی زیر استفاده کرده‌اند:

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

پروژه‌ای برای طراحی یک دستیار صوتی جدید: از تست رابط کاربری (UI) با روش جادوگر شهر اُز برای کمک به تیم در درک نحوه‌ی تعامل کاربران با یک دستیار صوتی جدید استفاده شد. یک بلندگوی بلوتوث داخل یک ماکت فیزیکی از مقوا قرار داده شد. کاربر با ماکت صحبت می‌کرد و پاسخ‌های دستیار صوتی از طریق یک نرم‌افزار تبدیل متن به گفتار که به بلندگوی بلوتوث متصل شده بود، تولید می‌شد.

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

مزایای استفاده از روش جادوگر شهر اُز

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

روش جادوگر شهر اُز اغلب در هنگام توسعه‌ی محصولات با حداقل قابلیت پذیرش (MVP) استفاده می‌شود. یکی از مشهورترین نمونه‌های MVP که از روش جادوگر شهر اُز استفاده کرده، متعلق به شرکت زاپوس، اولین خرده‌فروش آنلاین کفش است. نیک سوینمرن، بنیان‌گذار این شرکت، قبل از سرمایه‌گذاری در انبارها، موجودی و خودکارسازی خدمات، با برآوردن سفارشات به صورت شخصی، ارزش پیشنهادی شرکت را آزمایش کرد. هنگامی که سفارش‌هایی در وب‌سایت او ثبت می‌شد، سوینمرن به یک فروشگاه کفش محلی می‌رفت، کفش‌ها را می‌خرید و آن‌ها را برای مشتری ارسال می‌کرد.

چگونه یک مطالعه و تست رابط کاربری (UI) با روش جادوگر شهر اُز را راه‌اندازی کنیم؟

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

مرحله ۱: ساختن نمونه اولیه

شما به یک نمونه اولیه از طراحی جدید نیاز دارید که کاربر با آن تعامل کند. این نمونه اولیه بسته به چیزی که آزمایش می‌کنید، ممکن است یکی از موارد زیر باشد:

1. یک نمونه اولیه در یک نرم‌افزار طراحی (مانند فیگما)

2. یک نمونه اولیه‌ی کدگذاری‌شده

3. یک فناوری موجود به عنوان نماینده‌ای برای عملکرد جدید (به عنوان مثال، یک پلتفرم پیام‌رسان موجود برای شبیه‌سازی یک چت‌بات جدید)

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

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

مرحله ۲: تعیین پاسخ‌هایی که جادوگر ارائه می‌دهد

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

1. روش بسته: در این روش، جادوگر می‌تواند پاسخ‌های خود را از یک لیست از پیش تعیین شده انتخاب کند. این لیست باید شامل پاسخ‌های رایج و قابل پیش‌بینی برای تعاملات کاربر باشد.

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

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

1. روش بسته: قاطع و سریع

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

مزایا:

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

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

معایب:

انتخاب پاسخ می‌تواند زمان‌بر باشد، به خصوص اگر تعداد پاسخ‌ها زیاد باشد: اگر جادوگر مجموعه‌ی بزرگی از پاسخ‌های احتمالی برای انتخاب داشته باشد، انتخاب مناسب‌ترین پاسخ می‌تواند زمان‌بر باشد.

ممکن است پاسخ‌هایی متناسب با موقعیت وجود نداشته باشد: روش بسته ممکن است برای موقعیت‌هایی که طیف وسیعی از ورودی‌های کاربر وجود دارد، مناسب نباشد، زیرا ممکن است پاسخی از پیش تعیین‌شده برای همه‌ی سناریوها وجود نداشته باشد.

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

2. روش باز: انعطاف‌پذیری و مهارت و خلاقیت

در این روش پاسخ قاطع و روشنی وجود ندارد و جادوگر باید بسته به موقعیت پاسخی را به کاربر ارائه بدهد:

مزایا:

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

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

معایب:

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

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

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

3. روش ترکیبی: انعطاف‌پذیری با کارایی

روش ترکیبی، همانطور که از نامش پیداست، مزایای هر دو روش بسته و باز را در خود جای داده است. در این روش:

مزایا:

جادوگر می‌تواند پاسخی را انتخاب یا پاسخی جدید ایجاد کند: این موضوع انعطاف‌پذیری بالایی را برای تطبیق با رفتارهای کاربر و شبیه‌سازی سناریوهای غیرمنتظره فراهم می‌کند.

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

معایب:

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

به طور کلی، روش ترکیبی تعادلی بین کارایی و انعطاف‌پذیری ایجاد می‌کند و به محققان اجازه می‌دهد تا طیف وسیعی از سناریوهای تعامل را آزمایش کنند. این روش برای رابط‌های کاربری پیچیده یا آن‌هایی که نیاز به واکنش به ورودی‌های غیرمنتظره کاربر دارند، بسیار مناسب است.

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

مرحله ۳: ایجاد پروتکل مطالعه

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

پروتکل مطالعه‌ی روش جادوگر شهر اُز علاوه بر عناصر معمول که در یک برنامه‌ی تست یافت می‌شود (مانند وظایفی که به کاربر داده می‌شود)، باید شامل موارد زیر نیز باشد:

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

2. سوالات: این بخش شامل سوالاتی است که تسهیل‌گر در ابتدای جلسه از کاربر می‌پرسد و می‌تواند پاسخ‌های جادوگر را در طول جلسه (در صورت لزوم) تحت تاثیر قرار دهد.

3. عناصر تحت کنترل جادوگر: این بخش شامل مشخص کردن عناصری از طراحی است که توسط جادوگر کنترل می‌شود و همچنین نحوه‌ی کنترل آن‌ها (مانند درخت تصمیم‌گیری، دستورالعمل‌های گام‌به‌گام یا اسکرین‌شات‌هایی برای جادوگر جهت مشاوره یا پیروی).

4. پاسخ‌های از پیش تعیین‌شده: این بخش شامل پاسخ‌هایی است که جادوگر می‌تواند از آن‌ها انتخاب کند، به ویژه در صورت استفاده از روش بسته یا ترکیبی (برای مثال، «در حال بارگذاری... لطفاً منتظر بمانید» زمانی که جادوگر به زمان بیشتری نیاز دارد یا «در حال ساخت است» اگر کاربر به طور غیرمنتظره‌ای با سیستم تعامل کند).

5. دستورالعمل‌های پاسخ‌دهی: این بخش شامل هرگونه دستورالعمل برای نحوه‌ی پاسخ‌دهی جادوگر در صورت ایجاد پاسخ‌های جدید برای سیستم در طول جلسه است (برای مثال، توصیه‌هایی در مورد لحن صدا اگر جادوگر وانمود می‌کند که یک چت‌بات است).

مرحله ۴: انتخاب و آماده‌سازی جادوگر

جادوگر باید با موارد زیر آشنایی داشته باشد:

1. مفهوم و طراحی محصول: جادوگر باید درک کند که محصول چه هدفی دارد و چگونه کار می‌کند. در حالت ایده‌آل، او همچنین از هرگونه محدودیت تکنولوژیکی آگاه است تا بتواند از ارائه‌ی پاسخ‌های سیستمی که امکان‌پذیر نیستند، اجتناب کند.

2. پاسخ‌هایی که باید ارائه دهد: اگر شما یک آزمایش بسته یا ترکیبی انجام می‌دهید، جادوگر ممکن است به ایجاد پاسخ‌ها کمک کرده باشد.

3. نرم‌افزار یا کد نمونه‌سازی: در صورتی که جادوگر نیاز به به‌روزرسانی عناصر در یک نمونه اولیه داشته باشد.

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

1. مرور پروتکل مطالعه با جادوگر

2. تمرین پاسخ‌دهی یا به‌روزرسانی نمونه اولیه برای جادوگر

3. حتی دعوت از جادوگر برای شرکت در یک آزمایش آزمایشی (به مرحله ۵ مراجعه کنید)

مرحله ۵: اجرای آزمایشی مطالعه

با توجه به پیچیدگی‌های تست رابط کاربری (UI) با روش جادوگر شهر اُز، اجرای آزمایشیِ مطالعه به اطمینان از کارکرد صحیح تمامی اجزا و توانایی جادوگر در ارائه‌ی سریع پاسخ‌ها کمک می‌کند. شما می‌توانید با یک دوست، همکار یا یک کاربر واقعی، مطالعه را به صورت آزمایشی اجرا کنید. اجرای آزمایشی به جادوگر شما فرصتی برای تمرین قبل از جلسات واقعی می‌دهد و از اتلاف وقت باارزش در طول جلسه برای حل مشکلات فنی غیرمنتظره جلوگیری می‌کند.

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

آیا باید ماهیت جادوگر را فاش کرد؟

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

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

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

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

جمع‌بندی: روش جادوگر شهر اُز برای تحقیقات در مورد رابط‌های کاربری پیچیده

مطالعه و تست رابط کاربری (UI) با روش جادوگر شهر اُز بینش‌های اولیه‌ای را در مورد رابط‌های کاربری پیچیده و بسیار تعاملی ارائه می‌دهد که آزمایش و ساخت آن‌ها ممکن است پرهزینه باشد. لازم به ذکر است که همه‌ی مطالعات قابلیت استفاده از این روش را ندارند. برای انتخاب روش مناسب، اهداف تحقیق خود و آنچه را که می‌خواهید بیاموزید در نظر بگیرید. در بسیاری از موارد، یک نمونه اولیه با محتوای ایستا برای رسیدن به هدف شما کافی خواهد بود.

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

هنگام اجرای یک مطالعه و تست رابط کاربری (UI) با روش جادوگر شهر اُز، آمادگی و برنامه‌ریزی کلیدی هستند. برای دستیابی به بهترین نتایج، یک برنامه‌ی مشخص تهیه کنید، از مهندسان کمک بگیرید و مطالعه‌ی خود را به صورت آزمایشی اجرا نمایید.