از یک ابزار ثبت فاکتور تا یک حلقه ارزش محصول

Brief پروژه

سگمنت مشتریان

• تنوع کالایی بالایی داشتند بیش از 1500 قلم کالا؛
• فروش حضوری بالایی داشتند؛
• و در نتیجه، کیفیت موجودی آن‌ها تأثیر مستقیمی بر تنوع کالای قابل‌فروش در اکالا داشت.

01 — ابتدا Brief را به یک سؤال قابل‌بررسی تبدیل کردم

من Brief را این‌طور می‌خواندم:

Business Problem:
موجودی ثبت‌شده فروشگاه‌ها دقیق نیست → کالاهای موجود در فروشگاه روی اکالا قابل فروش نیستند → تنوع و فروش آنلاین کاهش پیدا می‌کند.

Product Hypothesis:
اگر ثبت فاکتور خرید و اصلاح موجودی ساده‌تر و سریع‌تر شود، فروشگاه‌ها بیشتر از PDA استفاده می‌کنند و در نتیجه کیفیت داده موجودی بهتر می‌شود.

اما هنوز یک چیز را نمی‌دانستم:

آیا واقعاً مشکل، سخت بودن ابزار است؟

چون اگر مشکل اصلی انگیزه، ارزش perceived، آموزش، فرآیند کاری یا هر چیز دیگری باشد، صرفاً redesign کردن PDA مسئله را حل نمی‌کند.

بنابراین اولین سؤال من:

دقیقاً در کدام نقطه از مسیر، Adoption و Workflow دچار اختلال می‌شوند؟

02 — در ادامه وضعیت موجود و الگوی استفاده از PDA را بررسی کردم

قبل از اینکه چیزی طراحی کنم، می‌خواستم بفهمم:

1. چه فروشگاه‌هایی PDA دارند؟
2. کدام فروشگاه‌ها واقعاً از آن استفاده می‌کنند؟
3. از PDA برای چه کارهایی استفاده می‌کنند؟
4. کجا از PDA استفاده نمی‌کنند و به POS برمی‌گردند؟
5. فرایند ثبت فاکتور و اصلاح موجودی بدون PDA چگونه انجام می‌شود؟
6. تفاوت رفتار کاربران فعال و غیرفعال چیست؟

2.1 Data Analysis

برای اینکه ابتدا یک تصویر کمی از وضعیت موجود داشته باشم، از تیم Data خواستم الگوی استفاده از PDA را در سطح فروشگاه‌ها استخراج کند؛ از جمله میزان استفاده از PDA برای ثبت فاکتور خرید و اصلاح موجودی و وضعیت موجودی فروشگاه‌ها.

فروشگاه‌ها را بر اساس میزان استفاده از PDA به چند گروه تقسیم کردم تا بتوانم رفتار و عملکرد آن‌ها را با یکدیگر مقایسه کنم. نتایج به دست آمده از این بخش به شرح زیر است

نتیجه گیری خیلی مهم:

• نتایج به دست آمده از جدول بالا نشان داد کنسل یا ویرایش کردن سفارش آنلاین در فروشگاه ها ارتباط معناداری با موجودی غلط فروشگاه ندارد و احتمالا عامل دیگری باعث اصلاح و کنسلی سفارش آنلاین فروشگاه ها میشود و در این مرحله رسیدگی و پیگیری این مسئله از بازطراحی PDA خارج شد و توسط تیم جداگانه ای پیگیری و برطرف شد.
• نتایج بالا همچنین نشان داد حتی فروشگاه هایی که به طور مرتب فاکتور خرید ثبت میکنند همه فاکتورها را با PDA ثبت نمیکنند و نیاز بود علت این مسئله ریشه یابی شود

02.2 — Behavioral Research | کاربران در عمل چگونه کار می‌کنند؟

برای فهمیدن رفتار واقعی کاربران، با فروشگاه‌هایی که در حال حاضر PDA داشتند تماس گرفتم و درباره‌ی فرایند واقعی کارشان از لحظه دریافت کالا تا ثبت فاکتور، اصلاح موجودی و به‌روزرسانی قیمت‌ها مصاحبه کردم.

به‌جای پرسیدن صرفاً «چه مشکلی با PDA دارید؟»، سؤال‌ها را حول رفتار واقعی آن‌ها طراحی کردم؛ مثلاً:

• وقتی کالای جدید وارد فروشگاه می‌شود، از ابتدا چه کاری انجام می‌دهید؟
• فاکتور خرید را کجا و چگونه ثبت می‌کنید؟
• اگر موجودی سیستم اشتباه باشد، چه کاری انجام می‌دهید؟
• چه زمانی از PDA استفاده می‌کنید و چه زمانی سراغ POS می‌روید؟
• برای چه کارهایی حاضر هستید زمان بگذارید؟
• چه کارهایی را انجام نمی‌دهید و چرا؟
• اگر کالایی بارکد نداشته باشد چه می‌کنید؟
• وقتی قیمت خرید کالا تغییر می‌کند، چگونه قیمت آن را در سیستم به‌روزرسانی می‌کنید؟

نتیجه گیری خیلی مهم:

خروجی اول: PDA به‌تنهایی مسئله Adoption را حل نمی‌کرد

مهم‌ترین یافته این بود که مسئله فقط سرعت یا usability نبود.

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

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

نتیجه:

بهبود PDA می‌توانست friction عملیاتی را کاهش دهد، اما به‌تنهایی نمی‌توانست مشکل Value Perception / Motivation را حل کند. برای این بخش به یک راهکار محصولی یا بیزینسی جداگانه نیاز داشتیم.

خروجی دوم: تعداد بالای کالاهای با موجودی منفی مانع شروع اصلاح موجودی بود

خروجی سوم: خود PDA نیز چند مانع Adoption داشت

در مصاحبه‌ها، علاوه بر مسئله انگیزه، چند مانع مشخص در خود محصول پیدا کردم:

۱. نبود Search برای کالا

PDA عمدتاً بر پایه اسکن بارکد طراحی شده بود و امکان جست‌وجوی مناسب کالا وجود نداشت. در نتیجه برای کالاهای بدون بارکد، مثل برخی کالاهای فله‌ای، کاربر نمی‌توانست به‌راحتی عملیات را انجام دهد.

۲. نیاز به پشتیبانی از کالاهای چندقیمتی / Jet Print

برخی فروشگاه‌ها یک کالا را با قیمت‌های متفاوت در موجودی داشتند؛ به‌خصوص در شرایط تورمی، کالاهایی که در زمان‌های مختلف و با قیمت‌های متفاوت خریداری شده بودند. این موضوع نیاز به Jet Print / پشتیبانی از چند قیمت برای یک کالا را ایجاد می‌کرد.

۳.عدم اعتماد مدیر فروشگاه به کارگر تحویل بار برای ثبت فاکتور خرید در زمان تحویل بار با PDA

مدیر فروشگاه باور داشت کارگر تحویل گیرنده بار سوار کافی ندارد و نمیتواند فاکتورخرید را ثبت کند در حالی که ثبت فاکتور با PDA مستقیما در صندوق ثبت میشود 

۳. کمبود صبر کاربر در فرایندهای طولانی

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

بنابراین از Behavioral Research به دو دسته مسئله رسیدم:

این تفکیک خیلی مهم بود؛ چون نشان داد همه مشکلات را نباید با Redesign خود PDA حل کرد.

02.3 — Event Tracking & Task Analysis | دقیقاً کجا friction ایجاد می‌شود؟

بعد از اینکه فهمیدم چه کسانی از PDA استفاده نمی‌کنند و چرا، تمرکز را روی کاربرانی گذاشتم که قصد استفاده از PDA را داشتند.

سؤال جدید این بود:

در خود فرایند ثبت فاکتور و اصلاح موجودی، دقیقاً کدام مرحله بیشترین زمان یا تعامل را از کاربر می‌گیرد؟

برای پاسخ به این سؤال، فرایندها را به Micro-task شکستم و برای مراحل اصلی Event Tracking تعریف کردم تا بتوانیم زمان، تعداد تعامل و نقاط ریزش را اندازه‌گیری کنیم.

متریک‌هایی که برای Tracking تعریف کردم

خروجی این مرحله

این Tracking به من اجازه داد فرایند را از یک «فلو کلی» به مجموعه‌ای از نقاط قابل‌اندازه‌گیری تبدیل کنم و بفهمم:

کجا کاربر بیشتر مکث می‌کند؟
کجا تعامل اضافی دارد؟
کجا خطا می‌کند؟
کجا فرایند را رها می‌کند؟
و کدام بخش بیشترین سهم را در زمان کل عملیات دارد؟

نتایج به دست آمده از Event های بالا به شرح زیر است

03 — از Insight به راه‌حل رسیدم

تحلیل داده و تحقیق رفتاری نشان داد که مسئله فقط «سخت بودن PDA» نیست. در واقع با چند مانع متفاوت روبه‌رو بودیم:

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

بنابراین به‌جای اینکه همه مشکلات را با یک Redesign حل کنیم، برای هر مانع یک راهکار جداگانه در نظر گرفتیم.

03.1 — ایجاد انگیزه برای اصلاح موجودی

مسئله

برای بخشی از فروشگاه‌ها، مسئله اصلی نبود انگیزه بود، نه سخت بودن PDA.

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

راهکارهای پیشنهادی

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

فرضیه

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

03.2 — وقتی مشکل «زیاد بودن کار» بود، کار را کوچک کردم

مسئله

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

برای فروشگاهی که صدها یا هزاران SKU با موجودی منفی دارد، پیام «موجودی خود را اصلاح کنید» عملاً یک Task بسیار بزرگ است.

کاربر نمی‌دانست:

«از بین این همه کالا، از کجا شروع کنم؟»

راهکار: Daily Recommendations

به‌جای اینکه تمام موجودی‌های اشتباه را یکجا به کاربر نشان دهیم، پیشنهاد شد سیستم هر روز تعداد محدودی از مهم‌ترین کالاها را پیشنهاد کند.

منطق اولیه:

Top-selling products on Akala
↓
مقایسه با موجودی فروشگاه
↓
شناسایی کالاهای مهم با موجودی اشتباه
↓
نمایش چند مورد با اولویت بالاتر
↓
اصلاح موجودی همان موارد

مثلاً به‌جای اینکه کاربر با لیستی از ۲۰۰ SKU مواجه شود:

امروز این ۳ کالا را بررسی کنید.

این Recommendation می‌توانست هم در PDA و هم در صفحه فروش قرار بگیرد.

هدف

کاهش Cognitive Load و تبدیل یک کار بزرگ و مبهم به مجموعه‌ای از Taskهای کوچک و قابل انجام.

03.3 — پوشش سناریوهایی که PDA فعلی پشتیبانی نمی‌کرد

Behavioral Research نشان داد که حتی کاربرانی که قصد استفاده از PDA را داشتند، در بعضی سناریوها مجبور بودند به POS برگردند.

چند نیاز مشخص شناسایی شد:

Search

PDA عمدتاً بر پایه Barcode Scan بود و برای کالاهای بدون بارکد، مانند برخی کالاهای فله‌ای، کاربر مسیر مناسبی برای پیدا کردن کالا نداشت.

راهکار: اضافه کردن Search به جریان انتخاب کالا.

کالاهای چندقیمتی / Jet Print

فروشگاه‌ها ممکن بود یک SKU را در چند نوبت و با قیمت خرید متفاوت تهیه کرده باشند. بنابراین ثبت یک قیمت واحد برای همه موجودی همیشه با واقعیت فروشگاه سازگار نبود.

راهکار: پشتیبانی از چند قیمت برای یک کالا / Jet Print.

03.4 — کاهش ریسک ثبت فاکتور برای کاربران کم‌تجربه

یکی از یافته‌های Behavioral Research این بود که بعضی کاربران به‌خصوص در فروشگاه‌هایی با نیروی کم‌تجربه، نسبت به ثبت مستقیم اطلاعات خرید در سیستم اطمینان نداشتند.

در بررسی الگوهای رقبا، دیدیم که در برخی محصولات مشابه، ثبت فاکتور به‌صورت مستقیم نهایی نمی‌شود و ابتدا در وضعیت Draft قرار می‌گیرد.

راهکار

فرایند ثبت فاکتور را به یک جریان دو مرحله‌ای تبدیل کردیم:

ثبت اطلاعات فاکتور
↓
Draft
↓
بازبینی / تأیید
↓
ثبت نهایی

این مدل به کاربر اجازه می‌داد قبل از تأثیر نهایی اطلاعات روی سیستم، آن را بررسی و تأیید کند.

03.5 — و در نهایت، خود Workflow را ساده کردم

تا اینجا چند مسئله Adoption و Workflow را شناسایی و برایشان راهکار در نظر گرفته بودیم.

اما برای کاربرانی که واقعاً می‌خواستند از PDA استفاده کنند، یک سؤال باقی مانده بود:

آیا خود فرایند PDA می‌تواند سریع‌تر و کم‌اصطکاک‌تر شود؟

اینجا وارد طراحی اصلی شدم.

04 — طراحی PDA بر اساس Frictionهای اندازه‌گیری‌شده

با استفاده از Micro-taskها و Eventهایی که در مرحله قبل تعریف کرده بودم، طراحی را بر اساس نقاطی که بیشترین زمان، تعامل و ریزش ایجاد می‌کردند انجام دادم.

هدف صرفاً تغییر ظاهر نبود؛ بلکه می‌خواستم:

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

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

یکی از تصمیم‌های مهم، کاهش تعداد Stepهای قابل مشاهده در فرایند ثبت فاکتور بود؛ به‌جای اینکه کاربر با چندین بخش و کنترل مواجه شود، جریان اصلی به چند اقدام واضح و محدود تبدیل شد.

04.1 — Prototype Validation

بعد از طراحی اولیه، Prototype را قبل از پیاده‌سازی با اعضای تیم بررسی کردم و برای بررسی فنی و رفتاری، آن را در فرآیند QA نیز تست کردیم.

در این مرحله هدف فقط پیدا کردن Bug نبود؛ بررسی می‌کردیم که آیا:

• کاربر متوجه مسیر انجام Task می‌شود؟
• CTAها قابل تشخیص هستند؟
• اطلاعات ضروری در دسترس است؟
• فرایند با منطق عملیاتی فروشگاه سازگار است؟
• طراحی جدید محدودیت‌های فنی و اجرایی را ایجاد نمی‌کند؟

پس از پیاده‌سازی نیز رفتار واقعی کاربران را با Clarity بررسی کردم تا ببینم آیا frictionهایی که در طراحی پیش‌بینی کرده بودم، در استفاده واقعی نیز برطرف شده‌اند یا نه.

04.2 — Measurement | آیا واقعاً Workflow بهتر شد؟

اینجا پیشنهاد می‌کنم جدول Metrics را حتماً بیاوری، ولی عدد ساختگی نگذاری. چون این بخش یکی از قوی‌ترین Evidenceهای Case Study تو می‌تواند باشد.

ساختار جدول:

04.3 — Iteration | داده نشان داد هنوز یک مشکل باقی مانده

بعد از پیاده‌سازی، دوباره Eventها را بررسی کردم.

یک الگوی غیرمنتظره دیدم:

در بعضی فروشگاه‌ها، زمان ثبت فاکتور به ازای هر آیتم همچنان بالا بود.

این بار به‌جای اینکه دوباره حدس بزنم، Sessionهای همین فروشگاه‌ها را در Clarity بررسی کردم.

چیزی که در Sessionها دیدم

کاربر بعد از اضافه کردن چند کالا، مرتب در لیست آیتم‌ها Scroll می‌کرد تا بررسی کند:

«این کالا را ثبت کردم یا نه؟»

بررسی بیشتر نشان داد که مشکل از سرعت اسکن نبود.

فضای نمایش Line Itemها بیش از حد کوچک شده بود.

بخش زیادی از صفحه توسط Inputها اشغال شده بود و در نتیجه کاربر برای دیدن لیست کالاهای ثبت‌شده فضای کافی نداشت.

این یک Insight مهم بود:

Friction در اینجا از «ورود اطلاعات» نبود؛ از «Review کردن اطلاعات واردشده» بود.

04.4 — Iteration دوم: طراحی را بر اساس رفتار واقعی اصلاح کردم

برای حل این مشکل، بخش Input را از فضای اصلی Workflow خارج کردم و آن را به Bottom Sheet منتقل کردم.

در نتیجه:

قبل

Inputهای بزرگ
↓
فضای کم برای Line Items
↓
Scroll زیاد
↓
زمان بیشتر برای Review

بعد

Line Items با فضای بیشتر
↕
Bottom Sheet برای ورود / ویرایش اطلاعات

این تغییر باعث شد کاربر بتواند تعداد بیشتری از آیتم‌های ثبت‌شده را همزمان ببیند و بدون Scrollهای مکرر آن‌ها را بررسی کند.

همزمان متوجه شدم جدول اطلاعات بیش از حد متراکم است و بعضی ستون‌ها ارزش عملیاتی کافی برای این Task ندارند.

بنابراین اطلاعات را دوباره اولویت‌بندی کردم و ستون‌های غیرضروری، مثل قیمت فروش در این مرحله از Workflow، حذف شدند تا فضای بیشتری برای اطلاعات ضروری باقی بماند و خوانایی Line Itemها افزایش پیدا کند.