https://virgool.ir/feed/@hosseinkarimi.6872fa2026-11-10 18:33:32https://files.virgool.ir/upload/users/876528/avatar/avatar.pnghttps://virgool.ir/@hosseinkarimi.6872https://virgool.ir/@hosseinkarimi.6872/why-organizations-dont-do-user-research-wkedpdkckw1gاین مقاله رو پس از خوندن مطلبی در وب‌سایت NNGroup نوشتم. ایده و ساختار اصلی از اونجا الهام گرفته شده، اما در بازنویسی، تجربه‌ها و مشاهدات شخصی‌ام رو هم اضافه کردم تا کاربردی‌تر و ملموس‌تر باشه.تصور کنید در حال ساخت یک محصول هستید، بدون اینکه حتی یک بار از کاربر واقعی بپرسید چه می‌خواد. این مثل اینه که بدون نقشه، وارد بیابان بشید! با وجود اینکه تحقیقات کاربر می‌تونه مسیر رو روشن کنه، هنوز هم بسیاری از سازمان‌ها اون رو نادیده می‌گیرن. چرا؟ بیایید با هم بررسیش کنیم.تحقیقات کاربر در دیزاین یک ضرورته.مشکل کجاست؟مشکل اینجاست که بسیاری از تصمیم‌گیران، ارزش واقعی تحقیقات کاربر رو یا نمی‌دونن یا اون رو کم‌اهمیت می‌شمارن. نتیجه چی میشه؟ محصولاتی که شاید از نظر فنی بی‌نقص باشن، اما در دنیای واقعی شکست می‌خورن.بهانه‌های رایج مدیران برای انجام ندادن تحقیقات کاربربرخی سازمان‌ها به جای پذیرش نیاز به تحقیق، بهانه‌هایی پیدا می‌کنن. این بهانه‌ها شاید منطقی به نظر برسن، اما در عمل، مانع پیشرفت میشن.«وقت نداریم!»تیم‌ها تحت فشار هستن تا سریع لانچ کنند و به KPIها برسن. اما نتیجه این میشه که بعدا وقت بیشتری صرف درست کردن اشتباهات می‌کنن.«تحقیق هزینه بردار!»خیلی از مدیران هزینه تحقیق رو سنگین می‌بینن. اما واقعیت اینه که هزینه اشتباه گرفتن تصمیمات، چندین برابر بیشتره. مخصوصاً وقتی محصول شکست بخوره.«کاربرها نمی‌دونن چی می‌خوان!»این هم یکی از سوءبرداشت‌های بزرگه. درست شاید کاربرها راه‌حل فنی ندونن، اما مشکلات و نیازهاشون رو خیلی خوب می‌دونن. وظیفه تیم ماست که اون‌ها رو به راه‌حل مناسب ترجمه کنه.«ترس از بازخورد منفی در محصول!»ترس از بازخورد منفی باعث می‌شه خیلی از تیم‌ها تحقیق رو عقب بندازن. اما واقعیت اینه که شنیدن بازخورد منفی اول مسیر بهتر از شکست کامل محصول در آینده‌ست.مشکل واقعی در فرهنگ و ساختار سازمانیواقعیت اینه که دلیل اصلی انجام نشدن تحقیقات کاربر، فقط وقت یا هزینه نیست. خیلی وقت‌ها سیستم پاداش‌دهی در شرکت‌ها طوریه که تیم‌ها رو تشویق می‌کنه سریع یه فیچر جدید تحویل بدن، نه اینکه وقت بذارن و محصول درست رو بسازن. برای همین تحقیق به چشم یه هزینه اضافی یا سد راه دیده می‌شه.تجربه شخصیمن بارها دیدم که پروژه‌هایی بدون تحقیقات کاربر شروع شدن و در نهایت، با هزینه و زمان زیاد، دوباره‌کاری شدن. هر بار که صدای کاربر نادیده گرفته شد، نتیجه چیزی جز اتلاف منابع نبود.جمع‌بندیتحقیقات کاربر یک «گزینه لوکس» نیست، بلکه یک ضرورته. هر سازمانی که می‌خواهد محصولی موفق بسازد، باید این واقعیت رو بپذیرد: بدون شناخت کاربر، موفقیت شانسی است.Hossein KarimiHossein KarimiSat, 13 Sep 2025 02:27:32 +0330https://virgool.ir/@hosseinkarimi.6872/فرمول-طلایی-نوشتن-برای-دکمه-ها-و-قابلیت-ها-راهنمای-ux-writing-nnch2omjlbmuبارها در محصولات مختلف دیده ام که چگونه جزئیات کوچک می توانند بزرگترین تأثیر را بر تجربه کاربری بگذارند. یکی از این جزئیات که اغلب محل بحث و تردید است، «میکروکپی» است.فرمول طلایی نوشتن برای دکمه ها و قابلیت هااخیراً در یک پروژه، دوباره با این چالش روبرو شدیم: برای یک دکمه ی اشتراک گذاری، Share Link درست است یا Link Sharing؟این سوال، با اینکه ساده به نظر میرسد، فرصت خوبی است تا به اصول بنیادین «UX Writing» برگردیم و منطق پشت نامگذاری دکمه های اقدام (Buttons) و نام قابلیت ها (Features) را مرور کنیم. در این مطلب، میخواهم این اصول را به شکلی ساده و کاربردی با شما به اشتراک بگذارم.قانون اول: متن دکمه ها باید یک «دستور عمل» باشددکمه ها برای «انجام دادن» یک کار طراحی شده اند. بنابراین، متن روی آنها باید یک دستور واضح، مستقیم و عملگرا باشد.فرمول طلایی دکمه: فعل امری + اسماین ساختار به کاربر می گوید چه کاری انجام دهد و آن کار روی چه چیزی انجام می شود.مثال: Share Link (لینک را به اشتراک بگذار)این عبارت یک فعل (Share) دارد که کاربر را به انجام یک کار دعوت می کند. این بهترین ساختار برای دکمه ها، لینک ها و گزینه های منو است.نکات کلیدی برای نوشتن متن دکمه:با فعل شروع کنید: مانند ذخیره تغییرات، افزودن به سبد خرید، ایجاد حساب.شفاف باشید: کاربر باید دقیقاً بداند با کلیک کردن چه اتفاقی می افتد. از کلمات مبهمی مثل «تایید» یا «ارسال» (بدون توضیح) بپرهیزید.مختصر بنویسید: معمولاً ۱ تا ۳ کلمه کافی است.قانون دوم: نام قابلیت ها باید یک «مفهوم» را توصیف کندوقتی می خواهیم یک قابلیت، یک بخش از تنظیمات یا یک صفحه را نامگذاری کنیم، هدف ما توصیف یک «مفهوم» یا یک «فرآیند» است، نه دستور دادن.فرمول طلایی: اسم + اسم مصدر (Gerund)این ساختار نام یک ویژگی را به شکل یک اسم ترکیبی توصیف می کند.مثال: Link Sharing (قابلیت اشتراک گذاری لینک)این عبارت نام یک ویژگی است. Sharing در اینجا اسم مصدر (فعل + ing) است و یک فرآیند کلی را توصیف می کند. این ساختار برای عناوین، تیترها و برچسبهای تنظیمات عالی است.نکات کلیدی برای نامگذاری قابلیت ها:توصیفی باشید: نام باید ماهیت آن قابلیت را شرح دهد، مانند File Management یا Notification Settings.از زبان کاربر استفاده کنید: از اصطلاحات فنی و پیچیده که کاربر با آنها آشنا نیست، خودداری کنید.ثبات داشته باشید: در تمام بخش های محصول از یک نام ثابت برای یک قابلیت استفاده کنید.چرا این تفاوت مهم است؟ذهن ما دستورالعمل ها (Share Link) را سریعتر از مفاهیم انتزاعی (Link Sharing) برای انجام یک کار پردازش می کند. وقتی برای هر عنصر از ساختار نوشتاری درست استفاده کنیم:بار شناختی کاربر را کاهش میدهیم: او بدون فکر کردن و زحمت، اپلیکیشن را میفهمد.اعتماد ایجاد میکنیم: محصول شما حرفهای، قابل پیشبینی و قابل اعتماد به نظر میرسد.در نهایت، همین جزئیات کوچک در انتخاب کلمات هستند که یک تجربه کاربری معمولی را به یک تجربه عالی تبدیل می کنند.شما چه چالش های مشابهی در نامگذاری داشته اید؟Hossein KarimiHossein KarimiMon, 01 Sep 2025 02:47:25 +0330