<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های ساسان سروشه</title>
        <link>https://virgool.io/feed/@sasansorousheh</link>
        <description>من ساسان هستم، یک طراح محصول ​​با سابقه بیش از 5 سال فعالیت.
اینجا سعی میکنم یک سری چالش‌ها و موضوعات مهم در زمینه طراحی محصول رو با تجربه خودم بنویسم.

isasan.ir</description>
        <language>fa</language>
        <pubDate>2026-04-14 08:52:16</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/560104/avatar/avatar.png?height=120&amp;width=120</url>
            <title>ساسان سروشه</title>
            <link>https://virgool.io/@sasansorousheh</link>
        </image>

                    <item>
                <title>چرا ورژنینگ و گزارش‌نویسی در فرآیند طراحی محصول مهم است؟</title>
                <link>https://virgool.io/@sasansorousheh/version-report-alts79o7uydx</link>
                <description>یک فرق بزرگ بین طراح معمولی و طراح حرفه‌ای وجود داره که کمتر کسی بهش توجه می‌کنه. نه سبک طراحیه ، نه تسلط به ابزار. اینکه چطور طراحیت رو مدیریت و مستند کنی، خیلی خیلی زیاد توی روند طراحی محصول اهمیت داره.اهمیت ورژنینگ و گزارش‌نویسیوقتی درباره طراحی محصول صحبت می‌کنیم، چه سایت، چه اپلیکیشن و چه سیستم‌های داشبوردی، یکی از چیزهایی که بعضی از طراح‌ها کمتر جدی می‌گیرن، ورژنینگ و گزارش‌نویسی دقیق هست. در حالی که همین دو تا موضوع می‌تونن باعث بشن پروژه‌ت با کیفیت‌تر جلو بره، اختلافات تیمی کمتر بشه و تصمیم‌ها کاملاً قابل پیگیری باشن.ورژنینگ و گزارش‌نویسی در طراحی محصولاصلا ورژنینگ یعنی چی؟ورژنینگ یعنی تغییرات هر نسخه از محصول رو با یک شماره، تاریخ و توضیح واضح ثبت کنیم. مثلا واسه طراحی یه داشبورد میتونیم اینجوری عمل کنیم:V1.0: طراحی اولیه داشبوردV1.1: اصلاح استایل، اضافه شدن بخش فیلترV1.2: رفع باگ‌های UI، تغییر اینپوت‌های تیکتورژنینگ محصولاین سیستم ورژنینگ باعث می‌شه دیگه کسی نپرسه کدوم فایل یا طرح، آخریه؟ برنامه‌نویس دو ساعت توی صفحه اشتباهی دنبال چیزی نگرده، QA بر اساس ورژن اشتباهی از محصول باگ نگیره، خودت هم گیج نشی و بدونی الان کجا هستی.حالا گزارش نویسی چیه؟به زبان ساده یعنی تو دلیل تصمیم‌هایی که تو محصول گرفتی رو توضیح بدی که نتیجه‌اش چی شد؟حالا ممکنه بعضی‌ها با خودشون بگن بابا این دیگه چه کاریه؟ معلومه چرا اینو گذاشتم، یا مشخصه چه تغییری دادم. ولی وقتی بری تو کار تیمی می‌بینی نه، 2 هفته بعد یادت نمیاد چرا فلان دکمه رو حذف کردی. مدیر محصول نمی‌پرسه چرا رنگ کارت تغییر کرد؟ برنامه‌نویس نمی‌پرسه چرا اینجا دوتا فلوی مختلف گذاشتی؟اگر هم پرسیدن به راحتی میتونی گزارش رو بهشون نشون بدی و مجبور نیستی دیگه همه چی رو حفظ کنی.چرا ورژنینگ و گزارش‌نویسی در فرآیند طراحی محصول ضروری هستند؟1) از سردرگمی تیم جلوگیری میکنناگر ورژنینگ نباشه، همه اعضای تیم نمی‌دونن الان باید روی کدوم فایل کار کنن. این مشکل توی تیم‌های بزرگ‌تر خیلی شایع‌تره.2) تصمیم‌هاتون قابل دفاع و پیگیری می‌شنوقتی مدیر محصول بپرسه: چرا اینجا این رنگه؟ چرا این دکمه حذف شد؟ و … ، تو یک سند واضح داری که دلیل علمی و منطقی تصمیم‌های شما رو ثبت کرده.3) انتقال پروژه سریع‌تر می‌شهفرض کن یه روز مرخصی هستی یا اصلا روزی از اون تیم جدا شدی و رفتی، خب هر کسی که بیاد بعد از تو کار رو ادامه بده، با دیدن گزارش‌ها کاملاً می‌فهمه پروژه چطور رشد کرده و چه اتفاقاتی براش افتاده. از دوباره‌کاری هم جلوگیری میشه.5) کیفیت محصول بالاتر میرهمحصولی که تصمیماتش ثبت شده باشن، به طور کلی پخته‌تر و منسجم‌تر درمیاد. این موضوع بازم توی تیم‌ها و پروژه‌های بزرگتر، بیشتر خودش رو نشون میده.در نهایت یادت باشه، ورژنینگ و گزارش‌نویسی نه کار اضافه‌ست، نه صرفاً کار اداریه. این دو تا ابزار باعث می‌شن کار حرفه‌ای انجام بدی، محصول باکیفیت‌تری بسازی و تیمت حرفه‌ای‌تر جلو بره. طراح خوب، کسی نیست که فقط خوب طراحی کنه، کسیه که خوب مدیریت و مستندسازی هم بکنه.امیدوارم این پست هم به کارتون بیاد و بهتون کمک کنه. اگر دوست داشتین میتونین واسه حمایت، من رو دنبال کنین، این پست رو لایک کنین و واسه هرکسی که فکر میکنین نیاز داره بفرستین. اگر هم نظری دارین که فکر میکنین میتونه به من کمک کنه تا محتوای بهتری واستون بسازم حتما کامنت کنین.فعلا، روز خوش!</description>
                <category>ساسان سروشه</category>
                <author>ساسان سروشه</author>
                <pubDate>Sun, 25 Jan 2026 10:50:11 +0330</pubDate>
            </item>
                    <item>
                <title>اهمیت یکپارچگی در طراحی محصول</title>
                <link>https://virgool.io/@sasansorousheh/consistency-dr1hsd6aymik</link>
                <description>دیدی وقتی با آیفون کار می‌کنی، بعد روی مک‌بوک یا آیپد سوئیچ می‌کنی، بازم همه‌چیز آشناست؟ دکمه‌ها شبیه هم، رفتار المان‌ها و صفحات مثل هم، موشن‌ها یکسان و ساختارها قابل پیش‌بینی هستن.این حسِ روان و بدون فکری که من و توی کاربر داریم، نتیجه‌ی سال‌ها زحمت و سرمایه‌گذاری اپل روی موضوع یکپارچگی یا همون Consistency هست.یکپارچگی یا Consistency چیه؟اگه بخوام ساده بگم، Consistency یعنی وقتی کاربر وارد محصولت میشه، نبینه هر بخش داره ساز خودش رو میزنه! در واقع همه‌چیز یه منطق مشترک داشته باشه. از فونت گرفته تا مثلا دکمه ها یا از layout صفحه گرفته تا موشن‌ها. این چیزیه که وجودش واقعا می‌تونه محصولت رو نجات بده و نبودش محصولت رو حتی نابود کنه.اهمیت یکپارچگی در طراحی محصول موفقاگه توی محصول، Consistency رعایت نشه چه اتفاقی میوفته؟اول از همه کاربر مبتدی ممکنه گیج بشه، بار ذهنی کاربر میره بالا. مثلا یه محصول کلاسیک طراحی کردی که ux writing رسمی داره. اما اومدی توی toast message ها، صفحات ارور، یا پیام‌های سیستم از تصاویر و الفاظ خودمونی‌تر و فانتزی استفاده کردی. یا به جای اینکه مثلا روی تکمیل فرم تمرکز کنه یا خریدش رو انجام بده، داره به این فکر میکنه که چرا توی این صفحه از یه UI فانتزی استفاده شده ولی صفحه قبلی UI رسمی داشت. خب اینا با هم نمیخونه و کاربر حس میکنه به فضای دیگه‌ای پرتاب شده و برای اون محصول نیست. میگه نکنه توی محصول اشتباهی رفتم و فرم اشتباهی رو دارم پر میکنم.دوم اینکه ممکنه کاربر به اشتباه بیوفته. فرض کن یه سایت فیلم و سریال داری. اومدی واسه صفحه بندی فصل ها یا قسمت های یه سریال pagination رو از راست به چپ چیدی و به کاربر القا کردی قبلی سمت راست هست و بعدی سمت چپ. اما توی صفحه سینگل هر قسمت اومدی برعکس عمل کردی. خب کاربرها عمدتا بعد یکی دوتا اکشن، اون رو دیفالت محصول میبینن و زود عادت میکنن، اما با این تغییر تو به خیال خودشون دارن میرن قسمت بعدی در صورتی که روی قسمت قبلی کلیک میکنن.و سوم اینکه هزینه و دوباره کاری بالا میره. یعنی هرکی توی تیم میاد یه چیزی طراحی میکنه، بعد جلوتر میریم میبینیم با هم نمیخونه، خب مجبوریم یه ریفکتور انجام بدیم. یعنی زمان دوباره، انرژی دوباره. حالا فکر کن محصول هی بزرگتر بشه و تعداد نیروها بیشتر.یه مثال ساده از همون اپل بزنم. مثلا توی محصولات اپل می‌دونی همه جا، چه Apple Music، چه Settings، چه Messages و هر اپ دیگه‌ای، دکمه Back همیشه سمت چپ بالاست، همون شکل فلش ساده و همون رفتار. همیشه موشن برگشت یکیه، از سمت چپ وارد میشه و همون مکان رو حفظ میکنه. خب نتیجش میشه این که تو هیچ‌وقت دنبال دکمه &quot;back&quot; نمی‌گردی. همیشه می‌دونی کجاست.چجوری از به هم ریختگی و اصطلاحا Inconsistency جلوگیری کنیم؟اول اینکه یه دیزاین سیستم داشته باش. اگه پروژت کوچیکه و نمیخوای دنبال دیزاین سیستم بگردی، حداقل از یه UI Kit ساده استفاده کن. اینجوری رنگ، تایپوگرافی، کامپوننت‌های اصلی، فواصل و این المان‌های اولیه رو واسه یه ساختار منظم داری.دوم اینکه هر تصمیمی توی تیم به خصوص تیم دیزاین گرفته میشه رو داکیومنت کن تا بقیه تیم هم از چارچوب موجود، مطلع بشن. اگر هم تغییری داده میشه و تصمیم جدیدی گرفته میشه حتما ورژن بزن.سوم هم اینکه Design QA انجام بده. قبل انتشار و تحویل فایل به مدیر محصول یا تیم دولوپ یه دور کامل دیزاین رو طبق اصولی که چیدید، چک کن تا همه چی دقیق باشه.چجوری داخل تیم، فرهنگ Consistency رو جا بندازیم؟مهم ترین و اساسی ترین کار لازم اینه که یه نفر توی تیم مثلا مسئول دیزاین سیستم و QA خروجی ها باشه تا همه چی از فیلتر اون رد بشه چون تمرکز بیشتری روی این موضوع گذاشته و مسلط تره. واسه هماهنگی بیشتر و بهتر، لازمه هر از گاهی حتی یه جلسه کوتاه 10 دقیقه‌ای بین اعضای مربوطه انجام بشه تا اگر کسی مثلا کامپوننت جدیدی هم ساخته اطلاع بده و بررسی بشه.یکی از ضروری ترین اقدامات هم اینه که تیم دیزاین با سایر تیم ها در مورد نامگذاری توکن ها به توافق برسن و همه از یه کد استفاده کنن. مثلا ما میایم اسم دکمه های اصلی رو PrimaryButton میذاریم، تیم دولوپ رفته توی storybook اسمش رو گذاشته BrandBtn. خب اینجوری خودمون هم گیج میشیم و بعضی موقع ها نمیفهمیم کی چی میگه، حتی گزارش تغییر توی توکن و رفتارشون هم سخت و پیچیده میشه. در نهایت هم میتونیم مثل همیشه به تست کاربری اعتماد کنیم و بعد از بررسی رفتار کاربرامون اگر inconsistency وجود داشت متوجه بشیم، چون کاربر عادی اولین کسیه که این موضوع رو میفهمه.دیدی چقدر consistency میتونه توی طراحی محصولت نقش مهمی داشته باشه؟ پس نگران نباش اگه یه سریا میان واسه این که کارشون رو توجیه کنن میگن اینجوری خلاقیت از بین میره! دروغ محضه!اپل یه جمله معروف داره که میگه، کاربر نباید هر دفعه مجبور بشه از اول یاد بگیره چطور باید با محصولت کار کنه.امیدوارم این پست هم به کارتون بیاد و بهتون کمک کنه. اگر دوست داشتین میتونین واسه حمایت، من رو دنبال کنین، این پست رو لایک کنین و واسه هرکسی که فکر میکنین نیاز داره بفرستین. اگر هم نظری دارین که فکر میکنین میتونه به من کمک کنه تا محتوای بهتری واستون بسازم حتما کامنت کنین.فعلا، روز خوش!</description>
                <category>ساسان سروشه</category>
                <author>ساسان سروشه</author>
                <pubDate>Tue, 20 Jan 2026 11:31:28 +0330</pubDate>
            </item>
                    <item>
                <title>بایاس یا سوگیری ذهنی در طراحی محصول</title>
                <link>https://virgool.io/@sasansorousheh/%D8%A8%D8%A7%DB%8C%D8%A7%D8%B3-%DB%8C%D8%A7-%D8%B3%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%B0%D9%87%D9%86%DB%8C-%D8%AF%D8%B1-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D9%85%D8%AD%D8%B5%D9%88%D9%84-g6bvdlkla5mx</link>
                <description>تا حالا به این فکر کردی با اینکه همه مراحل طراحی یه محصول رو پیش بردی، چرا بازم اونجور که باید کار نمیکنه؟ دقیقا مشکل کجاس؟ کار، کار بایاسه. همون خطای ذهنی که یواشکی توی مسیر طراحی با ما پیش میاد و اگه زود پیداش نکنیم مثل یه ویروس توی کل محصول پخش میشه و وقتی میفهمیم که اکثرا دیگه کاری از دست ما برنمیاد.بایاس چیه و چه تاثیری توی مسیر طراحی محصول داره؟به طور کلی بایاس همون چیزیه که باعث می‌شه تصمیم‌هامون دقیق نباشه، داده‌ها رو بد تفسیر کنیم و محصولی بسازیم که کاربر واقعاً نمی‌خواد چون فکر میکردیم کاربر توی اون قسمت مثل ما رفتار میکنه، یا اولین ایده ای که به ذهنمون رسیده به نظرمون بهترین بوده و دیگه فکری نکردیم یا اصلا ممکنه فقط نظرهایی رو اعمال کرده باشیم که با فکر ما سازگار بوده.بایاس یا سوگیری ذهنی در طراحی محصولانواع بایاس در طراحی محصول کدوم‌ها هستن؟بزار با 6 تا مثال ساده که همیشه هم باهاش برخورد داشتی، انواع بایاس رو بهت معرفی کنم:اگه دقت کرده باشی، توی مصاحبه با کاربران یا آنالیز پرسشنامه، ناخوداگاه فقط دنبال اطلاعات و نتایجی هستیم که با ما موافقن و نظرمون رو تایید میکنن. چون همه ما دوست داریم تایید بشیم و حرفمون بشینه. اینجوری خوشحال تریم و احساس موفقیت داریم. شایدم حوصله بحث درباره یه حرف مخالف رو نداریم. شایدم از نتایج جدید میترسیم.یه جا دیگه هست میایم چندتا اتود وایرفریم می‌سازیم و به کارفرما نشون میدیم تا فیدبک بگیریم، همون اولی که میبینه رو تایید میکنه و دیگه بقیه اتودها به چشمش نمیاد. به راحتی هم راضی به تغییر و اصلاح احتمالی نمیشه، چون اولین چیزی که دیده اصطلاحا توی ذهنش لنگر کرده.یکی از متداول ترین نمونه ها که واسه ما بیشتر اتفاق میوفته اینه که فکر می‌کنیم همه کاربران مثل خودمون فکر می‌کنن. مثلا من عادت دارم وقتی با گوشی کار میکنم، دستم رو روی یه گزینه نگه دارم و اکشن های اضافی اون مثل ویرایش یا حذف کردن رو ببینم. پس میام روی محصول مدیریت تسکی که ساختم، فقط این قابلیت رو روی کارت تسک ها میزارم و راه دیگه ای برای ویرایش و حذف نمیبینم چون از نظر من بقیه هم طبیعتا این رفتار رو میدونن دیگه. همکارام و دوستام رو دیدم که بلدن. اما آیا بقیه کاربرها به خصوص کاربران مبتدی هم این رفتار رو میشناسن؟یه موقع هایی هم هست که می‌ترسیم چیزی رو تغییر بدیم. مثلا کارفرما میگه از اول ما منوی کاربر رو این شکلی چیدیم و داره کار میکنه، پس نمیخواد عوض کنیم. وضعیت فعلی رو داره ترجیح میده. در صورتی که ممکنه اون متود قدیمی شده باشه، اشتباه باشه، با طراحی جدید نخونه یا دیگه کاربرپسند نباشه و صرفا کاربرای قدیمیش عادت کردن باهاش کار کنن نه اینکه راحت باشن.یه جاهایی هم چون زمان زیادی گذاشتیم، نمی‌خوایم تغییرش بدیم حتی اگه به ضررمون باشه. مثلا شما میبینی که سبک گرافیکی که روی سایت کار شده خیلی فانتزیه اما محصول داشبوردی و خیلی رسمیه. میگی باید بنرها و آیکون و بقیه چیزا عوض بشه، اصلا همخوانی با بقیه صفحات نداره و کاربر پسند نیست. اما کارفرما این اجازه رو نمیده و میگه ما مثلا 2،3 ماه روی این بنرها کار کردیم و هزینه دادیم براش و حیفه حالا بزار همین بمونه.آخریش هم بازم چیزیه که قطعا توی مسیر طراحی حداقل یک بار باهاش برخورد داشتی به خصوص اگر کمال گرا باشی. توجه بیش از حد روی یه موضوع جزئی که تمرکز روی تجربه اصلی کاربر رو به هم میزنه. مثلا رفتیم بخش نظرات کاربران توی محصولات فروشگاه رو ایجاد کنیم. یهو کاملا درگیر این میشیم که واسه ریتینگ ستاره بزاریم یا لایک و دیسلایک یا توی فرم چه فیلدهایی باشه یا … . اما اصلا دقت نکردیم برای این فروشگاهی که تازه راه اندازی شده، در ماه شاید 50 الی 100 تا کاربر داشته باشه. مگه از این تعداد چند نفر تمایل به نظردهی دارن و چند درصدشون ممکنه توی این مسیر نظردهی اون فیچر ریتینگ واسشون چالش اصلی باشه!!برای جلوگیری از ایجاد بایاس در طراحی محصول چیکار کنیم؟خب میبینیم که بایاس می‌تونه باعث تصمیم‌گیری اشتباه بشه، فیچرهای اشتباه یا غیرضروری طراحی کنیم، نیازهای واقعی کاربران رو نادیده بگیریم، تیم گمراه بشه و هزینه توسعه بره بالا و در نهایت محصول توی بازار شکست بخوره.پس برای جلوگیری از احاطه بایاس روی تفکر طراحیمون، بهتره موارد زیر رو رعایت کنیم:فرضیات رو ثبت کنیم و از خودمون بپرسیم این فرضیه و نتیجه از کجا اومده و چرا؟ حتما مصاحبه با کاربران واقعی داشته باشیم، تست کاربری از محصول بگیریم، به پرسونای محصولمون به شدت توجه کنیم و تا جای ممکن از همه کاربرا توی پرسونامون بهره ببریم. بعد از اتود اولیه، از سایر طراحان، توسعه دهنده ها و بقیه اعضای تیم یک فیدبک بگیریم. از یه طراح خارج از اون محصول هم میتونیم کمک بگیریم چون خطاها رو سریع تر شناسایی میکنه.توی تصمیم گیری عجله نکنیم و تحقیقات کاربری رو فدای زمان نکنیم. اگر طراح محصولی، بدون شک با بایاس سر و کار داری و این مواردی که گفتم رو تجربه کردی. نکته مهم اینه که سعی کنیم همیشه آگاه باشیم و مدیریت‌شون کنیم تا محصولی واقعی، دقیق و کاربرمحور بسازیم.امیدوارم این پست به کارتون بیاد و بهتون کمک کنه. اگر دوست داشتین میتونین واسه حمایت، من رو دنبال کنین، این پست رو لایک کنین و واسه هرکسی که فکر میکنین درگیر بایاس فکری شده بفرستین. اگر هم نظری دارین که فکر میکنین میتونه به من کمک کنه تا محتوای بهتری واستون بسازم حتما کامنت کنین.فعلا، روز خوش!</description>
                <category>ساسان سروشه</category>
                <author>ساسان سروشه</author>
                <pubDate>Mon, 19 Jan 2026 13:48:17 +0330</pubDate>
            </item>
            </channel>
</rss>