چگونه تحقیقات یوایکس را با دو سوال ساده بفروشیم

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

می‌دانید که درک بهتر نیازهای کاربران به تیم کمک می‌کند تا درباره هدف واقعی پروژه به توافق برسد، اما بودجه و زمان کافی برای تحقیق در اختیار ندارید. وقتی می‌خواهید دسترسی مستقیم‌تری به کاربران داشته باشید، شاید احساس کنید مثل الیور توئیست، شخصیت داستان چارلز دیکنز، باید با ترس و تردید درخواست کنید: «ببخشید آقا، ممکن است کمی بیشتر به من بدهید؟»

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

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

• چه چیزهایی در سیستم وجود دارند؟
• این چیزها چه ارتباطی با یکدیگر دارند؟

مرحله‌ای دشوار میان تحقیق و طراحی صفحه

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

اما ORCA چیست؟

خوشحالم که پرسیدید!

ORCA مخفف چهار واژه Objects، Relationships، CTAs و Attributes است:

• Objects (اشیا): موجودیت‌ها یا چیزهای مهم در سیستم.
• Relationships (روابط): ارتباط میان این اشیا.
• CTAs (فراخوان‌های اقدام): اقدام‌هایی که کاربران می‌توانند انجام دهند.
• Attributes (ویژگی‌ها): مشخصات و اطلاعات مربوط به هر شیء.

این چارچوب فرایندی برای طراحی تجربه‌های کاربری مستحکم و مبتنی بر رویکرد شیءگرا ارائه می‌کند.

تجربه کاربری شیءگرا (Object-Oriented UX یا OOUX) فلسفه طراحی من است. ORCA یک روش‌شناسی تکرارشونده است که به ما کمک می‌کند یافته‌های تحقیقات کاربران را به یک ساختار منسجم و زیبا تبدیل کنیم، ساختاری که زیربنای طراحی صفحات و تعاملات محصول خواهد بود.

OOUX و ORCA باعث شده‌اند کار من به‌عنوان طراح تجربه کاربری مشارکتی‌تر، مؤثرتر، کارآمدتر، لذت‌بخش‌تر، راهبردی‌تر و معنادارتر شود.

فرایند ORCA شامل چهار دور تکرارشونده و در مجموع پانزده مرحله است. در هر دور، درک روشن‌تری از اشیا (O)، روابط (R)، فراخوان‌های اقدام (C) و ویژگی‌ها (A) به دست می‌آوریم.

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

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

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

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

قرار گرفتن در یک قایق کنجکاوی مشترک

چیزی که ما را به دردسر می‌اندازد، ندانسته‌های ما نیست، بلکه چیزهایی است که با اطمینان می‌دانیم، اما در واقع درست نیستند.

— مارک تواین

دو مرحله نخست فرایند ORCA، یعنی کشف اشیا (Object Discovery) و کشف روابط (Relationship Discovery)، نقاط تاریک و غبارگرفته ناهماهنگی‌های تیم و پیچیدگی‌های ذاتی‌ای را آشکار می‌کنند که تا پیش از آن زیر فرش پنهان شده بودند.

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

این یکی از دلایلی است که بسیاری از طراحان تجربه کاربری از شغل خود ناراضی هستند و پروژه‌های زیادی با شکست مواجه می‌شوند. همچنین یکی از دلایلی است که اغلب نمی‌توانیم ضرورت تحقیقات کاربری را به دیگران بقبولانیم: هر تصمیم‌گیرنده‌ای به تصویر ذهنی خودش از محصول اطمینان دارد.

وقتی بخش‌های مبهم و تفاوت‌های موجود میان تصویر ذهنی افراد را آشکار کنیم، ضرورت انجام تحقیقات کاربری خودبه‌خود روشن می‌شود.

اما شیوه انجام این کار اهمیت زیادی دارد. هرچقدر هم که بخواهیم، نمی‌توانیم صرفا به همه بگوییم: «شما اشتباه می‌کنید!»

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

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

شاید برای متقاعد کردن ذی‌نفعان به انجام تحقیقات، صادقانه بگویید:

«باید پزشکان را بهتر بشناسیم! چه مشکلاتی دارند؟ چگونه از اپلیکیشن فعلی استفاده می‌کنند؟»

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

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

یک لحظه صبر کنید، پزشکان هر چند وقت یک‌بار بیمار مشترک دارند؟ آیا هر بیمار در این سیستم پزشک اصلی و پزشک ثانویه دارد؟

اصلا ممکن است یک بیمار بیش از یک پزشک اصلی داشته باشد؟

عنوان درست، پزشک اصلی است یا مراقب اصلی؟ مگر این نقش نمی‌تواند متعلق به یک پرستار متخصص باشد؟

نه، مراقبان موضوع دیگری هستند... منظورمان اعضای خانواده و مخاطبان مرتبط با بیمار است، درست است؟

پس آیا مراقبان هم در محدوده این بازطراحی قرار می‌گیرند؟

بله، چون اگر مراقبی در جلسه ویزیت حضور داشته باشد، پزشک باید این موضوع را ثبت کند. مثلا مراقب را در یادداشت پزشکی تگ کند... یا در نوبت ملاقات؟

حالا داریم به نتیجه می‌رسیم!

می‌بینید که واداشتن ذی‌نفعان به بحث درباره این پرسش‌ها چقدر می‌تواند قدرتمند باشد؟ هدف پنهان این است که اعتمادبه‌نفس آن‌ها نسبت به دانسته‌هایشان را به‌آرامی و با رعایت ملاحظات دیپلماتیک به چالش بکشیم.

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

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

دو پرسش اصلی

اما چگونه می‌توانیم به شکلی دیپلماتیک، کارآمد، مشارکتی و قابل‌اعتماد به چنین پرسش‌های عمیقی برسیم؟

می‌توانیم کار را با همان دو پرسش اصلی آغاز کنیم که با دو مرحله نخست فرایند ORCA مطابقت دارند:

• چه چیزهایی در سیستم وجود دارند؟
• این چیزها چه ارتباطی با یکدیگر دارند؟

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

در ادامه نشان می‌دهم که چگونه همین دو پرسش ساده می‌توانند چارچوب یک کارگاه تعریف اشیا (Object Definition Workshop) را تشکیل دهند. در جریان این کارگاه، پرسش‌های اولیه به ده‌ها پرسش دقیق‌تر تبدیل می‌شوند و ضرورت انجام تحقیقات بیشتر روی کاربران را آشکار می‌کنند.

آماده‌سازی: جست‌وجوی هوشمندانه اسم‌ها

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

در اصل، باید به دنبال اسم‌هایی باشید که مختص کسب‌وکار یا صنعت پروژه شما هستند و آن‌ها را از دست‌کم چند منبع مختلف استخراج کنید. من این کار را «جست‌وجوی اسم‌ها» (Noun Foraging) می‌نامم.

چند منبع مناسب برای این کار عبارت‌اند از:

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

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

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

هنگام بررسی این منابع، به اسم‌هایی توجه کنید که بارها تکرار می‌شوند و آن‌ها را فهرست کنید. اگر قرار است بعدا نقشه اشیا بسازید، بهتر است از یادداشت‌های چسبان آبی‌رنگ استفاده کنید!

تمرکز شما باید بر اسم‌هایی باشد که احتمال دارد نمایانگر یک شیء در سیستم باشند. اگر مطمئن نیستید که یک اسم ارزش تبدیل شدن به یک شیء را دارد یا نه، از سرواژه SIP استفاده کنید و سه معیار زیر را بررسی کنید:

• Structure (ساختار)
• Instances (نمونه‌های مشخص)
• Purpose (هدف)

برای مثال، یک اپلیکیشن کتابخانه را در نظر بگیرید. آیا «کتاب» یک شیء محسوب می‌شود؟

ساختار: آیا می‌توانید چند ویژگی برای این شیء احتمالی نام ببرید؟ عنوان، نویسنده، تاریخ انتشار و موارد دیگر. بله، کتاب ساختار دارد. پس این معیار تایید می‌شود.

نمونه‌های مشخص: چند نمونه از این شیء احتمالی را نام ببرید. «کیمیاگر»، «بازیکن شماره یک آماده» و «همه جیش می‌کنند». بله، این معیار هم تایید می‌شود.

هدف: چرا این شیء برای کاربران و کسب‌وکار اهمیت دارد؟ کتاب چیزی است که کتابخانه در اختیار مردم قرار می‌دهد و دلیل مراجعه بسیاری از افراد به کتابخانه است. پس این معیار نیز تایید می‌شود.

هنگام جست‌وجوی اسم‌ها، روی مواردی تمرکز کنید که هر سه معیار SIP را دارند.

از ثبت اجزایی مانند منوهای کشویی، چک‌باکس‌ها و انتخاب‌گرهای تقویم خودداری کنید. سیستم تجربه کاربری شما همان سیستم طراحی رابط کاربری نیست!

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

هیچ‌کس به فضای دیجیتال شما نمی‌آید تا با منوی کشویی بازی کند! کاربران برای دسترسی به چیزهای ارزشمند و انجام کارهایی که با آن‌ها ممکن است، به محصول مراجعه می‌کنند. ما در تلاش هستیم همین چیزها، یا همان اشیا، را شناسایی کنیم.

فرض کنید در یک استارتاپ کار می‌کنیم که می‌خواهد تجربه استفاده از ایمیل را متحول کند. من جست‌وجوی اسم‌ها را به این شکل آغاز می‌کنم.

ابتدا به سرویس ایمیلی که خودم استفاده می‌کنم، یعنی Gmail، نگاه می‌کنم. سپس Outlook و سرویس ایمیل جدید HEY را بررسی می‌کنم. بعد سراغ Yahoo و Hotmail می‌روم. حتی Slack، Basecamp و سایر ابزارهایی را که ادعا می‌کنند جایگزین ایمیل هستند بررسی می‌کنم.

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

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

و حالا... طبل‌ها را به صدا درآورید!

چند اسم که در جریان جست‌وجو پیدا کرده‌ام عبارت‌اند از:

• پیام ایمیل
• رشته گفت‌وگو (Thread)
• مخاطب
• کلاینت یا نرم‌افزار ایمیل
• قانون یا خودکارسازی (Rule/Automation)
• آدرس ایمیلی که در فهرست مخاطبان نیست
• گروه‌های مخاطبان
• فایل پیوست
• فایل Google Docs یا سایر فایل‌های یکپارچه‌شده
• خبرنامه، چون سرویس HEY با آن متفاوت از بقیه برخورد می‌کند
• پاسخ‌های ذخیره‌شده و قالب‌ها (Templates)

فهرست اسم‌های خود را مرور کنید و کلماتی را که معنایشان را اصلا نمی‌دانید مشخص کنید. در مثال ایمیل، این کلمات ممکن است «کلاینت» یا «خودکارسازی» باشند.

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

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

• Record Locator
• Incentive Home
• Augmented Line Item
• Curriculum-Based Measurement Probe

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

برگزاری کارگاه تعریف اشیا

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

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

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

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

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

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

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

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

سپس اجازه دهید بازی «موش‌وگربه پرسش‌ها» آغاز شود!

۱. این چیز چیست؟

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

سپس از همه بخواهید نوشته‌هایشان را هم‌زمان نشان دهند تا ببینید آیا تعریف‌های متفاوتی ارائه کرده‌اند یا خیر. مطمئن باشید که چنین تفاوت‌هایی پیدا خواهید کرد!

این روش برای آشکار کردن ناهماهنگی‌ها و آغاز گفت‌وگوهای سازنده، بسیار ارزشمند است.

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

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

۲. آیا کاربران این چیزها را می‌شناسند؟ کاربران از چه نامی برای آن‌ها استفاده می‌کنند؟

ذی‌نفع اول: «احتمالا کاربران به کلاینت‌های ایمیل می‌گویند اپلیکیشن، اما مطمئن نیستم.»

ذی‌نفع دوم: «فکر می‌کنم کاربران به خودکارسازی‌ها Workflow می‌گویند. البته شاید از نظر آن‌ها Workflow معنای متفاوتی داشته باشد.»

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

به این ترتیب، تیم می‌تواند با زبان و ذهنیت کاربران هماهنگ‌تر شود.

بسیار خب، برویم سراغ مرحله بعد.

اگر دو یا چند شیء پیدا کردید که از نظر هدف با یکدیگر هم‌پوشانی دارند، یکی از پرسش‌های زیر را مطرح کنید.

۳. آیا این‌ها یک چیز هستند یا دو چیز متفاوت؟ اگر متفاوت‌اند، چه تفاوتی دارند؟

شما: «آیا پاسخ ذخیره‌شده همان قالب است؟»

ذی‌نفع اول: «بله! قطعا همین‌طور است.»

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

به تکمیل واژه‌نامه اشیای خود ادامه دهید و هرگونه ابهام را نیز در فهرست «پرسش‌های بی‌پاسخ» ثبت کنید.

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

۴. این اشیا چه ارتباطی با یکدیگر دارند؟

شما: «آیا پاسخ‌های ذخیره‌شده و قالب‌ها به نوعی با هم مرتبط هستند؟»

ذی‌نفع سوم: «بله، می‌توان یک قالب را روی یک پاسخ ذخیره‌شده اعمال کرد.»

شما که همیشه پرسش‌های تکمیلی دارید، ادامه می‌دهید: «قالب چه زمانی روی پاسخ ذخیره‌شده اعمال می‌شود؟ هنگام ساخت پاسخ ذخیره‌شده یا زمانی که کاربر آن پاسخ را در یک ایمیل به کار می‌برد؟ این فرایند دقیقا چگونه کار می‌کند؟»

گوش کنید و ابهام‌ها را ثبت کنید.

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

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

می‌بینید که چگونه به‌تدریج زمینه را برای متقاعد کردن تیم به انجام تحقیقات تجربه کاربری فراهم می‌کنیم؟

۵. آیا این شیء در محدوده پروژه قرار دارد؟

پرسش بعدی تمرکز تیم را به سمت مهم‌ترین چیزها برای کاربران هدایت می‌کند.

می‌توانید به‌سادگی بپرسید: «آیا پاسخ‌های ذخیره‌شده در محدوده نسخه اول محصول قرار دارند؟»

اما من راهبردی بهتر و کمی زیرکانه‌تر پیشنهاد می‌کنم.

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

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

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

سعی کنید وقتی دوباره یکی دیگر از ناهماهنگی‌های تیم را آشکار می‌کنید، بیش از حد از نتیجه کار راضی به نظر نرسید!

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

مدیرعامل کمی عقب رفت، به تخته نگاه کرد و گفت:

«به همین دلیل است که دو سال نتوانسته‌ایم پیشرفت کنیم.»

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

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

۶. نمایش بصری روابط میان اشیا

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

برای هر شیء، بررسی کنید که چه ارتباطی با تمام اشیای دیگر دارد. این اشیا از چه راه‌هایی به هم متصل می‌شوند؟

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

در این روش، اشیا را با فعل‌ها به یکدیگر متصل می‌کنیم. من ترجیح می‌دهم از عبارت‌های ساده‌ای مانند «دارد» (Has a) و «چندین مورد دارد» (Has many) استفاده کنم.

این فعالیت مدل‌سازی سیستم، پرسش‌های تازه‌ای را مطرح می‌کند:

• آیا یک پاسخ ذخیره‌شده می‌تواند فایل پیوست داشته باشد؟
• آیا یک پاسخ ذخیره‌شده می‌تواند از یک قالب استفاده کند؟ اگر بله، وقتی ایمیلی از پاسخ ذخیره‌شده‌ای استفاده می‌کند که به قالبی متصل است، آیا کاربر می‌تواند آن قالب را تغییر دهد؟
• آیا کاربران می‌خواهند تمام ایمیل‌هایی را که شامل یک فایل پیوست مشخص بوده‌اند، مشاهده کنند؟ برای مثال: «تمام ایمیل‌هایی را که فایل ProfessionalImage.jpg را پیوست کرده‌ام نشان بده. عکس حرفه‌ای خودم را تغییر داده‌ام و می‌خواهم به همه اطلاع بدهم که آن را به‌روزرسانی کنند.»

ممکن است شرکت‌کنندگان کارگاه مستقیما پاسخ‌های روشنی ارائه دهند. عالی است! این درک مشترک جدید را ثبت کنید.

اما هر زمان که ابهامی ظاهر شد، به افزودن پرسش‌ها به فهرست در حال رشد خود ادامه دهید.

جرقه را روشن کنید

مواد منفجره را در سراسر مسیر سد چیده‌اید. حالا فقط باید فتیله را روشن کنید تا صدای انفجار بلند شود و حمایت از تحقیقات کاربری مانند سیل جاری شود!

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

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

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

بپرسید:

«اگر بدون پاسخ به این پرسش طراحی کنیم، اگر خودمان پاسخی را حدس بزنیم و اشتباه کنیم، پیامد آن چقدر می‌تواند بد باشد؟»

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

بله، این یک راهبرد حساب‌شده است و بابت آن هم عذرخواهی نمی‌کنم!

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

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

سخن پایانی: فعلا طراحی صفحه را متوقف کنید!

جدی می‌گویم، اگر امکانش وجود دارد، دیگر هیچ صفحه‌ای را پیش از پاسخ دادن به این پرسش‌های بنیادی طراحی نکنید:

اشیا چه هستند و چه ارتباطی با یکدیگر دارند؟

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

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

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

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

برای شما آرزوی موفقیت دارم!

حالا بروید و ضرورت تحقیقات کاربری را به تیم خود بفروشید!