Workload عملیاتی بالا
هماهنگی و ورود اطلاعات به‌صورت دستی زمان زیادی می‌گرفت.
کیس‌استادی طراحی محصول 01 — 15
از یک عملیات دستی و پراکندههومکا.به یک محصول ساختاریافته‌تر برای خدمات درمانی و آزمایشگاهی در محل
هومکا پلتفرمی برای ارائه خدمات درمانی و آزمایشگاهی در محل است؛ از ثبت درخواست و نمونه‌گیری تا دریافت نتیجه و تفسیر پزشکی. در طول حدود ۳.۵ سال، روی بخش‌های مختلف محصول کار کردم تا فرایندهای دستی و پراکنده، به تجربه‌هایی قابل‌پیگیری‌تر تبدیل شوند.
شروع روایتPRODUCT DESIGN / HOMECA
DESIGNING
THE SYSTEM
BEHIND THE SERVICE
THE SYSTEM
BEHIND THE SERVICE
نقش منطراح محصولProduct Designer
مدت همکاریحدود ۳.۵ سالاز ۱۴۰۰
نوع پروژهمحصول واقعیدر حال رشد
دامنه مسئولیتاز مسئله تا تحویلطراحی، همکاری فنی، تست و QA
02نگاهی به محصول
هومکا؛ یک تجربه چندوجهی برای ارائه خدمات سلامت در محل
هومکا فقط یک سایت یا پنل کاربر نبود. تجربه سرویس از ثبت درخواست تا عملیات، متخصصان، پرداخت، نتیجه و تفسیر بین چند بخش مختلف محصول جریان داشت.
HOMECA-HOME-01اسکرین‌شات واقعی صفحه اصلی هومکاتصویر را بارگذاری کنید
HOMECA-REQUEST-FORM-01فرم ثبت درخواست موبایلتصویر را بارگذاری کنید
03نقطه شروع
بخش بزرگی از سرویس خارج از محصول اجرا می‌شد
محصول موجود برای پیچیدگی‌های لاین آزمایش خون طراحی نشده بود. بسیاری از مراحل از طریق شیت‌ها، گروه‌های پیام‌رسان و انتقال دستی اطلاعات جلو می‌رفتند.
جریان اولیه عملیات BEFORE / MANUAL WORKFLOW
ثبت درخواست←عملیات←محاسبه در شیت←گروه پزشک←انتقال دستی←نمونه‌گیر←پیگیری نتیجه
هزینه پنهان این فرایند چه بود؟
خطای انسانی
Copy/Paste، شیت‌ها و پیام‌رسان‌ها مستعد خطا بودند.
داده پراکنده
مشخص نبود دقیقاً روی هر سفارش چه اتفاقی افتاده است.
ردیابی دشوار
Traceability کامل مسیر درخواست وجود نداشت.
ابهام برای کاربر
کاربر وضعیت سرویس و مرحله بعد را به‌روشنی نمی‌دید.
04تکامل محصول
محصول یک‌باره بازطراحی نشد؛ مرحله‌به‌مرحله بالغ شد
به‌جای بازسازی ناگهانی همه‌چیز، تجربه در چند جریان واقعی و در ارتباط با نیازهای روزمره عملیات توسعه پیدا کرد.
05
Structured Data & Automation
ساخت ساختار داده و اتوماسیون‌های بیشتر برای هزینه، سفارش و عملیات
SELECTED FLOW01 / 04
05Sampler PWA
از «آدرس + توضیح + انجام شد» به ابزار عملیات میدانی
پنل اولیه فقط اطلاعات پایه سفارش و دکمه انجام شد را ارائه می‌کرد؛ درحالی‌که اجرای واقعی نمونه‌گیری به تصمیم‌ها، داده‌ها و ثبت وضعیت‌های بسیار بیشتری نیاز داشت.
قبل از طراحی مجدد
یک لیست از درخواست‌ها
شماره تماس، آدرس، توضیحات عملیات و دکمه «انجام شد». تقریباً بدون پوشش فرایند واقعی خدمت.
بعد از توسعه تجربه
ابزار اجرای خدمت
درخواست‌های جدید، اعلام آمادگی، ارجاع نهایی، اطلاعات بیمار، ثبت زمان و وضعیت، مستندسازی و تحویل.
قابلیت‌های اضافه‌شده FIELD OPERATIONS
درخواست‌های قابل انجامموقعیت و اعلام آمادگیاطلاعات بیماراقلام و پکیجکد رهگیریآزمایشگاه مقصدثبت زمان رسیدن و انجاموضعیت‌های دقیق‌ترمستندسازی و عکس‌هاتحویل به آزمایشگاهدستمزد و پاداشآموزش متخصص
DESIGN PRINCIPLE«اطلاعات درست، در زمان درست، برای اجرای درست سرویس.»
06Sampler PWA / Product Views
ابزاری برای اجرای قابل‌ردیابی‌تر خدمت
از انتخاب درخواست تا ثبت خدمت و مستندسازی، در یک تجربه متصل.
HOMECA-SAMPLER-01-LISTلیست درخواست‌های قابل انجام
HOMECA-SAMPLER-02-DETAILجزئیات بیمار و سرویس
HOMECA-SAMPLER-03-EXECUTIONاجرا، مستندسازی و تحویل
SELECTED FLOW02 / 04
07Customer Panel
از لیست ساده سفارش‌ها به تجربه‌ای برای پیگیری کامل سرویس
پنل اولیه فهرست سفارش‌ها، وضعیت‌های کلی، مبلغ و پرداخت را نشان می‌داد؛ اما به سؤال‌های واقعی کاربر در طول دریافت سرویس پاسخ نمی‌داد.
مسئله اصلی
«سفارشم الان کجاست، مرحله بعد چیست و چه زمانی نتیجه را دریافت می‌کنم؟»
هویت و اطلاعات
ثبت سفارش برای خود یا دیگران، مدیریت افراد خانواده و آدرس‌ها، نگهداری اطلاعات برای دفعات بعد.
سفارش و Journey
وضعیت روشن‌تر، مرحله بعد، اطلاعات نمونه‌گیر، زمان تقریبی جواب و وضعیت نمونه‌های لجستیکی.
پرداخت و صورتحساب
نمایش مبلغ پرداخت‌شده، پرداخت سفارش، صورتحساب و کد تخفیف.
نتیجه و تفسیر
فایل PDF نتیجه، وضعیت آماده‌سازی و تفسیر متنی یا صوتی پزشک.
هدف طراحی
کاهش ابهام و ایجاد شفافیت بیشتر روی تمام Journey سرویس.
08Customer Panel / Product Views
هر سفارش، یک Journey قابل‌فهم و قابل‌پیگیری
اطلاعات مناسب در طول سفارش، از مرحله بعد تا نتیجه و تفسیر.
HOMECA-CUSTOMER-01-ORDERجزئیات سفارش و مرحله بعد
HOMECA-CUSTOMER-02-RESULTنتیجه و زمان جواب‌دهی
HOMECA-CUSTOMER-03-INTERPRETATIONتفسیر صوتی یا متنی پزشک
SELECTED FLOW03 / 04
09Physician PWA
خارج‌کردن Workflow پزشک از گروه‌های پیام‌رسان
در مدل اولیه، نسخه و کد رهگیری بین گروه پزشکان و تیم عملیات ردوبدل می‌شد؛ مسئولیت، زمان انجام و وضعیت واقعی کار روشن نبود.
قبل MESSENGER-BASED
- ارسال اطلاعات بیمار در گروه
- ثبت نسخه توسط پزشک
- Reply کد رهگیری در پیام‌رسان
- جست‌وجوی پیام توسط عملیات
- ورود دستی کد روی سفارش
بعد TASK-BASED
- ساخت خودکار Task
- Assignment و پیامک اطلاع‌رسانی
- مشاهده Context بیمار توسط پزشک
- ثبت نسخه یا تفسیر
- خروجی ساختاریافته در محصول
Prescription
اطلاعات بیمار، شرح حال، اقلام، کد رهگیری و PDF نسخه
Interpretation
نتیجه فعلی، سوابق قبلی، تفسیر صوتی و متنی
Operations
وضعیت، زمان‌سنج، صورتحساب ماهانه و آموزش
زمان کار عملیاتی برای هر نسخهحدود ۵ دقیقهکمتر از ۱ دقیقه
خطاهای تکرارشونده ناشی از گم‌شدن نسخه، انجام تکراری درخواست و Handling موازی عملاً حذف شدند.
SELECTED FLOW04 / 04
10Pricing & Automation
از Spreadsheet شکننده به منطق ساختاریافته داخل محصول
هر کارشناس با شیت‌های جداگانه هزینه آزمایش، بیمه و پوشش را حساب می‌کرد. پیچیدگی قواعد بیمه و تفاوت آزمایشگاه‌ها خروجی را آسیب‌پذیر کرده بود.
BEFORE 00
محاسبه در شیت‌ها
فرمول‌های شکننده، تفاوت خروجی کارشناسان، پوشش بیمه نامشخص و مغایرت احتمالی با هزینه آزمایشگاه.
VERSION 01
اقلام و قواعد در محصول
جست‌وجوی کد و نام آزمایش، بیمه، آزمایشگاه، پکیج، شرایط آمادگی، زمان جواب‌دهی و اتصال مستقیم به سفارش.
VERSION 02
زنجیره مالی متصل
اتصال اقلام سفارش به سهم کاربر، نمونه‌گیر، پزشک، آزمایشگاه، صورتحساب و تسویه؛ همراه با محاسبه مجدد وابستگی‌ها.
EXCEPTION HANDLING
برای موارد خاص، Supervisor امکان تغییر دستی داشت؛ اما وابستگی‌های مالی همچنان بر اساس تغییر جدید دوباره محاسبه می‌شدند.
زمان محاسبه و تکمیل هزینه هر درخواست
۵–۱۰ دقیقهکمتر از ۱–۳ دقیقه
بسته به پیچیدگی سفارش11Pricing & Automation / Product Logic
Business Ruleهایی که بخشی از خود محصول شدند
نکته مهم این جریان زیبایی ظاهری UI نبود؛ تبدیل وابستگی‌های واقعی کسب‌وکار به منطق قابل‌مدیریت داخل محصول بود.
COREOrderسفارش
Test Itemاقلام آزمایشInsuranceبیمهLabآزمایشگاهPackageپکیجTurnaroundزمان جواب‌دهیCostsهزینه‌هاPayoutsتسویه
HOMECA-PRICING-01-ESTIMATEاسکرین‌شات واقعی سیستم قیمت‌گذاریبا هر میزان قدمت UI، منطق واقعی محصول را نمایش دهید
12نتیجه
اثر یک Feature نبود؛ نتیجه تحول تدریجی کل محصول بود
تا حدود۲×
سفارش بیشتر
با
تقریباً½
ظرفیت عملیاتی قبلی
Prescription Handling۵ دقیقه ← کمتر از ۱ دقیقه
Pricing Workflow۵–۱۰ دقیقه ← کمتر از ۱–۳ دقیقه
تغییرهای کیفی QUALITATIVE OUTCOMES
- انتقال Workflowهای مهم از شیت‌ها و گروه‌ها به محصول
- Traceability بیشتر و داده‌های ساختاریافته‌تر
- وابستگی کمتر به Copy/Paste و پیگیری دستی
- امکان سنجش بهتر عملکرد فرایندها و متخصصان
- شفاف‌تر شدن پیگیری سفارش برای کاربر
یادداشت درباره انتساب نتایج این نتایج حاصل مجموعه‌ای از تغییرات محصول در طول چند سال هستند و به یک Feature یا Redesign منفرد نسبت داده نمی‌شوند.
14مرحله بعد / تصاویر محصول
نگاهی به مسیر یکپارچه‌سازی محصول
دو نمای منتخب از مسیر طراحی پیش از تغییر جهت محصول؛ زبان بصری مشترک و تجربه جدید وب‌سایت هومکا.
HOMECA-NEXT-01-WEBSITEتصویر بازطراحی وب‌سایتدر انتظار فایل اصلی تصویر دوم
15بازنگری
اگر امروز دوباره این مسئله را حل می‌کردم
بخش مهمی از یادگیری این تجربه، دیدن ارزش طراحی در کنار عملیات واقعی و محدودیت‌های توسعه بود.
آنچه خوب جواب داد WHAT WORKED
- ارتباط نزدیک با عملیات، پزشک و نمونه‌گیر
- مشاهده Workflow واقعی قبل از طراحی
- Prototype و Validation پیش از توسعه
- Iteration سریع با تیم فنی
- طراحی بر اساس محدودیت‌های واقعی
امروز متفاوت انجام می‌دادم WHAT I'D CHANGE
- Research Loop مستقیم‌تر با مشتری نهایی
- تعریف Metric پیش از انتشار
- Product Analytics ساختاریافته‌تر
- مستندسازی تصمیم‌ها و Baseline
- Design QA منظم‌تر و قابل‌تکرار
محدودیت مهم
تحقیق مستقیم با مشتری نهایی در آن دوره به اندازه‌ای که امروز ترجیح می‌دهم ساختاریافته نبود. بخش بزرگی از Discovery از عملیات، داده‌های تاریخی، پزشکان و نمونه‌گیرها به دست می‌آمد.
FINAL THOUGHT
این تجربه برای من نقطه‌ای بود که طراحی محصول از «طراحی Interface» به «طراحی سیستم و Workflow» تبدیل شد.
بازگشت به ابتدای کیس‌استادی