‏پنج اصل برای طراحی اپ‌های voice-first

تو این مقاله، نویسنده از تجربه‌ش با یه استارتاپ که روی رابط‌های voice-first (یعنی اپ‌هایی که اول برای صحبت کردن طراحی شدن، نه تایپ) کار می‌کنه حرف می‌زنه. اون می‌گه خیلی راحت می‌شه با همون کامپوننت‌ها و روال‌های آشنای لمسی شروع کرد و وقتی نوبت به صدا می‌رسه، تقریباً همه‌چیز تصمیم‌گیری شده. اون‌وقت صدا فقط یه راه دیگه برای پر کردن همون فیلدهاست. نویسنده نمی‌گه کیبورد رو حذف کنیم، ولی معتقده باید قانون‌هایی مثل «اول پروژه رو انتخاب کن، بعد تسک بساز» رو زیر سؤال برد.

اصل اول اینه که context حساب بشه. وقتی حرف می‌زنیم، خودبه‌خود توضیح بیشتری می‌دیم. مثلاً به جای «Review proposal» می‌گیم باید قبل از جلسهٔ جمعه پروپوزال رو چک کنم، مخصوصاً قیمت‌گذاری، چون مطمئن نیستم برای تحقیق وقت کافی گذاشتیم. اگه اپ همهٔ اینو به یه تسک خشک و خالی تبدیل کنه، عملاً داره به کاربر یاد می‌ده کوتاه حرف بزنه. نویسنده می‌گه زمان‌بندی و نگرانی کاربر باید روی خود تسک بمونه، با امکان اصلاح.

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

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

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

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

نکات کلیدی:

• طراحی voice-first یعنی زیر سؤال بردن روال‌هایی مثل «اول پروژه، بعد تسک»، نه حذف کیبورد.
• اگه توضیح‌های گفتاری کاربر توی نتیجه نمونه، کاربر یاد می‌گیره کوتاه حرف بزنه.
• ثبت حرف (transcript)، فهمیدنش و انجام کار سه مرحلهٔ جدان و اپ باید وضعیت هرکدوم رو بگه.
• اصلاح باید فقط همون جزئیات اشتباه رو عوض کنه و تسک تکراری نسازه.
• میزان تأیید گرفتن به اثر کار بستگی داره: جابه‌جایی تسک ساده‌ست، فرستادن ایمیل به مشتری نه.
• یه تجربه باید هم جلوی صفحه و هم بدون صفحه (مثلاً با AirPods) کار کنه.