فرض کنیم قرار است یک اپلیکیشن مسیریابی را برای کسی طراحی کنیم که اینترنت پایداری ندارد. کاربر ممکن است وسط مسیر ارتباطش را از دست بدهد، نقشه بارگذاری نشود یا نتواند مسیر جایگزین پیدا کند.
اولین واکنش شاید این باشد که قابلیت استفاده آفلاین را اضافه کنیم، حجم داده‌های نقشه را کاهش دهیم یا نسخه سبک‌تری از اپلیکیشن بسازیم.
اما از کجا معلوم مشکل اصلی همین‌هاست؟
شاید کاربر اصلا به نقشه کامل نیاز نداشته باشد. شاید فقط بخواهد مسیر همیشگی خانه تا محل کارش را پیدا کند. حتی ممکن است مشکل او بیشتر از اینکه به اینترنت مربوط باشد، به ناآشنایی با محیط یا هزینه مصرف داده برگردد.
اینجاست که تفاوت بین طراحی یک قابلیت و حل یک مسئله واقعی مشخص می‌شود.
سوال مصاحبه امروز:
یکی از محصولاتی را که هر روز استفاده می‌کنید انتخاب کنید. چطور آن را برای فردی با دسترسی محدود طراحی می‌کنید؟
این سوال در دسته Product Sense و طراحی محصول قرار می‌گیرد و در نگاه اول ساده به نظر می‌رسد. اما پاسخ خوب به آن فقط به خلاقیت در پیشنهاد قابلیت‌های جدید وابسته نیست.
مصاحبه‌کننده دنبال چیست؟
مصاحبه‌کننده می‌خواهد بفهمد آیا می‌توانیم از یک درخواست مبهم به یک مسئله مشخص، قابل بررسی و قابل حل برسیم یا نه.
در واقع چند توانایی را هم‌زمان ارزیابی می‌کند:
- آیا قبل از پیشنهاد راهکار، مسئله و محدودیت کاربر را روشن می‌کنیم؟
- آیا می‌توانیم از بین چند گروه کاربری، یک گروه مشخص را برای شروع انتخاب کنیم؟
- آیا نیاز واقعی را از فرضیات خودمان جدا می‌کنیم؟
- آیا می‌توانیم بین پوشش کاربران بیشتر و حل عمیق‌تر یک مشکل تصمیم بگیریم؟
- آیا راهکاری پیشنهاد می‌کنیم که با منابع محدود قابل آزمایش باشد؟
- آیا می‌دانیم چه شواهدی می‌تواند تصمیم اولیه ما را تغییر دهد؟
نکته مهم این است که مصاحبه‌کننده لزوما دنبال بهترین ایده نیست. بیشتر می‌خواهد منطق رسیدن به آن ایده را ببیند.
۱. اول مشخص کنیم دسترسی محدود یعنی چه
عبارت «دسترسی محدود» به‌تنهایی اطلاعات زیادی به ما نمی‌دهد.
ممکن است درباره فردی صحبت کنیم که اینترنت ضعیفی دارد، از گوشی قدیمی استفاده می‌کند، محدودیت بینایی یا حرکتی دارد، با زبان محصول آشنا نیست یا توانایی پرداخت هزینه اشتراک را ندارد.
این کاربران مشکلات یکسانی ندارند و طبیعتا یک راهکار نمی‌تواند بدون بررسی برای همه آن‌ها مناسب باشد.
پس اولین قدم در مصاحبه، روشن کردن دامنه مسئله است.
مثلا می‌توانیم بپرسیم:
«منظور از دسترسی محدود، محدودیت اینترنت و دستگاه است یا محدودیت‌های جسمی و شناختی؟ و انتظار داریم کاربر کدام کار اصلی را بتواند انجام دهد؟»
اگر مصاحبه‌کننده توضیح بیشتری نداد، نباید متوقف شویم. یک فرض مشخص انتخاب می‌کنیم و آن را شفاف می‌گوییم.
برای ادامه این مثال فرض می‌کنیم کاربر به اینترنت موبایل پایدار دسترسی ندارد و می‌خواهیم تجربه یک اپلیکیشن مسیریابی را برای او بهتر کنیم.
این فرض، محدوده پاسخ ماست؛ نه ادعایی درباره تمام افرادی که دسترسی محدود دارند.
۲. کاربر را انتخاب کنیم، نه اینکه محصول را برای همه طراحی کنیم
حالا باید مشخص کنیم دقیقا کدام کاربر را هدف گرفته‌ایم.
برای مسیریابی چند گروه احتمالی داریم: مسافران جاده‌ای، رانندگان، گردشگران، افرادی که در مناطق کم‌پوشش زندگی می‌کنند و کسانی که هر روز از حمل‌ونقل عمومی استفاده می‌کنند.
هر گروه شرایط متفاوتی دارد.
مثال فرضی:
کاربری را در نظر بگیریم که هر روز با اتوبوس به محل کار می‌رود. اینترنت موبایل او محدود و ناپایدار است. معمولا مسیر مشخصی دارد، اما گاهی لازم است ایستگاه‌ها یا ادامه مسیر را دوباره بررسی کند.
نیاز او این نیست که تمام امکانات یک مسیریاب حرفه‌ای را داشته باشد.
نیاز اصلی این است که بتواند در زمان قطع اینترنت، مسیر از قبل آماده‌شده و اطلاعات ضروری مربوط به آن را پیدا کند و بفهمد کدام بخش اطلاعات هنوز قابل اعتماد است.
چرا این گروه را برای شروع انتخاب می‌کنیم؟
چون مسئله در یک فعالیت پرتکرار اتفاق می‌افتد، می‌توانیم شرایط استفاده را مشاهده کنیم و موفقیت یا شکست انجام کار را در یک آزمایش محدود بسنجیم.
البته این انتخاب هنوز یک فرضیه است. باید با تحقیق بررسی کنیم که مشکل واقعا برای این گروه تکرار می‌شود و ارزش حل کردن دارد.
انتخاب یک گروه مشخص به معنای نادیده گرفتن سایر کاربران نیست. یعنی فعلا می‌خواهیم یک مسئله را درست بفهمیم و بعد درباره گسترش راهکار تصمیم بگیریم.
۳. قبل از طراحی، رفتار فعلی کاربر را بررسی کنیم
یکی از اشتباهات رایج این است که بعد از انتخاب کاربر، بلافاصله سراغ طراحی صفحه‌ها و قابلیت‌ها برویم.
در حالی که هنوز نمی‌دانیم کاربر امروز چگونه مشکلش را حل می‌کند.
ممکن است قبل از حرکت از مسیر اسکرین‌شات بگیرد، آدرس‌ها را در پیام‌رسان ذخیره کند، از دیگران کمک بخواهد یا بعضی مسیرها را به دلیل نبود اینترنت انتخاب نکند.
این رفتارها ارزش بررسی دارند.
من ابتدا می‌خواهم سه موضوع را بفهمم:
شدت مشکل: وقتی اینترنت قطع می‌شود، چه اتفاقی می‌افتد؟ فقط چند ثانیه منتظر می‌ماند یا ممکن است مسیرش را گم کند؟
تکرار مشکل: این وضعیت چند وقت یک بار اتفاق می‌افتد و در کدام بخش سفر بیشتر دیده می‌شود؟
راهکار فعلی: کاربر الان چه کاری انجام می‌دهد و چرا آن راهکار برایش کافی نیست؟
برای پاسخ، می‌توانیم با تعدادی از کاربران همین گروه مصاحبه کنیم، انجام یک مسیر واقعی را مشاهده کنیم و در صورت وجود داده، رفتار استفاده از محصول هنگام اتصال ضعیف را بررسی کنیم.
داده‌های تحلیلی به‌تنهایی کافی نیستند. مثلا خطای بارگذاری نقشه نشان می‌دهد یک درخواست ناموفق بوده، اما لزوما نمی‌گوید کاربر در نهایت توانسته مسیرش را پیدا کند یا نه.
از طرف دیگر، نباید فقط به گفته‌های کاربران تکیه کنیم. دیدن رفتار آن‌ها در شرایط واقعی می‌تواند مشکلاتی را آشکار کند که در مصاحبه به آن اشاره نکرده‌اند.
۴. چه راهکارهایی داریم و کدام را انتخاب می‌کنیم؟
بعد از بررسی اولیه، چند مسیر طراحی پیش رو داریم.
راهکار اول: نسخه سبک‌تر محصول
مصرف اینترنت را کاهش دهیم و بخش‌های غیرضروری را حذف کنیم.
مزیت آن بهبود تجربه در اتصال ضعیف است، اما در قطع کامل اینترنت ممکن است همچنان کاربر را بدون راهکار بگذارد.
راهکار دوم: ذخیره نقشه یک محدوده
کاربر بتواند نقشه منطقه موردنظرش را از قبل دریافت کند.
این راهکار انعطاف بیشتری دارد، ولی ممکن است به فضای ذخیره‌سازی زیاد نیاز داشته باشد و کاربر هم نداند دقیقا کدام منطقه را باید دریافت کند.
راهکار سوم: ذخیره مسیرهای پرتکرار
کاربر بتواند مسیرهای مهم زندگی روزمره‌اش را از قبل آماده کند و هنگام قطع اینترنت به اطلاعات ضروری آن‌ها دسترسی داشته باشد.
برای گروه انتخاب‌شده، من راهکار سوم را به‌عنوان فرضیه اولیه انتخاب می‌کنم.
چرا؟
چون مسئله ما پیدا کردن هر مسیر ممکنی نیست. می‌خواهیم کاربر بتواند در شرایط اتصال نامطمئن، کار اصلی و پرتکرار خودش را انجام دهد.
در نتیجه به جای ساختن یک مسیریاب کامل آفلاین، روی دسترسی مطمئن به تعداد محدودی مسیر تمرکز می‌کنیم.
این تصمیم یک هزینه هم دارد: کاربری که مرتب مقصدش تغییر می‌کند، احتمالا ارزش کمتری از نسخه اولیه دریافت خواهد کرد.
پذیرفتن آگاهانه همین محدودیت، بخشی از تصمیم‌گیری محصول است.
۵. نسخه اولیه محصول چه چیزی داشته باشد؟
برای شروع، به مجموعه بزرگی از قابلیت‌ها نیاز نداریم.
نسخه اولیه می‌تواند به کاربر اجازه دهد مسیر مشخصی را هنگام اتصال به اینترنت ذخیره کند و بعدا اطلاعات پایه آن را بدون اینترنت ببیند.
برای مثال:
- مسیر ذخیره‌شده و نقاط مهم آن در دسترس باشد.
- حجم داده‌ای که باید دریافت شود، مشخص باشد.
- زمان آخرین به‌روزرسانی اطلاعات نمایش داده شود.
- اگر اطلاعاتی مانند وضعیت لحظه‌ای ترافیک یا زمان رسیدن اتوبوس در دسترس نیست، این محدودیت صریحا اعلام شود.
- کاربر بتواند مسیر ذخیره‌شده را بدون جست‌وجوی مجدد پیدا کند.
یک نکته فنی مهم وجود دارد: ذخیره نقشه، به معنای در دسترس بودن تمام قابلیت‌های مسیریابی در حالت آفلاین نیست.
مثلا در Google Maps امکان دریافت نقشه برای استفاده آفلاین وجود دارد، اما براساس راهنمای رسمی گوگل، مسیریابی پیاده، دوچرخه و حمل‌ونقل عمومی در حالت آفلاین در دسترس نیست و اطلاعات لحظه‌ای ترافیک هم ارائه نمی‌شود.
بنابراین در محصول فرضی خودمان هم نباید صرفا با ذخیره یک نقشه، به کاربر وعده مسیریابی کامل و به‌روز بدهیم.
اگر نمی‌توانیم تغییر مسیر اتوبوس یا برنامه جدید حرکت آن را تایید کنیم، باید این موضوع را روشن نشان دهیم.
گاهی نمایش صادقانه محدودیت، از اضافه کردن یک قابلیت ظاهرا جذاب ارزشمندتر است.
۶. از کجا بفهمیم طراحی موفق بوده است؟
موفقیت را نباید فقط با تعداد دانلود نقشه‌ها یا دفعات باز شدن قابلیت اندازه بگیریم.
ممکن است کاربران زیادی مسیر ذخیره کنند، اما وقتی اینترنت قطع می‌شود باز هم نتوانند کاری انجام دهند.
پس باید معیارها را به نتیجه‌ای که برای کاربر مهم است وصل کنیم.
معیار اصلی موفقیت:
درصد کاربرانی که در شرایط بدون اینترنت می‌توانند مسیر از قبل آماده‌شده را پیدا کنند و اطلاعات ضروری آن را با موفقیت بخوانند.
این معیار را می‌توانیم در یک آزمون کاربردپذیری کنترل‌شده بسنجیم. البته موفقیت این آزمون به‌تنهایی ثابت نمی‌کند که کاربر در دنیای واقعی حتما به مقصد رسیده است.
معیارهای تشخیصی:
زمان لازم برای باز کردن مسیر، تعداد تلاش‌های ناموفق و میزان نیاز به کمک دیگران.
معیارهای محافظتی:
مصرف حافظه و اینترنت، خطاهای اطلاعاتی، میزان سردرگمی درباره به‌روز بودن مسیر و مواردی که اطلاعات قدیمی باعث تصمیم اشتباه می‌شوند.
چرا معیار محافظتی مهم است؟
چون ممکن است دسترسی آفلاین را بهتر کنیم، اما در عوض کاربر به اطلاعات قدیمی اعتماد کند و مسیر اشتباهی برود.
در این وضعیت افزایش نرخ استفاده لزوما به معنای موفقیت محصول نیست.
قبل از شروع آزمایش باید مشخص کنیم چه تغییری را موفقیت می‌دانیم، چه ریسکی قابل قبول نیست و تحت چه شرایطی راهکار را تغییر می‌دهیم.
۷. اگر فقط دو هفته فرصت داشته باشیم چه می‌کنیم؟
این یکی از سوالات تکمیلی مهم مصاحبه است.
پاسخ مناسب این نیست که قول بدهیم در دو هفته همه امکانات محصول را توسعه می‌دهیم.
هدف باید کاهش عدم قطعیت باشد.
در چند روز اول با کاربران گروه هدف صحبت می‌کنیم و تجربه آن‌ها را در شرایط اینترنت ضعیف بررسی می‌کنیم. می‌خواهیم مطمئن شویم مشکل پرتکرار است، چه پیامدی دارد و راهکارهای فعلی چرا کافی نیستند.
سپس یک نمونه اولیه می‌سازیم که امکان ذخیره و بازیابی یک مسیر را شبیه‌سازی کند.
در ادامه از کاربران می‌خواهیم در شرایط قطع اینترنت، چند کار مشخص را با نمونه انجام دهند.
در پایان دو هفته باید بتوانیم به چند سوال پاسخ دهیم:
آیا کاربران واقعا به این قابلیت نیاز دارند؟ آیا بدون راهنمایی می‌توانند از آن استفاده کنند؟ آیا اطلاعات موجود برای تصمیم‌گیری کافی است؟ و آیا ابهام درباره به‌روز بودن داده‌ها خطر ایجاد می‌کند؟
اگر پاسخ‌ها امیدوارکننده بود، می‌توانیم درباره توسعه واقعی تصمیم بگیریم.
اگر نبود، بهتر است قبل از صرف هزینه بیشتر، فرضیه را اصلاح کنیم.
۸. چه شواهدی باعث می‌شود راهکارمان را کنار بگذاریم؟
یک مدیر محصول نباید آن‌قدر به راهکار اولیه خودش وابسته شود که شواهد مخالف را نادیده بگیرد.
برای مثال، اگر تحقیق نشان دهد کاربران بیشتر از مسیرهای ثابت، به تغییر مسیرهای لحظه‌ای نیاز دارند، راهکار ذخیره مسیرهای پرتکرار احتمالا کافی نیست.
یا شاید متوجه شویم مشکل اصلی، دریافت نقشه نیست؛ کاربران مسیر را دارند اما نمی‌توانند اطلاعات آن را درست تفسیر کنند.
حتی ممکن است قابلیت مشابهی از قبل در محصول وجود داشته باشد و کاربران فقط آن را پیدا نکنند.
در این حالت شاید بهبود دسترسی به قابلیت موجود، از توسعه قابلیت جدید ارزشمندتر باشد.
همچنین اگر داده‌های مسیر آن‌قدر سریع تغییر کنند که نسخه آفلاین به شکل خطرناکی قدیمی شود، باید راهکار را بازنگری کنیم.
نکته این است که از ابتدا بدانیم چه شواهدی می‌تواند فرضیه ما را رد کند.
این رویکرد با تصمیم‌گیری قاطع تضادی ندارد. برعکس، نشان می‌دهد تصمیم ما بر پایه شواهد است، نه علاقه شخصی به یک ایده.
۹. پاسخ مناسب در جلسه مصاحبه چطور بیان می‌شود؟
اگر بخواهم این سوال را در یک مصاحبه واقعی پاسخ دهم، چیزی شبیه این می‌گویم:
«اول مشخص می‌کنم منظور از دسترسی محدود چیست، چون محدودیت اینترنت، توانایی جسمی یا هزینه استفاده، مسئله‌های متفاوتی ایجاد می‌کنند.
برای این مثال فرض می‌کنم کاربر اینترنت پایداری ندارد و محصولی که انتخاب می‌کنم یک اپلیکیشن مسیریابی است.
از بین گروه‌های مختلف، ابتدا روی افرادی تمرکز می‌کنم که مسیرهای روزمره و تکراری دارند. بررسی می‌کنم قطع اینترنت دقیقا در کدام مرحله آن‌ها را متوقف می‌کند و امروز چطور این مشکل را دور می‌زنند.
بعد چند گزینه مثل نسخه سبک‌تر، نقشه آفلاین و ذخیره مسیرهای پرتکرار را مقایسه می‌کنم.
انتخاب اولیه من ذخیره مسیرهای ضروری است، چون با فرض فعلی می‌توانیم مسئله مشخصی را با هزینه محدودتر آزمایش کنیم.
برای سنجش موفقیت، فقط تعداد استفاده از قابلیت را بررسی نمی‌کنم. می‌خواهم ببینم کاربران در نبود اینترنت واقعا می‌توانند اطلاعات موردنیازشان را پیدا کنند یا نه.
در کنار آن مصرف داده، خطاها و خطر اعتماد به اطلاعات قدیمی را هم کنترل می‌کنم.
اگر تحقیق نشان دهد نیاز اصلی کاربران چیز دیگری است، راهکار را تغییر می‌دهم. ترجیح می‌دهم زودتر متوجه اشتباه بودن فرضیه شوم تا اینکه محصول اشتباهی را با کیفیت بالا بسازیم.»
این پاسخ نه بیش از حد کلی است و نه وارد جزئیات فنی غیرضروری می‌شود.
مهم‌تر اینکه یک تصمیم مشخص دارد و توضیح می‌دهد چرا به آن رسیده‌ایم.
۱۰. چه پاسخ‌هایی در مصاحبه ضعیف محسوب می‌شوند؟
«یک نسخه ساده‌تر برای همه کاربران می‌سازم.»
ساده‌تر شدن لزوما به معنای قابل استفاده‌تر شدن نیست. بدون شناخت محدودیت و کار اصلی، ممکن است قابلیت‌های موردنیاز کاربر را هم حذف کنیم.
«تمام قابلیت‌ها را آفلاین می‌کنم.»
این پاسخ محدودیت هزینه، پیچیدگی فنی، حجم داده و به‌روز بودن اطلاعات را نادیده می‌گیرد.
«از هوش مصنوعی استفاده می‌کنم تا تجربه هوشمندتر شود.»
تا زمانی که مسئله را مشخص نکرده‌ایم، اضافه کردن فناوری جدید توضیح نمی‌دهد چه چیزی برای کاربر بهتر خواهد شد.
«اگر کاربران از محصول راضی بودند، موفق شده‌ایم.»
رضایت مهم است، اما باید بدانیم کاربر موفق به انجام چه کاری شده و محصول چه پیامدهای منفی احتمالی داشته است.
«از همان اول برای تمام افراد با دسترسی محدود طراحی می‌کنم.»
طراحی فراگیر ارزشمند است، اما به معنای یکسان دانستن نیاز همه کاربران نیست. می‌توانیم با شناخت عمیق یک محدودیت شروع کنیم و سپس راهکار را برای گروه‌های دیگر گسترش دهیم.
در طراحی فراگیر مایکروسافت هم یکی از اصول کلیدی همین است: مسئله یک گروه را عمیق بفهمیم و ببینیم راهکار آن چگونه می‌تواند به افراد بیشتری کمک کند.
جمع‌بندی
برای طراحی محصولی که افراد با دسترسی محدود هم بتوانند از آن استفاده کنند، نباید از فهرست قابلیت‌ها شروع کنیم. ابتدا باید نوع محدودیت، کاربر هدف و کاری را که انجام دادنش دشوار شده مشخص کنیم. سپس رفتار فعلی کاربران را بررسی کنیم، چند راهکار را مقایسه کنیم و کوچک‌ترین راهکار قابل آزمایش را انتخاب کنیم.
در مثال مسیریابی، با فرض اینترنت ناپایدار و مسیرهای روزمره، ذخیره مسیرهای ضروری را برای آزمایش اولیه انتخاب کردیم. دلیل این تصمیم، تمرکز روی یک نیاز مشخص و امکان سنجش آن با هزینه محدود است؛ نه اینکه این راهکار برای تمام کاربران بهترین انتخاب باشد. اگر شواهد نشان دهند کاربران بیشتر به تغییر مسیر لحظه‌ای نیاز دارند یا اطلاعات آفلاین به اندازه کافی قابل اعتماد نیست، باید تصمیم را تغییر دهیم.
تفاوت پاسخ یک کاندیدای قوی با یک پاسخ معمولی در تعداد ایده‌ها نیست؛ در توانایی تعریف مسئله، انتخاب آگاهانه، پذیرش هزینه تصمیم و مشخص کردن شرایطی است که آن تصمیم باید دوباره بررسی شود.
منابع
- Microsoft Inclusive Design، اصول طراحی فراگیر: https://inclusive.microsoft.design/
- Google Android Developers، راهنمای معماری محصولات آفلاین: https://developer.android.com/topic/architecture/data-layer/offline-first
- Google Maps Help، قابلیت‌ها و محدودیت‌های نقشه آفلاین: https://support.google.com/maps/answer/6291838
- W3C، محدودیت‌های دائمی، موقت و موقعیتی کاربران: https://www.w3.org/WAI/people-use-web/abilities-barriers/
