اخیراً گفت‌وگوی جالبی با جنائه راموس (Jenae Ramos)، طراح تجربه کاربری (UX) و یکی از برگزارکنندگان رویداد Downtown UX Meetup در اورلاندو داشتم و درباره طراحی و اینترنت اشیاء (Internet of Things) صحبت کردیم. جنائه شوخی کرد که طراحی برای صفحه نمایش یعنی کار کردن با کلی “مستطیل‌های شیک”.
البته این حرف پیچیدگی طراحی UX را دست‌کم می‌گیرد، اما منظور را می‌فهمم. بعد از سال‌ها طراحی برای صفحه نمایش، میلیون‌ها حرفه‌ای در جامعه طراحی راه‌حل‌های مؤثری برای تقریباً هر مشکلی که در دنیای پیکسل‌ها پیش می‌آید پیدا کرده‌اند.
با این حال، تجربه‌های کاربری بد هنوز هم زیادند و حرفه‌ای‌ها باید تیم‌های کسب‌وکار و برنامه‌نویسی را در کل فرایند طراحی هدایت کنند (مثلاً گاهی به آن‌ها یادآوری کنند که به کاربر فکر کنند). اما مطمئنم که ارائه راه‌حل در یک صفحه تخت مستطیلی گاهی خسته‌کننده به نظر می‌رسد.
اینترنت اشیاء (Internet of Things) горизون‌های جدید و هیجان‌انگیزی فراتر از بحث مزایا و معایب یک آیکون منوی همبرگری باز می‌کند.
بسته به اینکه چه نوع طراحی هستید، فکر کردن فراتر از محدودیت‌های صفحه نمایش می‌تواند ترسناک یا رهایی‌بخش باشد. اگر از دسته اول هستید، آن را مثل زمینی پر از برف تازه ببینید که منتظر است ردپایتان را رویش بگذارید. IoT یک دنیای سه‌بعدی است که پر از مشکلات و راه‌حل‌های جدید در هر گوشه منتظر شماست.
برای شروع، پنج تصمیم مهم در طراحی UX برای خلق راه‌حل‌های واقعی IoT را که به نظرم کلیدی‌اند، برایتان آورده‌ام.
- تجربه را بهبود بدهید (Enhance the Experience)
این دسته همه‌چیز را در بر می‌گیرد. تصمیم‌های زیادی در طراحی UX می‌توان اینجا آورد: نگذارید کاربر نگران عمر باتری باشد، عملکرد را طوری کنید که فوراً حس شود و بار شناختی (Cognitive Load) را کم کنید، نه اینکه اضافه کنید.
اگر در حال توجیه اتصال چیزی به اینترنت هستید، شاید دارید از راه اشتباه به مشکل نگاه می‌کنید.
پرسیدن “اگر قهوه‌ساز به ساعتم وصل بود چه می‌شد؟” و بعد پیدا کردن دلیلش می‌تواند جالب باشد، اما شاید سؤال درست این باشد: “قهوه‌ساز ایده‌آل چطور باید کار کند؟” بعد ببینید اتصال به اینترنت چطور شما را به آن هدف نزدیک‌تر می‌کند.
این تفاوت ظریف اما مهمی است. اگر اتصال قهوه‌ساز به اینترنت تجربه را بهتر نکند، نکنید. من عاشق IoT هستم، اما اگر تجربه را بهبود ندهد، طرفدارش نخواهم بود.
- محلی کار کند (Works Locally)
هیچ‌کس – حتی پاپ (شاید به‌خصوص پاپ؟) – همیشه به اینترنت دسترسی ندارد. وقتی برای IoT طراحی می‌کنید، فرض نکنید اتصال دائمی به اینترنت وجود دارد.
ایده‌آل این است که ابتدا برای نبود اینترنت طراحی کنید و بعد ببینید چقدر از عملکرد می‌تواند محلی باشد قبل از اینکه به اینترنت نیاز پیدا کنید. مثلاً اگر چتری طراحی می‌کنید که موقع باران آبی می‌شود، یک فشارسنج (Barometer) داخلش بگذارید تا اگر نتواند آب‌وهوای محلی را از اینترنت چک کند، کار کند.
به‌عنوان نکته جانبی، آن چتر را دیوید رز (David Rose)، نویسنده کتاب Enchanted Objects ساخته. پیشنهاد می‌کنم حتماً این کتاب را بخوانید.
حتی اگر مطمئن باشیم پروتکل HTTP امروزی در آینده هم حاکم است (که نیستیم)، این احتمال واقعی وجود دارد که سرورهای الان شما برای همیشه کار نکنند. شرکت‌هایی که خریداری می‌شوند یا ورشکست می‌شوند، کاربران متصل را تنها می‌گذارند. این در تجربه‌های روی صفحه قابل‌تحمل است، اما وقتی یک کامپیوتر کوچک به دستگاه بزرگی وصل است، تغییر فروشنده خیلی سخت‌تر می‌شود.
- قابل ارتقا باشد (Upgradeable)
چرخه عمر دستگاه‌های متصل خیلی طولانی‌تر از این است که فکر کنیم کاربران هر دو سال مثل گوشی عوضشان می‌کنند. سازندگان گوشی می‌توانند همه‌چیز را یکپارچه کنند، چون می‌دانند کاربران بعد از دو سال آن را با یک صفحه جدید جایگزین می‌کنند. اما وسایلی مثل ماشین لباسشویی یا اجاق گاز 5 تا 10 سال عمر می‌کنند و خریداران صرفه‌جو حتی بیشتر نگهشان می‌دارند. گوشی‌تان 10 سال پیش چه شکلی بود؟
به‌جای اینکه کاربران را با سخت‌افزار قدیمی که به ماشین لباسشویی کاملاً سالمشان وصل است تنها بگذارید، طراحی خوب باید امکان ارتقای آسان واحد پردازش را بدون تأثیر روی بقیه دستگاه فراهم کند – آسان یعنی بدون نیاز به ابزار. ماژولار کردن طراحی می‌تواند امکان فروش ارتقاها را در آینده باز کند؛ برد-برد برای کسب‌وکار و مصرف‌کننده.
این برای نرم‌افزار هم صدق می‌کند. یک سیاست پشتیبانی شفاف و قابل‌فهم بدهید. اگر ایده می‌خواهید، شرکت‌های نرم‌افزاری مثل مایکروسافت (Microsoft) را ببینید که دقیق می‌گویند هر محصولشان تا کی پشتیبانی می‌شود – شما هم باید همین کار را کنید.
به نظرم این یک ملاحظه تجربه کاربری است، چون ندانستن اینکه خدمات کی قطع می‌شود، برای هر مصرف‌کننده آگاهی اضطراب ایجاد می‌کند. با افزایش محصولاتی که پشتیبانی‌شان ناگهان قطع می‌شود، کاربرانتان باید دقیق بدانند تا کی پشتیبانی دارید: کی آپدیت‌های بی‌سیم (Over-the-Air Updates) قطع می‌شود؟ کی باید برای پشتیبانی تلفنی پول بدهند (اگر اصلاً باشد)؟ اگر شرکت تعطیل شود چه می‌شود؟ ضمانت uptime خدمات متصل به اینترنت چیست؟ و بعد از پایان پشتیبانی چه می‌شود؟
پیشنهادم این است که وقتی پشتیبانی تمام شد، کد منبع‌باز (Open Source) شود و به کاربران اجازه دهید دستگاهشان را هک کنند و ارتقا دهند. اگر شما پشتیبانی نمی‌کنید، ابزارهایی به کاربران بدهید تا خودشان این کار را بکنند.
- قابل گسترش باشد (Extendable)
APIها. این کلمه سه‌حرفی زیبا که موسیقی گوش هر توسعه‌دهنده‌ای است. مطمئن شوید هر چیزی که می‌سازید یک API داشته باشد، چون کاربردهایی برای محصولتان وجود دارد که به ذهنتان هم نرسیده. قدرت واقعی IoT در تعاملات یک‌به‌یک بین دستگاه شما و سرویس ابری که مدیریتش می‌کنید نیست، بلکه در تعامل دستگاهتان با همه دستگاه‌های دیگر است!
هر وقت ممکن و امن باشد که کاربر بتواند به دستگاه شما وصل شود، آن را کنترل کند و اطلاعاتش را بخواند، این امکان را فراهم کنید. کاربرانتان از شما تشکر خواهند کرد.
- امن باشد (Secure)
آیا امنیت یک تصمیم تجربه کاربری است؟ از کاربرانی که مانیتور کودکشان هک شده بپرسید. “هک شدن” وقتی دستگاهتان را امن نکنید، اصطلاح گُنگی است. منظورم این است که از ابتدا برای امنیت طراحی کنید. انتظار ندارم طراحان UX آخرین اقدامات امنیتی را پیاده کنند، اما اصول اولیه را بفهمید و از طرف کاربر دفاع کنید.
نتیجه‌گیری: طراحی UX برای IoT
بعد از فرایند طراحی، چیزی خواهید ساخت که کاربران هر روز با لذت از آن استفاده کنند. به لطف تلاش شما، همه ناشناخته‌های رایج در فناوری‌های امروزی پاسخ پیدا کرده‌اند.
آن‌ها می‌دانند که 5 یا 10 سال دیگر هم می‌توانند از آن استفاده کنند، حتی اگر شرکت خریداری شود.
می‌دانند حتی اگر اینترنت امروزی با پروتکل‌ها یا فناوری‌های دیگر جایگزین شود، می‌توانند تجربه‌شان را به دلخواه ارتقا دهند یا گسترش دهند، یا فقط محلی کار کند.
کنترل تجربه دست آن‌هاست و هرچند اتصال به اینترنت تجربه را بهتر می‌کند، آن را محدود یا کنترل نمی‌کند.
همه این مزیت‌ها به لطف تلاش شما به‌عنوان طراح تجربه کاربری IoT است. پس دست به کار شوید و این دنیای جدید را به شکلی دوست‌داشتنی طراحی کنید!
منبع: iotforall