تفکر محصول | امیرحسین کاشفی

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی فرم‌های چندستونه معمولاً سرعت اسکن را پایین می‌آورند؛ چون چشم کاربر مجبور می‌شود بین ستون‌ها رفت‌وبرگشت کند و ترتیب پرکردن فیلدها مبهم می‌شود. نتیجه‌اش مکث، خطا و حس “فرم شلوغ” است—به‌خصوص وقتی کاربر عجله دارد یا تمرکز پایین است. در نسخه‌ی بالایی، فیلدها دو ستونه چیده شده‌اند (Email کنار Password و …) و کاربر باید تصمیم بگیرد مسیرش چطور باشد: از چپ به راست؟ ستون اول کامل، بعد ستون دوم؟ این ابهام، اصطکاک ایجاد می‌کند. در نسخه‌ی پایینی، همه چیز تک‌ستونه است؛ مسیر چشم از بالا به پایین طبیعی می‌شود، خوانایی و تکمیل فرم سریع‌تر می‌شود و دکمه اصلی هم واضح‌تر دیده می‌شود. قاعده ساده است: تا جای ممکن فرم را تک‌ستونه طراحی کن؛ چندستونه را فقط وقتی استفاده کن که واقعاً فیلدها کوتاه و کاملاً هم‌خانواده‌اند و ارزشش از هزینه‌ی کاهش خوانایی بیشتر است. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی فاصله‌گذاری (spacing) در فرم‌ها باید «ارتباط‌ها را واضح کند»: لیبل باید واضحاً به فیلد خودش بچسبد، نه اینکه از فیلد قبلی هم به همان اندازه فاصله داشته باشد. وقتی فاصله‌ی لیبل با فیلد قبلی و فیلد خودش یکسان باشد، چشم کاربر لحظه‌ای شک می‌کند این متن مربوط به کدام ورودی است و اسکن فرم کندتر می‌شود. در نسخه‌ی بالایی، لیبل‌ها تقریباً وسطِ فاصله‌ی بین دو فیلد نشسته‌اند؛ یعنی از پایینِ فیلد قبلی و بالای فیلد خودشان فاصله‌ی مشابه دارند و مرزبندی گروه‌ها مبهم می‌شود. در نسخه‌ی پایینی، فاصله‌ی «لیبل تا فیلد خودش» کمتر و فاصله‌ی «بین دو گروه فیلد» بیشتر شده؛ در نتیجه هر لیبل به‌صورت طبیعی به ورودی خودش می‌چسبد و چشم بدون مکث، فرم را از بالا به پایین می‌خواند. قاعده ساده است: فاصله‌ی داخل یک گروه (Label ↔️ Field) را کم نگه دار و فاصله‌ی بین گروه‌ها را بیشتر کن تا نسبت‌دادن لیبل به فیلد، فوری و بدون ابهام باشد. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی فیلدهای فقط-زیرخط (underline) در نگاه اول کمتر شبیه «فرم قابل پر کردن» دیده می‌شوند؛ چون مرز ورودی واضح نیست و کاربر باید یک لحظه بیشتر فکر کند که کجا باید تایپ کند. مرزهای روشن، فهم فوری ایجاد می‌کنند و اسکن فرم را سریع‌تر می‌کنند. در نسخه‌ی بالایی، هر ورودی فقط با یک خط زیرین نشان داده شده؛ مخصوصاً برای کاربران کم‌تجربه یا وقتی سرعت مهم است، تشخیص “کادر ورودی” کندتر می‌شود و فرم مینیمال ولی مبهم به نظر می‌رسد. در نسخه‌ی پایینی، فیلدها با کادر مستطیلی و مرز قابل مشاهده طراحی شده‌اند؛ کاربر فوراً می‌فهمد این‌ها جاهای تایپ هستند، ساختار فرم واضح‌تر است و احتمال خطا/مکث کمتر می‌شود. قاعده ساده است: اگر فرم باید سریع و بی‌اصطکاک فهمیده شود، ورودی‌ها را با مرز قابل‌دیدن (کادر) مشخص کن؛ مینیمالیسمی که فهم را کند کند، هزینه دارد. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی پیام خطا باید «صادق، قابل فهم و راه‌حل‌محور» باشد؛ وقتی خطا را با رنگ/آیکون موفقیت نمایش می‌دهی یا به‌جای علت واقعی یک کد مبهم می‌دهی، کاربر هم گیج می‌شود هم اعتمادش ضربه می‌خورد. خطا یعنی مشکل رخ داده؛ UI باید دقیق بگوید چه شد و قدم بعدی چیست. در نسخه‌ی بالایی، با تیک سبز (نشانه موفقیت) پیام شکست نمایش داده شده و خطا هم مبهم است (“Unknown error 51526c”)؛ کاربر نمی‌فهمد مشکل چیست و فقط یک “Try again” می‌بیند که ممکن است دوباره به همان بن‌بست بخورد. در نسخه‌ی پایینی، پیام واضح است (“Email is already used”) و رابط بلافاصله دو مسیر عملی می‌دهد: “Log in instead” یا “pick a different email”؛ یعنی هم علت روشن است، هم اقدام بعدی مشخص، هم تجربه منصفانه و کم‌استرس‌تر می‌شود. قاعده ساده است: خطا را مثل خطا نشان بده (رنگ/آیکون درست)، علت را انسانی توضیح بده، و همیشه یک اقدام مشخص برای ادامه مسیر ارائه کن. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی وقتی چند المان نزدیک به هم «گوشه‌گردی تقریباً مشابه ولی نه دقیقاً یکسان» دارند، چشم یک ناهماهنگی ریز را حس می‌کند؛ انگار مسیر حرکت نگاه روی لبه‌ها مرتب قطع و وصل می‌شود. این اختلاف‌های میلی‌متری نه شخصیت بصری می‌سازند، نه معنا؛ فقط حس شلختگی و “سیستم طراحی ناپایدار” می‌دهند. در نسخه‌ی بالایی، کارت یک radius دارد و دکمه یک radius خیلی نزدیک ولی متفاوت؛ همین تفاوتِ کوچک باعث می‌شود لبه‌های پایین (جایی که دایره مشخص کرده) با هم هم‌ریتم نباشند و چشم نتواند یک «مسیر قابل پیش‌بینی» دور فرم پیدا کند. در نسخه‌ی پایینی، radiusها هماهنگ شده‌اند؛ لبه‌ها یک ریتم ثابت دارند، نگاه راحت‌تر دور کامپوننت حرکت می‌کند و کل کارت یک سیستم یکپارچه‌تر و حرفه‌ای‌تر به نظر می‌رسد. قاعده ساده است: radiusهای نزدیک به هم را متفاوت انتخاب نکن؛ یا دقیقاً یکسان‌شان کن یا آن‌قدر فاصله بده که تفاوت‌شان “عمدی” به نظر برسد. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی حتی روی دسکتاپ هم کلیک‌پذیری فقط «وجود یک چک‌باکس» نیست؛ اندازه‌ی ناحیه‌ی کلیک (hit area) تعیین می‌کند کاربر با چه سرعت و خطایی انتخاب کند. کنترل‌های خیلی ریز باعث miss-click، مکث‌های ناخواسته و حس “UI ضعیف” می‌شوند؛ مخصوصاً برای کاربران با دقت کمتر، ترک‌پد، یا لرزش دست. در نسخه‌ی بالایی، رادیوباتن‌ها و چک‌باکس‌ها کوچک‌اند و عملاً کاربر باید دقیق روی مربع/دایره کلیک کند؛ این یعنی اصطکاک بیشتر و احتمال خطای بیشتر، بدون هیچ ارزش افزوده. در نسخه‌ی پایینی، خود کنترل‌ها و فضای قابل کلیک بزرگ‌تر شده (و ردیف‌ها شبیه یک انتخاب‌گر واقعی دیده می‌شوند)؛ انتخاب سریع‌تر، مطمئن‌تر و قابل دسترس‌تر می‌شود. قاعده ساده است: کنترل‌های انتخابی را ریز طراحی نکن؛ hit area را بزرگ کن (حتی اگر ظاهر آیکون کوچک بماند) تا انتخاب با یک کلیک راحت و کم‌خطا شود. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی فیلدهایی که گوشه‌های خیلی گرد دارند یک مشکل ریز ولی واقعی می‌سازند: «لبه‌ی چپِ فیلد» برای شروع خواندن و هم‌تراز شدن عناصر، واضح و صاف نیست. نتیجه‌اش این است که چشم کاربر در ابتدای متن (لیبل و placeholder) یک لغزش کوچک تجربه می‌کند و تراز بصری فرم ضعیف‌تر می‌شود. در نسخه‌ی بالایی، گردیِ زیاد باعث شده مرز چپ فیلد به‌جای یک خط عمودیِ واضح، تبدیل به منحنی شود؛ بنابراین نقطه‌ی شروعِ “Email / Enter your…” دقیقاً روی یک خط ثابت نمی‌نشیند و حس ناهماهنگی ایجاد می‌کند. در نسخه‌ی پایینی، گردی کنترل شده است؛ هنوز نرم و مدرن به نظر می‌رسد، ولی لبه‌ی چپ “مزاحم خط تراز” نمی‌شود و چشم راحت‌تر فرم را اسکن می‌کند. قاعده ساده است: گوشه‌های گرد خوب‌اند، تا جایی که خطِ لبه (edge line) را خراب نکنند؛ اگر قرار است فرم سریع اسکن شود، گردیِ زیاد را کم کن. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#توسعه_برای_سه_شنبه_‌ها #Development #سهم_PM_از_توسعه رویکرد DDD از دید مدیر محصول (برای وقتی که سیستم بزرگ می‌شود و همه سر واژه‌ها با هم دعوا دارند) مفهوم DDD یعنی طراحی محصول و نرم‌افزار را حول «دامنه کسب‌وکار» انجام بده، نه حول دیتابیس و جدول و تکنولوژی. هدف اصلی‌اش کم‌کردن پیچیدگی با مدل‌سازی درست و همکاری نزدیک بین تیم فنی و خبره‌های کسب‌وکار است. 1. نقطه شروع PM در DDD: زبان مشترک (Ubiquitous Language) به‌جای اینکه هر تیم با لغت‌های خودش حرف بزند، یک زبان مشترک می‌سازید که «روی مدل دامنه» سوار است و داخل یک مرز مشخص توسط همه استفاده می‌شود. این زبان فقط داکیومنت نیست، باید وارد نام‌گذاری‌ها، سناریوها و تصمیم‌ها هم بشود. 2. مرزبندی: Bounded Context رویکرد DDD می‌گوید یک مدل واحد جهانی برای کل سازمان نساز؛ سیستم را به «کانتکست‌های محدود» تقسیم کن که داخل هرکدام مدل و معنی واژه‌ها ثابت و معتبر است. همان کلمه ممکن است در دو کانتکست معنی متفاوت داشته باشد و این طبیعی است. 3. خروجی کلیدی PM: Context Map (نقشه ارتباط کانتکست‌ها) بعد از مرزبندی، باید مشخص کنی این کانتکست‌ها چطور با هم تعامل دارند (وابستگی‌ها، upstream/downstream، قراردادهای تبادل داده). اینجاست که الگوهایی مثل Anti-Corruption Layer معنی پیدا می‌کنند: یک لایه ترجمه/محافظ که نگذارد مدل یک کانتکست، مدل کانتکست دیگر را آلوده کند. 4. رویکرد DDD برای PM یعنی “تصمیم‌های محصولی کمترِ اشتباه” رویکرد DDD به‌خصوص برای طراحی مرز سرویس‌ها/قابلیت‌ها مفید است چون کمک می‌کند وابستگی پنهان، coupling و اینترفیس‌های بد کمتر شود و مرزها با واقعیت کسب‌وکار هم‌راستا بمانند (و این کار، یک‌بار برای همیشه نیست و با تکامل محصول دوباره بازبینی می‌شود). 5. مثال خیلی ملموس در لندتک فرض کن دو کانتکست داری: Sales و Support. هر دو ممکن است چیزی به اسم “Customer” داشته باشند: * Sales.Customer برای قیمت‌گذاری، اعتبار، قرارداد، وضعیت فروش * Support.Customer برای SLA، کانال ارتباطی، تاریخچه تیکت‌ها اسم یکی است، ولی معنی و قوانین یکی نیست. تو به‌عنوان PM باید این تفاوت را صریح کنی و قرارداد ارتباطی‌شان را طراحی کنی (مثلاً Support فقط customerId مرجع را نگه دارد و برای نمایش “Customer 360” از API/رویدادها استفاده شود). 6. چک‌لیست عملی PM برای اجرای DDD در یک فیچر/محصول * لیست واژه‌های کلیدی دامنه + تعریف دقیقشان (Glossary) * تعیین Bounded Contextها (چه تیمی مالک کدام مدل/قواعد است) * نقشه یا Context Map : تعامل‌ها و قراردادها (API/Event) و جاهایی که ACL لازم است * قوانین کلیدی هر کانتکست (Invariants) و اینکه کجا enforce می‌شوند * تصمیم‌های مرزی (چه داده‌ای share می‌شود و چه چیزی فقط از طریق contract مصرف می‌شود) ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی ستاره‌های قرمز و «اجباری کردنِ اکثر فیلدها» از همان اول به کاربر پیام سخت‌گیرانه می‌دهد: انگار سیستم دنبال گرفتن اطلاعات است، نه کمک‌کردن به ثبت‌نام. این هم اضطراب ایجاد می‌کند، هم ریزش فرم را بالا می‌برد؛ مخصوصاً وقتی دلیل نیاز به داده‌ها روشن نیست. در نسخه‌ی بالایی، کنار Email و Password ستاره قرمز گذاشته شده و حتی City هم بدون توضیح، در فرم آمده؛ نتیجه‌اش این است که کاربر حس می‌کند همه چیز باید پر شود و یک مانع اضافی جلوی “Create account” ایجاد شده است. در نسخه‌ی پایینی، فقط فیلدهای ضروری ارائه شده‌اند و برای City برچسب “optional” آمده؛ یعنی هم شفافیت بالا رفته، هم فشار روانی کم شده، هم کاربر می‌فهمد می‌تواند سریع ادامه بدهد. قاعده ساده است: حداقل اطلاعات لازم را بگیر؛ اگر فیلدی واقعاً اختیاری است، حذفش نکن—کنارش «optional» بزن تا کاربر احساس کنترل و سرعت داشته باشد. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین) قسمت : 3 عنوان: سه نقش متفاوت مدیر محصول خب! تو این جلسه قراره در مورد انواع مختلف مدیر محصول صحبت کنیم. همچنین چندتا اصطلاح رایج رو یاد می‌گیریم، پس عالیه! تو دنیای توسعه‌ی نرم‌افزار و تکنولوژی، بیش از یه نوع مدیر محصول وجود داره. سه تا از مهم‌ترین نوع‌هایی که می‌خوام در موردشون صحبت کنم عبارتند از: * مدیر محصول داخلی (Internal Product Manager): این مدیران محصول گاهی اوقات عضو تیمی به اسم «ابزارهای داخلی» یا یه اسم مشابه هستن. اون‌ها و تیم‌شون معمولا ابزارهایی رو برای سایر افراد سازمان‌شون می‌سازن. این ابزارها برای استفاده‌ی داخلی هستن، نه برای کاربران یا مشتریان عمومی. یه مثال خوب از یه مدیر محصول داخلی کسیه که با تیمش برای ساخت نرم‌افزاری کار می‌کنه که تیم پشتیبانی شرکت از اون برای ری‌ست کردن رمز عبور یا تغییر اطلاعات حساب کاربری استفاده می‌کنه. تو این مثال، ذی‌نفع (Stakeholder) کسیه که به صورت داخلی از اون نرم‌افزار استفاده می‌کنه. * مدیر محصول کسب‌وکار به کسب‌وکار (Business to Business Product Manager) یا مدیر محصول SaaS (نرم‌افزار به عنوان سرویس): این نوع مدیر محصول، محصولاتی رو تو شرکتی می‌سازه که مشتریانش شرکت‌های دیگه هستن. نمونه‌هایی از این شرکت‌ها اوراکل (Oracle) یا Salesforce هستن. این محصولات برای حل مشکلات سایر شرکت‌ها طراحی می‌شن. تو اینجور شرکت‌ها، ذی‌نفع‌ها یا همون کسایی که مدیر محصول با تیمش برای اون‌ها محصول می‌سازه، شرکت‌های دیگه هستن. این یعنی مدیر محصول باید خیلی با تیم فروش شرکت خودش در ارتباط باشه و مطمئن بشه محصولی که می‌سازه، نیازمندی‌های تجاری شرکت‌هایی که بهشون می‌فروشه رو برآورده کنه. اگه شما یه مدیر محصول B2B هستید، قراره خیلی با تیم فروش صحبت کنید. * مدیر محصول کسب‌وکار به مصرف‌کننده (Business to Consumer Product Manager): یه مدیر محصول B2C چیکار می‌کنه؟ مدیر محصول کسب‌وکار به مصرف‌کننده، نوع رایج‌تریه و به این معنیه که شما یه مدیر محصول هستید که محصولتون برای مصرف‌کنندگان عمومیه. خود من یه مدیر محصول B2C تو ساوندکلود (SoundCloud) هستم، چون روی بخش‌هایی از اپلیکیشن کار می‌کنم که میلیون‌ها نفر تو عموم هر روز ازش استفاده می‌کنن. نمونه‌های دیگه از جاهایی که مدیران محصول B2C زیادی دارن، فیس‌بوک، توییتر و اینستاگرام هستن. برای موفقیت تو نقش مدیریت محصول B2C به مجموعه‌ای از مهارت‌ها و همچنین دید قوی و خلاقیت نیاز هست. تو نقش B2C، مدیران محصول سعی می‌کنن میزان استفاده یا یه معیار دیگه رو به حداکثر برسونن. هیچ‌کس نیست که بهشون بگه «فلان کار بهترین کار بعدی برای انجام دادنه». این با نقش مدیر محصول B2B فرق داره، چون مثلا تیم فروش می‌گه «اگه این قابلیت رو بسازیم، 5 میلیون دلار درآمد کسب می‌کنیم». تو بخش مصرف‌کننده، هیچ‌کس نمی‌تونه با قطعیت بگه دقیقا چه چیزی لازمه ساخته بشه. پس مدیر محصول B2C زمان زیادی رو صرف صحبت با اون کاربرا، اون میلیون‌ها کاربر، می‌گذرونه، چندین نمونه اولیه (Prototype) مختلف می‌سازه، تست کاربری انجام می‌ده، تست A/B انجام می‌ده و حجم زیادی از داده رو تحلیل می‌کنه. هر چی تعداد کاربر بیشتر باشه، تست‌ها هم قدرتمندتر می‌شن. خب، اینم از سه نوع مدیر محصول. ما مدیر محصول ابزارهای داخلی، مدیر محصول کسب‌وکار به کسب‌وکار و مدیر محصول کسب‌وکار به مصرف‌کننده رو داشتیم. نوع‌های دیگه‌ای از مدیر محصول هم وجود داره، اما این سه تا، مهم‌ترین نوع‌هایی هستن که باید باهاشون آشنا باشید. تا جلسه بعد! اصطلاحات: * Stakeholder (ذی‌نفع): افراد یا گروه‌هایی که بر موفقیت یا شکست یه پروژه یا محصول تأثیر دارن یا تحت تأثیر اون قرار می‌گیرن. * Internal Tools (ابزارهای داخلی): نرم‌افزارها و ابزارهایی که برای استفاده‌ی کارکنان داخلی یه سازمان طراحی و توسعه داده می‌شن. * Prototype (نمونه اولیه): یه مدل اولیه یا یه نسخه‌ی ناقص از یه محصول که برای تست و دریافت بازخورد از کاربران قبل از شروع توسعه‌ی نهایی ساخته می‌شه. * User Testing (تست کاربری): فرآیندی که تو اون کاربران یه محصول رو تست می‌کنن و بازخورد در مورد تجربه‌ی کاربری‌شون ارائه می‌دن. * A/B Testing (تست A/B): یه روش تحقیقاتی که تو اون دو نسخه‌ی مختلف از یه وب‌سایت یا اپلیکیشن به طور تصادفی به دو گروه از کاربران نشون داده می‌شه و داده‌ها برای تعیین اینکه کدوم نسخه عملکرد بهتری داره، جمع‌آوری و مقایسه می‌شن. * Big Data (داده‌های حجیم): حجم عظیمی از داده‌ها که به دلیل حجم و پیچیدگی زیاد، با روش‌های سنتی قابل پردازش و تجزیه و تحلیل نیستن. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

موفق‌ترین تجربه‌های «میکروسرویس» معمولاً از جایی شروع شده‌اند که تیم اول یک مونولیت ساخته، محصول رشد کرده و وقتی مونولیت واقعاً بزرگ و دردسرساز شده، آن را تکه‌تکه کرده و به سرویس‌های جدا تبدیل کرده است؛ یعنی «میکروسرویس از روز اول» اغلب هزینه و پیچیدگی اضافه می‌آورد قبل از اینکه محصول به آن نیاز داشته باشد. آقای Martin Fowler است؛ نویسنده و صاحب‌نظر شناخته‌شده در معماری نرم‌افزار که در Thoughtworks عنوان Chief Scientist دارد و در سایت شخصی‌اش همین الگوی «Monolith First» را به‌عنوان مشاهده‌اش از پروژه‌های واقعی بیان کرده است. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#چشم_انداز_چهارشنبه #استراتژی یک نمونه‌ی خوب از «استراتژی شاخص‌محور» را Airbnb اجرا می‌کند: چرخاندن تصمیم‌های محصول و رشد حول یک عدد ساده به نام “Nights & Seats Booked” (قبلاً “Nights & Experiences Booked”). چرا این شاخص هوشمند است؟ چون مستقیم به ارزش اصلی پلتفرم وصل است: هر “night” یعنی یک تطبیق موفق بین عرضه (میزبان) و تقاضا (مهمان) رخ داده، و “seat” (نفرات) هم همان مفهوم را برای سرویس‌ها/تجربه‌ها پوشش می‌دهد. Airbnb حتی تعریفش را دقیق می‌نویسد: مجموع شب‌های رزرو شده برای اقامت + تعداد نفرات رزرو شده برای سرویس/تجربه، با کسر لغوها و تغییرات. و هشدار می‌دهد استاندارد واحدی برای محاسبه این‌ها در صنعت وجود ندارد، پس باید تعریف را شفاف و ثابت نگه داشت. درس برای PMها: «North Star Metric» وقتی درست انتخاب شود، تیم را از جنگ سلیقه‌ای نجات می‌دهد. تعریف کلاسیک این است: یک عدد که بهترین نماینده‌ی ارزش دریافتی مشتری از محصول است و جهت‌گیری تیم را هم‌راستا می‌کند. #مدیریت_محصول #استراتژی_محصول #Metrics #Airbnb ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#توسعه_برای_سه_شنبه_‌ها #Development #سهم_PM_از_توسعه «قرارداد» بین فرانت و بک یا API یعنی همان چیزی که اگر جدی‌اش نگیری، پروژه‌ات تبدیل می‌شود به دعوای بی‌پایان “پس چرا این‌طوری زدی؟” در ساده‌ترین مدل وب، کل داستان این است: کلاینت (فرانت‌اند یا اپ) یک Request می‌فرستد تا کاری روی سرور انجام شود و سرور یک Response برمی‌گرداند؛ همین پیام‌ها (Request/Response) واحد پایه تبادل داده در HTTP هستند. «قرارداد» یعنی دقیقاً توافق کنید endpoint چیست، با چه متدی صدا زده می‌شود (GET) برای خواندن، (POST) برای ایجاد، ()PATCH برای تغییر)، ورودی‌ها چه‌اند (پارامترها، بدنه، هدرها)، خروجی چه فرمتی دارد JSON) با فیلدهای مشخص)، و در حالت‌های خطا چه کدی برمی‌گردد (۲۰۰/۲۰۱/۴۰۰/۴۰۱/۴۰۳/۴۰۴/۴۲۲/۵۰۰ و غیره). کدهای وضعیت هم استانداردند و کلاس‌بندی مشخصی دارند، پس “هرچی شد یه ۲۰۰ بده” از آن ایده‌های درخشان انسانی است. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

#دوشنبه_های_دیزاین #UX #نکات_ظریف_طراحی دکمه‌ای که متنش به لبه‌ها می‌چسبد، ناخواسته «فشرده، ارزان و ناپایدار» به نظر می‌رسد؛ چون فضای تنفسی (padding) کافی ندارد و چشم کاربر حس می‌کند متن ممکن است بریده شود یا دکمه کوچک‌تر از حد لازم است. این موضوع خوانایی را هم پایین می‌آورد و لمس‌پذیری را بدتر می‌کند. در نسخه‌ی بالایی، متن “Save changes” نزدیک به لبه‌های دکمه است؛ تعادل بصری به‌هم می‌خورد و دکمه در مقایسه با کارت، ضعیف و نامطمئن دیده می‌شود. در نسخه‌ی پایینی، از هر طرف فضای خالی کافی برای لیبل گذاشته شده؛ متن راحت‌تر خوانده می‌شود، دکمه محکم‌تر و حرفه‌ای‌تر دیده می‌شود و سیستم طراحی برای طول‌های مختلف متن (ترجمه‌ها/نام‌های بلند) قابل اتکاتر می‌شود. قاعده ساده است: برای دکمه‌ها حداقل «۱× padding» از هر طرفِ متن بده؛ اگر جا داری «۲× بهتر است»—تا هم خوانایی خوب بماند، هم در زبان‌های مختلف متن به لبه نچسبد. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین) قسمت : 2 عنوان: محصول چیست؟ همه موارد زیر محصول به حساب میان: یه وب‌سایت، یه اپلیکیشن موبایل، یه ابزار سخت‌افزاری، یه موتور جستجو، و حتی یه فید خبری تو یه شبکه‌ی اجتماعی. این یعنی یه مدیر محصول کسیه که این محصولات رو مدیریت می‌کنه. هر قابلیت (فِیچِر) انقدر حیاتیه و پیچیده‌ست که برای مدیریت اون به یه تیم اختصاصی به اسم تیم محصول یا تیم فِیچِر نیاز هست. نکته‌ی مهم اینه که تو اصطلاحات مدیریت محصول، به یه قابلیت، محصول گفته می‌شه. این محصول توسط یه مدیر محصول و با همکاری یه تیم از طراحا و مهندسا مدیریت و توسعه پیدا می‌کنه. این تیم‌ها، همون‌طور که گفتیم، تیم محصول یا تیم فِیچِر نامیده می‌شن. بذارید با مثال فیس‌بوک یه کم عمیق‌تر به این موضوع بپردازیم. فید خبری فیس‌بوک یه محصوله. چون این یه بخش خیلی بزرگ از تکنولوژی فیس‌بوکه، یه مدیر محصول خاص به رهبری تیمی که روی الگوریتم رتبه‌بندی کار می‌کنه، مسئولشه. پس الان باید دیگه واضح باشه که تیم‌های محصول بر اساس قابلیت‌هایی که مدیریت می‌کنن، تفکیک نمی‌شَن. تا جلسه بعد! اصطلاحات: * Feature (فِیچِر): قابلیت. یه بخش یا عملکرد خاص تو یه محصول نرم‌افزاری یا سخت‌افزاری. * Product Team (تیم محصول): تیمی متشکل از افراد مختلف مثل مدیر محصول، طراح، مهندس و غیره که مسئولیت توسعه و مدیریت یه محصول خاص رو بر عهده دارن. * Feature Team (تیم فِیچِر): معادل تیم محصوله و هر دو اصطلاح برای توصیف تیمی که مسئولیت یه محصول خاص رو داره، به کار می‌رن. * Ranking Algorithm (الگوریتم رتبه‌بندی): الگوریتمی که نحوه‌ی نمایش و اولویت‌بندی محتوا رو تو یه فید خبری یا نتایج جستجو، مشخص می‌کنه. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog

جمله «Less, but better» خلاصه‌ی فلسفه‌ی طراحی دیتر رامز است: حذفِ هر چیز غیرضروری تا محصول ساده‌تر، قابل‌فهم‌تر و باکیفیت‌تر شود. دیتر رامز طراح صنعتی آلمانی و چهره‌ی کلیدی شرکت Braun است که با «۱۰ اصل طراحی خوب» و مینیمالیسم کارکردمحورش روی طراحی مدرن (از جمله محصولات اپل) اثر جدی گذاشت. ✍️ تفکر محصول | امیرحسین کاشفی بینش هوشمند راهبری محصول ماندگار 👉@ProductXblog