کشف صدای محصول در کلاودفلر تیمز: تجربه‌ای از یک یوایکس رایتر

من Alice Bracchi نویسنده فنی و تجربه‌نویسِ  Cloudflare for Teams, Cloudflare’s Zero Trust وSecure Web Gateway solution هستم. می‌خواهم دربارۀ چیستی صدای محصول صحبت کنم، اینکه چرا اهمیت دارد و چگونه توانستم صدای محصول را برای Cloudflare for Teams پیدا کنم.

مشتریان ما در Cloudflare for Teams Dashboard (یا همانطور که بطور غیررسمی ‌آن را Teams Dash می‌نامیم)، کنترل کاملی بر امنیت شبکۀ خود دارند. مدیران می‌توانند VPN خود را با راه‌حلی جایگزین کنند که بر اساس قوانین Zero Trust اجرا می‌شود و شبکۀ Cloudflare را به یک شبکۀ یکپارچه و امن تبدیل می‌کند. مشتریان می‌توانند با پیکربندی قوانین دیوار آتشین L7 و سیاست‌های فیلتر DNS، تمام ترافیک را ایمن کنند و سازمان‌ها این توانایی را دارند که وب‌گردی را در سایت‌های مشکوک مجزا کنند.

چندین عملکرد مختلف در یک مکان

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

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

اما دقیقاً صدای محصول چیست؟

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

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

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

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

صدای محصول مجموعه‌ای از اصول و دستورالعمل‌هایی است که نحوۀ شناخت ما را برای کاربران‌ استاندارد می‌کند. این صدا تعیین می‌کند که آیا در احوال‌پرسی‌هایمان علامت تعجب قرار می‌دهیم (خوش آمدید!)؟ آیا در پیام‌های خطا اصوات را اضافه می‌کنیم (اوه اوه!)؟ آیا کاربر را «شما» خطاب می‌کنیم یا رویکرد غیرشخصی‌تری را ترجیح می‌دهیم؟ این‌ها ویژگی و سَبک ما را نشان می‌دهند که کاربران می‌توانند از ما انتظار داشته باشند.

و Team Dashboard به چنین روندی نیاز داشت تا صدای محصول خود را پیدا کند.

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

 به این نتیجه رسیدم که اگر طراحی صدای محصول فقط بر اساس ذهنیّات تجربه‌نویس باشد به موفقیت نمی‌رسد. صدا باید برای همۀ ذینفعان (مدیران، طراحان و مهندسان محصول) که هر روز محصول را می‌سازند ملموس و حقیقی باشد. در نهایت، صدای محصول در صورتی تجلّی می‌کند که با اصول محصول همسو باشد. و ما به عنوان یک تیم، آنقدر درگیر ویژگی‌های حمل‌و‌نقل و حل مشکلات شده بودیم که برای اصول خود کاری نکرده بودیم.

بنابراین مسیر برای من روشن بود:

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

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

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

روند جلسه اینطور بود:

• تمام کلماتی را که با Teams مرتبط می‌دانید فهرست کنید.

 ما این سؤال را «بیان افکار بدون قضاوت و نقد» نامیدیم. به آن‌ها دو ۲٫۵ دقیقه فرصت دادم تا ناخودآگاه و خلاق عمل کنند و تمام کلماتی را که به ذهنشان می‌رسد به من بدهند.

• تیم‌ها به کاربران به‌وسیلۀ ____  کمک می‌کنند.

با این سؤال می‌خواستم آن‌ها روی روزمره تمرکز کنند: برای مشتریان خود چه کار می‌کنیم؟ برای حل کدام مشکلات تلاش می‌کنیم؟

• از نظر تجربه، من دوست دارم کاربران Teams را با ____ (برند) مرتبط کنند.

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

• Teams منحصر به فرد است زیرا ________ است.

از آن‌ها خواستم روی ویژگی‌هایی تمرکز کنند که ما را در بازار متمایز می‌کند. چه چیزی محصول را متمایز می‌کند؟

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

واژه‌هایی برای کشف صدای محصول: کلمات در پس اصول محصول ما

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

اطمینان‌بخش

این اولین اصلی بود که روی آن کار کردم. ما یک محصول امنیت شبکه هستیم، بنابراین وظیفۀ ما محافظت است. تحت این اصل من تمام کلمات مربوط به مفاهیم امنیت، حفاظت و اطمینان را جمع‌آوری کردم. آن‌ها حتی برای بیان این مفهوم از استعاره استفاده کرده بودند: ما یک محافظ هستیم. یک کامیون زرهی.

شفافیت

یکی دیگر از موضوعات محبوب، ویژگی‌های تجزیه‌وتحلیلِ گسترده و میدانِ دیدی بود که آن‌ها به کاربرانِ سطح مدیریت می‌دهند. این اصلْ کلماتی را دسته‌بندی می‌کند که ریشۀ آن‌ها به هر طریقی با حس بینایی مرتبط است: مشاهده، نظارت، دید و مواظبت. به‌اندازۀ کافی جالب توجه است که کلماتِ دیگر بیشتر معطوف به معناشناسیِ بررسی بودند: تحقیق‌کردن، یافتن، کشف‌کردن. در نهایت برای توصیف‌کنندۀ اصلی به واژۀ شفافیت اکتفا کردم، زیرا محصول ما یک قابِ شیشه‌ای است (استعارۀ دیگری که استفاد شد) که مدیرِ حساب می‌تواند آن را ببیند و فوراً دریابد که آیا چیزی نیاز به بررسی دارد یا خیر.

استفادۀ آسان

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

پیشگام

در کنارِ راهنما‌بودن، یک موضوعِ واضح دربارۀ Teams وجود داشت که مدرن‌بودن در بازار بود. مدرن‌بودن در اکثر جلسات همفکری تکرار می‌شد. توصیف‌کننده‌های نزدیک (اما قوی‌تر) پیشگام و پیشرو بودند، که با توجه به آن عنوان این اصل را انتخاب کردم، زیرا این واژه‌ها انرژی محصولی را منتقل می‌کند که فعال و تازه است.

بدون اصطکاک

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

قابل تطبیق

این اصل دو وجه دارد. اولین وجه در انعطاف‌پذیری و توانایی Teams برای انطباق با شرایط بروز پیدا می‌کند. (مفاهیمی مانند سازگار، آماده برای تغییر، و ساخته شده در سال 2020 را در نظر بگیرید). وجه دوم بیشتر دربارۀ توانایی ما برای انطباق با نیازهای کاربر است. اینجاست که ماهیت کاربرمحور ما آشکار می‌شود: ما اجازه می‌دهیم نیازهای کاربر به روند تکامل ما به‌عنوان محصول سر و شکل ببخشد.

صدای محصول ما چطور؟

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

1. واضح و روشن. ما ارزش زبان مؤثر و مختصر را می‌دانیم. ما حجم مناسبی از اطلاعات را در زمان مناسب ارائه می‌دهیم.
2. مفید. ما نکات و راهنمایی‌هایی را ارائه می‌دهیم و به کاربران اطمینان می‌دهیم که هرگز به حال خود رها نشوند تا خودشان مسائل را دریابند.
3. صمیمانه. ما خوشحالیم که کاربران همراه ما هستند. با آن‌ها همدلی می‌کنیم و افرادی گرم و پذیرا هستیم.
4. جدید و نو. ما یک محصول جدید، غیررسمی ‌و جذاب هستیم. کاربر را طوری خطاب می‌کنیم که انگار کنار ما نشسته است و مانند یک دوست ساعی هستیم که به شما پیشنهاد تعمیر کامپیوترتان را می‌دهد.
5. کنترل شده. ما همه چیز را تحت کنترل داریم. بدون ترس و بدون هیجان. ما بیش از حد واکنش نشان نمی‌دهیم.

در گام بعدی، یک ماتریس صوتی ساختم که کمی ‌با رویکرد Torrey Podmajersky در Strategic Writing for UX مطابقت دارد. یک ستون به هر ویژگی صدا اختصاص دادم و تعریف کردم که آن‌ها از نظر محتوا، واژگان، نحو، دستور زبان، علائم نگارشی و گزینه‌های حروف بزرگ چه چیزی را شامل می‌شوند. این ماتریس صوتی، بایدها و نبایدهای شیوه‌نامه تجربه‌نویسی را برای Teams Dashboard خلاصه می‌کند.

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

چیزی که یاد گرفتم

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

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

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

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

گام بعدی چیست؟

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