تصمیم‌های طراحی محصول با هوش مصنوعی: طراح، کاربر و برنامه‌نویس سرِ یک میز
بیشترِ دعواهایِ طراحیِ محصول بینِ سه نگاه است: آن‌چه زیباست، آن‌چه کاربر می‌فهمد و آن‌چه ساختنش می‌ارزد. این مقاله نشان می‌دهد چطور این سه نگاه را با چند مدل و اسکرین‌شاتِ طرحت شبیه‌سازی کنی، و کجا باید سراغِ کاربرِ واقعی بروی.
تصمیم‌های طراحی محصول با هوش مصنوعی وقتی مفید می‌شوند که طرحت را، ترجیحاً با اسکرین‌شات، به چند مدل با نقش‌هایِ جدا بدهی: یکی از جایِ طراح، یکی از جایِ کاربر و یکی از جایِ برنامه‌نویس. هر نقش چیزی را می‌بیند که دیگری نمی‌بیند، و وقتی هم را نقد می‌کنند، معامله‌هایِ پنهانِ یک تصمیمِ طراحی رو می‌شود. نتیجه جایِ آزمونِ کاربریِ واقعی را نمی‌گیرد، اما کمک می‌کند با گزینه‌هایِ بهتری سراغش بروی.
کدام تصمیم‌های طراحی محصول با هوش مصنوعی به نتیجه می‌رسند
هر تصمیمِ طراحی‌ای ارزشِ یک نشست را ندارد. رنگِ یک دکمه را بهتر است با آزمایش روی کاربرِ واقعی بسنجی تا با بحث. اما این‌ها نمونه‌هایی‌اند که بحثِ چندنگاهی واقعاً کمک می‌کند:
- ساختارِ یک جریان: ثبت‌نام در یک مرحله یا چند مرحله؟ پرداخت در یک صفحه یا چند صفحه؟
- اولویت‌بندیِ یک صفحه: در صفحه‌ی اولِ داشبورد چه چیزی باید اول دیده شود و چه چیزی می‌تواند یک کلیک دورتر باشد؟
- انتخاب بینِ دو یا سه الگو: منویِ پایینِ صفحه در موبایل یا منویِ کشویی؟ فیلترِ کناری یا فیلترِ بالایِ فهرست؟
- متن‌هایِ رابطِ کاربری: پیامِ خطا، متنِ دکمه‌ها، توضیحِ یک فرمِ پیچیده.
- قبل از ساختن: این قابلیت با این پیچیدگی ارزشِ زمانِ ساختن دارد یا نسخه‌ی ساده‌ترش کافی است؟
نقطه‌ی مشترکِ این‌ها این است که جوابشان به معامله بینِ چند خواسته بستگی دارد، نه به یک واقعیتِ قابلِ جست‌وجو.
سه نقش و آن‌چه هر کدام می‌بیند
در چندهوش هر صندلی نقش می‌گیرد و برایِ کارِ طراحی قالبِ نقشِ حرفه‌ایِ «طراحی» هست. پیشنهادِ ما این است که حداقل این سه نگاه سرِ میز باشند:
| نقش | به چه نگاه می‌کند | سؤالی که مدام می‌پرسد |
|---|---|---|
| طراح | سلسله‌مراتبِ دیداری، هم‌خوانی با بقیه‌ی محصول، خوانایی، فاصله‌ها و الگوهایِ آشنا | چشم اول کجا می‌رود و آیا همان‌جا باید برود؟ |
| کاربر | فهمیدنِ صفحه بدونِ توضیح، تعدادِ قدم‌ها، ترس از اشتباه، کار با یک دست رویِ گوشی | من این‌جا چه کار باید بکنم و اگر اشتباه کنم چه می‌شود؟ |
| برنامه‌نویس | هزینه‌ی ساختن و نگه‌داری، حالت‌هایِ خالی و خطا و بارگذاری، کارایی، سازگاری با سامانه‌ی فعلی | این را با چه هزینه‌ای می‌سازیم و چه چیزی در آن می‌شکند؟ |
برایِ نقشِ کاربر، بهتر است در متنِ موضوع مشخص کنی کدام کاربر: «کاربرِ تازه‌واردی که اولین بار از گوشی وارد می‌شود» خیلی مفیدتر از «کاربر» است. اگر محصولت چند گروه کاربر دارد، می‌توانی دو صندلی با دو تعریفِ متفاوت بگذاری. نقشِ برنامه‌نویس هم معمولاً همان جایی است که تیم‌هایِ طراحی کم می‌آورند: حالت‌هایی مثلِ «فهرستِ خالی» یا «اتصال قطع شد» که در طرحِ زیبا دیده نمی‌شوند. اگر بعدتر خودِ کدِ پیاده‌سازی را هم خواستی بسنجی، سراغِ بررسی کد با هوش مصنوعی برو.
صندلیِ «وکیلِ مدافعِ شیطان» هم در بحثِ طراحی جایِ خوبی دارد، به‌خصوص وقتی تیم عاشقِ یک طرح شده و می‌خواهی کسی رسماً مخالفت کند.
اسکرین‌شات و تصویر: چه بدهی و چطور
حرف زدن درباره‌ی طرح بدونِ دیدنش سخت است. در چندهوش می‌توانی تصویر پیوست کنی، پس اسکرین‌شاتِ صفحه‌ها یا خروجیِ طرح را بده. همه‌یِ مدل‌ها تصویر را به یک اندازه نمی‌فهمند، پس برایِ این نوع نشست مدل‌هایی را سرِ میز بنشان که تصویر را پشتیبانی می‌کنند و مهم‌ترین نکته‌یِ هر تصویر را در یک جمله در متن هم بنویس. چند نکته کیفیتِ نقد را خیلی بالا می‌برد:
- ترتیبِ جریان را روشن کن. اگر چند صفحه را نشان می‌دهی، در متن بنویس کدام تصویر قدمِ اول است و کاربر با چه کاری به قدمِ بعد می‌رود.
- زمینه را بنویس. تصویر نمی‌گوید کاربر از کجا آمده، چه عجله‌ای دارد و قبل از این صفحه چه دیده. این‌ها را در یکی دو جمله بگو.
- گزینه‌ها را کنارِ هم بده. اگر بینِ دو طرح مردّدی، از هر دو اسکرین‌شات بده و نامشان را «طرحِ الف» و «طرحِ ب» بگذار تا در بحث قابلِ ارجاع باشند.
- داده‌ی واقعی را پاک کن. اگر اسکرین‌شات از محصولِ زنده است، نام، شماره، ایمیل و هر اطلاعاتِ شخصیِ کاربران را پیش از پیوست بپوشان.
- اگر داده‌ی رفتاری داری، پیوست کن. یک فایلِ CSV یا Excel از جایی که کاربران در یک جریان رها می‌کنند، نقد را از سلیقه به شواهد می‌برد.
اگر محصولت فارسی و راست‌به‌چپ است، این را هم صریح بگو و از یک صندلی بخواه جهتِ آیکون‌ها، ترتیبِ دکمه‌ها و نمایشِ عددها را جداگانه بسنجد؛ این‌ها جزئیاتی‌اند که به‌راحتی از نگاه می‌افتند.
چطور سؤالِ طراحی را بنویسی
سؤالِ «این طرح خوب است؟» تقریباً همیشه جوابِ مؤدبانه و بی‌خاصیت می‌گیرد. سؤالِ خوب هدفِ صفحه، کاربرِ هدف، معیارِ موفقیت و گزینه‌ها را دارد. مقایسه کن:
ضعیف: نظرتان درباره‌ی صفحه‌ی ثبت‌نام‌مان چیست؟
بهتر: هدفِ این صفحه این است که کاربرِ تازه‌وارد از گوشی در کمتر از یک دقیقه ثبت‌نام کند. بینِ طرحِ الف (همه‌ی فیلدها در یک صفحه) و طرحِ ب (سه قدمِ کوتاه) مردّدیم. برایمان مهم‌تر از زیبایی، کم شدنِ رهاکردنِ فرم است. هزینه‌ی ساختنِ طرحِ ب را هم در نظر بگیرید.
برایِ دو گزینه، «مناظره» جوابِ روشنی می‌دهد: یک طرف از الف دفاع می‌کند، طرفِ دیگر از ب، و داورِ مستقل می‌گوید کدام استدلال قوی‌تر بود. روشِ این کار را در مناظره هوش مصنوعی توضیح داده‌ایم. برایِ سه گزینه یا بیشتر، «آرنا» مناسب‌تر است. و اگر هنوز گزینه نداری و می‌خواهی ایده ببینی، «تولیدِ ایده‌ی عمیق» را امتحان کن.
یک نمونه‌ی فرضی: صفحه‌ی پرداختِ یک فروشگاهِ آنلاین در موبایل
این بخش نمونه‌ی فرضی است و فقط شکلِ کار را نشان می‌دهد؛ نشست، محصول و نتیجه‌ی واقعی نیست.
فرض کن در تیمِ یک فروشگاهِ آنلاینِ لوازمِ خانگی هستی و بیشترِ خریدها از گوشی انجام می‌شود. صفحه‌ی پرداختِ فعلی یک فرمِ بلند است و تیم بینِ دو طرح بحث دارد: طرحِ الف همان یک صفحه با فیلدهایِ مرتب‌تر و آدرس‌هایِ ذخیره‌شده در بالا؛ طرحِ ب سه قدم (آدرس، زمانِ ارسال، پرداخت) با نوارِ پیشرفت.
- نوعِ نشست: «مناظره»، چون دو گزینه‌ی مشخص داری.
- صندلی‌ها: چهار صندلی از خانواده‌هایِ مختلف با قالبِ «طراحی». در طرفِ الف یک طراح و یک برنامه‌نویس، در طرفِ ب یک طراح و یک صندلی که نقشِ «خریدارِ میان‌سالی که اولین بار از این فروشگاه می‌خرد» را دارد.
- عمق: «عادی».
- پیوست‌ها: اسکرین‌شاتِ صفحه‌ی فعلی، دو تصویر از طرح‌هایِ الف و ب با اطلاعاتِ شخصیِ پوشانده‌شده، و یک فایلِ CSV که نشان می‌دهد کاربران در کدام بخشِ فرمِ فعلی بیشتر رها می‌کنند.
- پیش از شروع: در «تأییدِ فرض‌ها» فرضِ «بیشترِ کاربران آدرسِ ذخیره‌شده دارند» را رد می‌کنی، چون بخشِ بزرگی از خریدها خریدِ اول است.
حکمِ چنین نمونه‌ای می‌تواند بگوید طرفِ ب استدلالِ قوی‌تری داشت، چون داده‌ی پیوست‌شده نشان می‌دهد رهاکردن در میانه‌ی فرمِ طولانی رخ می‌دهد و قدم‌هایِ کوتاه این بار را پخش می‌کنند. در کنارش توافق بر این‌که در هر دو طرح، هزینه‌ی ارسال باید پیش از قدمِ پرداخت دیده شود؛ اختلاف بر سرِ این‌که ساختنِ طرحِ ب با سامانه‌ی فعلی چقدر زمان می‌برد؛ قوی‌ترین مخالفتِ باقی‌مانده از سمتِ برنامه‌نویس این‌که اگر کاربر وسطِ قدمِ دوم صفحه را تازه کند، اطلاعاتِ قدمِ اول نباید از دست برود و این در طرح دیده نشده؛ و توصیه این‌که طرحِ ب را با چند کاربرِ واقعی آزمایش کنی. با «گفتگویِ خصوصیِ دو صندلی» می‌توانی از طراح و برنامه‌نویس بخواهی جداگانه درباره‌ی ذخیره‌ی موقتِ قدم‌ها به توافق برسند و فقط خلاصه‌اش به بحث برگردد. خروجی را هم می‌توانی به PDF یا Word ببری و در جلسه‌ی تیم دست‌به‌دست کنی.
مرزِ کار: مدل‌ها کاربرِ تو نیستند
در تصمیم‌های طراحی محصول با هوش مصنوعی، صندلیِ «کاربر» تصویری است که مدل از یک کاربر ساخته، نه آدمی که واقعاً با محصولت کار می‌کند. ممکن است چیزهایی را بفهمد که کاربرِ واقعی نمی‌فهمد، یا از چیزی بترسد که برایِ کاربرِ واقعی مهم نیست. پس این نشست‌ها را این‌طور ببین:
- پیش از آزمونِ کاربری: گزینه‌هایِ ضعیف را کنار بگذار و سؤال‌هایِ آزمون را دقیق کن.
- بعد از آزمونِ کاربری: مشاهده‌هایت را پیوست کن و بخواه برایِ مشکل‌هایی که دیدی راه‌حل پیشنهاد شود.
- هرگز به‌جایِ آزمونِ کاربری: حتی اگر همه‌ی صندلی‌ها موافق باشند. توافقِ مدل‌ها یعنی استدلالشان هم‌سوست، نه این‌که کاربر همان‌طور رفتار می‌کند.
دسترس‌پذیری، یعنی قابلِ استفاده بودن برایِ کسانی که کم‌بینا هستند یا با صفحه‌خوان کار می‌کنند، هم چیزی است که مدل‌ها می‌توانند درباره‌اش هشدار بدهند، اما سنجشِ نهایی‌اش ابزار و آزمونِ خودش را لازم دارد.
جمع‌بندی
تصمیم‌های طراحی محصول با هوش مصنوعی وقتی کار می‌کنند که سؤال را دقیق بنویسی، طرح را با تصویر و زمینه نشان بدهی و سه نگاهِ طراح، کاربر و برنامه‌نویس را جدا سرِ میز بنشانی تا هم را نقد کنند. حکمِ نشست، گزینه‌ها را غربال می‌کند و ریسک‌هایِ دیده‌نشده را نشان می‌دهد؛ حرفِ آخر را کاربرِ واقعی می‌زند. اگر تصمیمِ طراحی‌ات به یک تصمیمِ فنیِ بزرگ‌تر گره خورده، انتخاب معماری نرم‌افزار با هوش مصنوعی را بخوان، و برایِ دیدنِ بقیه‌ی کاربردهایِ چندهوش در تصمیم‌گیری سری به آن صفحه بزن. اگر هم تازه با این پلتفرم هوش مصنوعیِ چندمدلی آشنا شده‌ای، از صفحه‌ی اصلی شروع کن.