۱۱ مطلب با موضوع «مقالات :: مدیریت فناوری اطلاعات و تحول دیجیتال :: پلتفرم دیجیتال و طراحی نرم افزار» ثبت شده است

پلتفرم دیجیتال چیست؟

پلتفرم ها ارتباط نزدیکی با مفهوم اکوسیستم دارند. در پلتفرم ها مقرر است تمام نیازهای کاربران دیده شده و به آنها رسیدگی شود. اصلی ترین سوالات در هنگام طراحی پلتفرم که باید به آنها پاسخ داده شود شامل موارد زیر است:

• با چه هدفی؟: باید مشخص شود که پلتفرم قصد دارد در چه زمینه ای و برای چه مقصدی ساخته شود. مثلا ممکن است که یک پلتتفرم با هدف ارتباط کاربران طراحی شود (مثلا توییتر) یا برای انتقال دانش باشد (مثلا کورسرا) یا شبکه اشتراک گذاری ویدیو باشد (مثلا یوتوب) یا در زمینه خدمات دولتی فعالیت کند (پنجره الکترونیکی دولت) بنابراین هر پلتفرمی برای هدف خاص خودش طراحی می شود.
• برای چه کسانی؟: در طراحی پلتفرم باید به خصوصیات جامعه هدف توجه شود مثلا وقتی مقرر است بستری برای آموزش کودکان طراحی شود، باید از رابط کاربری آسان و دارای مشخصه های کودکانه استفاده شود.
• در چه شرایط بازاری؟: باید حتما بررسی شود که این پلتفرم برای نیاز مخاطبان چقدر لازم است و چه رقبایی در این بازار حضور دارند؟ آیا مخاطبین به نیاز به این پلتفرم را حس می کنند که از آن استقبال کنند و آیا توان رقابت در این بازار را داریم؟
• با چه نوع محتوایی؟: مشخص است که وقتی مقرر است پلتفرم آموزشی طراحی شود، باید امکان برگزاری آزمون، نمایش ویدیو، برگزاری کلاس آنلاین، و... را داشته باشد بنابراین باید از انواع محتوای متنی، صوتی، تصویری و استریم پشتیبانی کند.
• اقتصاد پلتفرم؟: بغیر از برخی پلتفرم ها که خدمات عمومی و دولتی ارائه می دهند، تمام انواع پلتفرم ها باید روشی برای کسب درآمد فرض کرده باشند که توجیه اقتصادی داشته باشد. (مثلا یوتوب از محل پخش تبلیغات درآمد کسب می کند). این مسئله شامل موارد زیر است:
  • الف: بودجه اولیه برای راه اندازی چقدر است؟
  • ب: هزینه های نگهداری چقدر است؟
  • ج: محل کسب درآمد و پلن درآمدی آن چیست؟
  • د: چه دوره ای طول می کشد تا پلتفرم به سوددهی برسد؟
  • ه: پیش بینی درآمد حاصله از پلتفرم چقدر است؟
• بر چه بستری؟: در حال حاضر بستری که استفاده از آن عمومیت دارد وب است زیرا محدودیتهایی مانند زبانهای مختلف برنامه نویسی، زیرساخت های پیچیده و شخصی سازی شده، هزینه نگهداری بالا، امکان ایرادیابی سخت، هزینه بسیار بالای گسترش، و... را ندارد
• در چه دوره ای؟: این مسئله شامل دو حوزه جداگانه می شود یعنی:
  • الف: پلتفرم تا چه زمانی راه اندازی شود؟
  • ب: پلتفرم تا چه زمانی فعالیت داشته باشد؟
• برنامه گسترش؟: چنانچه قبلا اهدافی برای طراحی پلتفرم در نظر گرفته شده باشد، چگونه و در چه تاریخی قرار است این گسترش صورت پذیرد
• برنامه نگهداری؟: در حال حاضر سعی می شود که پلتفرم به نحوی طراحی شود که نیاز به حداقل دخالت کاربر جهت نگداری داشته باشد اما در هر حالت باید فکری برای نگهداری از آن اندیشید و هزینه های آنرا محاسبه نمود.
• بهبود مستمر؟: آیا برنامه ای برای رفع مشکلات احتمالی و یا اصلاح رابط و تجربه کاربری UI/UX وجود دارد یا خیر؟
• آموزش پلتفرم؟: برای هر پلتفرمی لازم است که برنامه ی آموزشی مشتریان در نظر گرفته شود. با وجود آنکه استفاده از پلتفرم باید در نهایت سادگی انجام شود اما همیشه مشتریانی هستند که نیاز به آموزش و راهنمایی دارند. برای این دسته از مشتریان باید محتوای ویدیویی، صوتی، متنی، FAQ یا پرسشهای متداول، کلاس آموزشی، و یا مشاوره تلفنی درنظر گرفت.
• با چه رابط کاربری؟: در هنگام طراحی رابط کاربری، علاوه بر تمام مواردی که بالا گفته شد لازم است به جنبه های مختلف مانند هویت برند، علاقمندی های مشتریان هدف، قوانین جاری و هنجارهای اجتماعی و... نیز پرداخته شود.
• با چه الگوریتمی؟: توجه به الگوریتم های محاسباتی مانند پروتکل های امنیت اطلاعات، محرمانگی داده های کاربران، محاسبات داخلی سرور و... باید مورد توجه قرار گرفته و برای آنها راهکارهای قابل اعتمادی اندیشیده شده باشد.
• بر اساس چه الگویی؟: در بسیاری از موارد، همیشه مجموعه های دیگری هستند که پلتفرمی با شباهت هایی به آنچه که ما  مدنظر داریم ساخته باشند. مثلا ما قصد داریم پلتفرم فروش املاک بسازیم اما شرکتی دیگر قبلا پلتفرمی برای فروش بلیط هواپیما ساخته یا شرکتی دیگر همین پلتفرم را در کشوری دیگر پیاده سازی کرده است. مشخص است که می توان از تجربیات ایشان با هزینه ای بسیار پایینتر از تحقیقات استفاده کرد.(مثلا استفاده از تجربه پلتفرم اوبر در راه اندازی پلتفرم اسنپ)
• با چه عامل تحریک کننده ای؟: در زمانی که استفاده از پلتفرم برای بازار جدید بوده و یا رقبایی در این بازار حضور داشته باشند، باید حتما چیزی برای جذب کاربران وجود داشته باشد. مثلا برخی از شرکت های حمل و نقل به کاربران جدید تخفیف می دهند و یا برخی شرکتهای مخابراتی به محض خرید سیمکارت، هدیه ای به کاربر اعطا می کنند که از شبکه مخابراتی آنها استفاده کرده اند.
• بعد از انجام تمام مراحل فوق، می توان از الگوی اسکرام برای ساخت پلتفرم استفاده کرد.

بر اساس نظریات: زیسمن، کارستن، کاله، کوهن، جوست، سرینیواسان، شوشانا

سند موضوع درخواست (RFP) در تولید نرم افزار

تعریف RFP در صنایع مختلف متفاوت است و معمولا شامل مستندات و اسنادی می شود که کارفرما به پیمانکار اعلام می دارد تا آنچه که ساخته می شود با نیازهای کارفرما همخوانی داشته باشد. گاهی سند RFP با این هدف تهیه می شود که بر اساس آن مناقصه برگزار شده و پیمانکار انتخاب شود. اما معمولا RFP در طراحی نرم افزار شامل اشاراتی به شرح نیاز و مشخصه های ظاهری رابط کاربری نیز می شود که مهمترین موارد آن به شرح زیر است:

1. بیان واضح و کافی نیاز سازمان که هرچه کاملتر باشد بهتر است.
2. مشخص کردن سطوح دسترسی کاربران و گاهی مشتریان به بخشهای مختلف نرم افزار.
3. مشخصه های نیاز سازمان در قالب اسناد تصویری (رسم کردن حدودی محیط کاربری بر روی کاغذ).
4. شرح عملیات و فرایند داخلی نرم افزار که مورد نیاز سازمان است بوسیله فلوچارت.
5. مشخص کردن نیازهای مدیریتی در پنل اصلی نرم افزار بهمراه مشخصه های ظاهری آن.

توجه: تنظیم سند RFP بسیار مهم است زیرا ممکن است پیمانکار بر اساس توضیحات ناقص کارفرما اقدام به طراحی نرم افزار و رابط کاربری کند اما محصول نهایی با انتظارات کارفرما مغایرت داشته باشد. در این حالت، احتمالا پیمانکار برای اصلاح نرم افزار تقاضای وجه خواهد کرد (زیرا اشتباه از ناحیه کارفرما بوده که توضیحات کافی را ارائه نکرده است).

بر اساس نظریات: لایتنر، فالک، نگوین، هویزینگا، راملر، کوپتسکی، گلپرین

الگوی اسکرام چیست و اسکرام مستر کیست؟

الگوی اسکرام برای چابک سازی توسعه نرم افزاری استفاده می شود اما می توان از این الگو برای سایر زمینه ها مانند بازاریابی، فروش، توسعه محصول، تحقیق و توسعه، تولید و... نیز استفاده نمود.الگوی اسکرام دارای خاستگاه ژاپنی است که تاکید فراوانی بر عملکرد تیمی دارد. الگوی اسکرام شامل مراحل زیر است:

• تعریف ابتدایی اسکرام: در ابتدا برنامه ریزی و تعیین پروژه مطابق تمام آنچه که در مدیریت استراتژیک، تعیین هدف، نقشه راه و... بیان شده است توسط کارفرما انجام می شود (طراحی ابتدایی پروژه). درواقع در این مرحله، کارفرما باید به نتیجه برسد که چرا و برای انجام چه کاری نیاز به نرم افزار دارد.
• ترکیب تیم اسکرام: شامل نماینده کارفرما، اسکرام مستر، و توسعه دهندگان خواهد بود که در ادامه به هرکدام پرداخته می شود:
  • الف- نماینده کارفرما: یک نفر بعنوان نماینده کارفرما مشخص می شود (فرض کنید که یک شرکت نیاز به نرم افزار داشته و به شرکتی که طراح نرم افزار است سفارش داده باشد. در این حالت باید نماینده کارفرما مشخص شده و در گروه حضور داشته باشد). هرگز این شخص نباید همان اسکرام مستر باشد. نماینده پیمانکار باید توانایی تنظیم RFP (سندی که شرح نیازها و راهکار رفع نیاز در آن بصورت دقیق ذکر شده است) را داشته باشد یعنی بتواند شرح نیاز (که معمولا متناسب با نیازهای کسب و کار است) را به صورت کامل و واضح به تیم اجرایی بگوید تا آنها بدانند که چه چیزی را باید فراهم کنند بنابراین نماینده پیمانکار باید حتما دانش کافی در دو حوزه تجارت شرکت و فنی را بصورت همزمان داشته باشد. این شخص باید به خوبی از ریسک ها، موانع، نیازهای وابسته با یکدیگر، و ملزومات غیر قابل چشم پوشی اطلاع داشته باشد.
  • ب- توسعه دهندگان: که شامل تمام افرادی است که در زمینه فنی فعالیت می کنند مانند معمار نرم افزار، برنامه نویسان، طراحان گرافیک و... که همگی زیر نظر اسکرام مستر فعالیت می کنند. این تیم باید حتما دارای دانش فنی کافی در هرکدام از حوزه هایی که مربوط به پروژه است باشند.
  • ج- اسکرام مستر: یک نفر متخصص که اصطلاحا اسکرام مستر نامیده می شود، بعنوان مسئول اجرای پروژه تعیین می گردد. این شخص باید مشخصاتی مانند: دانش مدیریت تیم اجرایی و پروژه، دانش فنی کافی، امکان ارائه راهکار، تنظیم برنامه و فازهای زمان بندی، رفع موانع، سنجش شاخص های پیشرفت پروژه، ارائه مشاوره به کارفرما جهت حل نیازها، تجربه اجرایی در مدیریت تیم، توانایی آموزش دادن و مربیگری، را داشته باشد تا بتواند تیم را راهنمایی کند. توجه شود که اسکرام مستر همان مدیر پروژه نیست زیرا در اسکرام از قابلیت خود سازمان دهی استفاده می شود و اختیار عمل با توسعه دهندگان است (زیرا ممکن است دانش فنی توسعه دهندگان در حوزه های مختلف فنی بسیار بیشتر از اسکرام مستر باشد و راهکارهای اجرایی بهتری سراغ داشته باشند که در صورت دیکته شدن یک عملکرد، نتوانند از آن راهکارها استفاده کنند.) درواقع اسکرام مستر باید نتیجه را مدنظر داشته باشد نه روش اجرا را.
• مراحل اجرای اسکرام: فاز های اجرایی به دوره هایی بین 15 روز الی یک ماه تقسیم می شود که به هرکدام از این فازها اسپرینت گفته می شود. (هرچه زمان فرض شده برای فازهای اجرایی کوتاه تر باشد، چابک سازی بیشتری انجام شده است) در برنامه ریزی فازها یا اسپرینت به موارد زیر توجه می شود:
  • الف: در جلسه ای که توسط توسعه دهندگان و اسکرام مستر برگزار می شود، فاز های اجرایی پروژه بر اساس واقعیات تبیین می شود و سپس آنرا به نماینده کارفرما اطلاع می دهند. در این مرحله باید احتمال بروز مشکلات و اهمیت هرکدام بررسی و امتیاز دهی شوند که از 1 تا 10 متفاوت است. هرچه این امتیاز بالاتر باشد، اهمیت آن مشکل جدی تر می شود. سپس زمان احتمالی تحویل پروژه بعلاوه 10% الی 30% بیشتر به اطلاع کارفرما میرسد. (هرچه تجربه تیم در انجام آن کار و شناخت ایشان از یکدیگر بیشتر باشد، این زمان کاهش می یابد). مثلا می گویند که جمع آوری مستندات و معماری نرم افزار 10 روز، کدنویسی 20 روز، پیاده سازی 5 روز، تست و دیباگ 10 روز، جمعا 45 روز. تعیین اسپرینت ها بر عهده اسکرام مستر است که در جلسه ای با حضور توسعه دهندگان انجام می شود.
  • ب: حالا مراحل فوق به زیربرنامه هایی باتوجه به نظر فنی توسعه دهندگان تقسیم شده و برای هر مرحله شاخص هایی قابل اندازه گیری تعریف می شود. حداکثر زمان برنامه ریزی ابتدایی برای یک اسپرینت که قرار است چهار هفته طول بکشد هشت ساعت است.در مراحل طراحی یا اجرای اسپرینت ممکن است اسکرام مستر به این نتیجه برسد که هر فاز از اسپرینت ها نیاز به دانش خاص یا تعداد خاصی از توسعه دهندگان دارد. درواقع سرعت انجام اسپرینت ها وابسته به توانایی توسعه دهندگان است. مثلا اسکرام مستر تعیین می کند که یک اسپرینت نیاز به 100 نفرساعت کار دارد و اگر دو توسعه دهنده در اختیار داشته باشد، می تواند در عرض یک هفته آن اسپرینت را به پایان برساند. پس از پایان بررسی ها، اسپرینت ها به اطلاع نماینده کارفرما میرسد تا او با توجه به اولویت های کسب و کار انتخاب کند که چه مواردی اولویت بیشتری دارند.
  • ج: موارد عقب مانده از برنامه در جلسات 15 دقیقه ای که ابتدای هر روز تشکیل می شود، لیست شده و در همان جلسه تصمیم گرفته می شود که چه راهکاری برای رسیدن به برنامه مورد نیاز است. این جلسات باید هر روز و بصورت منظم برگزار شوند و از 15 دقیق تجاوز نکند. فراموش نشود که این جلسات محل بحث نیست و مشکلاتی که مطرح می شود بصورت فردی بین یکی از توسعه دهندگان و اسکرام مستر بررسی می شود تا سایر اعضا از برنامه روزانه خود عقب نمانند.
  • د: اگر تیم اجرایی (شامل توسعه دهندگان و اسکرام مستر) به این نتیجه برسند که مشکلی غیر قابل پیشبینی رخ داده است، تغییر در زمان تحویل را به نماینده کارفرما اطلاع می دهند. بهتر است قبلا احتمال تغییر در زمان تحویل (با درج زمان مشخص مثلا ذکر شود که 10 روز تاخیر در تحویل مجاز است) در قرارداد فیمابین ذکر شده باشد تا باعث نارضایتی کارفرما نشود.
  • ه: در هر جلسه روزانه اگر ایرادی در اجرای برنامه شناسایی شود، اهمیتی ندارد که دلیل بروز آن چیست (چون بروز ایراد اجتناب ناپذیر است و تمرکز بر شناسایی مقصر یا دلیل ایراد صرفا باعث هدر رفتن زمان می شود) اما باید راهکاری برای حل آن از طریق اظهار نظر تمام اعضا انتخاب شود.
  • و: در پایان هرکدام از اسپرینت ها، بررسی می شود که چه چیزهایی خوب پیش رفت؟، چه مواردی خوب پیش نرفت؟، دلایل هرکدام چیست؟، راهکار برای حل هرکدام چیست؟ چگونه می توان سرعت و کیفیت اجرا را ارتقا بخشید؟. در اینجا باید فرایند بهبود مستمر پیاده سازی شود تا بتوان از بروز مشکلات در اسپرینت های بعدی اجتناب کرد.
• اجرای بک لاگ: ممکن است در پایان و یا اجرای هر اسپرینت مشخص شود که نیاز است اسپرینت های جدیدی تعریف شده و یا اسپرینت های قبلی به چند اسپرینت تقسیم شوند. همچنین ممکن است اصلاح نیازهای اعلامی کارفرما در حد یک پروژه جدید نباشد اما بقدری باشد که نیاز به تعریف اسپرینت های جدید شود. در این حالت باید تغییر زمان تحویل و تغییر هزینه نهایی به کارفرما اطلاع داده شود و در صورت توافق طرفین، اسپرینت های جدیدی تعریف شوند. حتی ممکن است در حین اجرای اسکرام، کارفرما به این نتیجه برسد که دیگر نیازی به برخی از اسپرینت ها ندارد بنابراین می توان آنها را لغو  و مجددا برنامه ریزی اسپرینت ها را انجام داد. همچنین ممکن است تاخیر در اجرای برخی اسپرینت ها آنقدر زیاد و جدی باشد که لازم باشد قبل از شروع اسپرینت جدید، ابتدا به آنها رسیدگی شود. تشخیص تمام این موارد بر عهده اسکرام مستر است.
• پایان اسکرام: در پایان پروژه، دو جلسه برای ذینفعان برگزار شده و به بررسی موارد زیر پرداخته می شود:
  • الف: بررسی می شود که آیا آنچه که ساخته شده متناسب با نیاز اولیه که اعلام شده بود است یا خیر. اگر متناسب نباشد، برنامه اصلاحی برای اسکرام تعیین می شود.
  • ب: ممکن است کارفرما به این نتیجه برسد که نیاز به قابلیت های جدیدی در نرم افزار دارد که قبلا بیان نکرده است. در این صورت باید یک اسکرام جدید تعریف شود.
  • ج: تمام آنچه که انجام شده است و مستندات آن در اختیار کارفرما و پیمانکار قرار می گیرد تا بتوانند در فازهای بعدی گسترش نرم افزار از آن استفاده کنند.
  • د: مدتی برای بررسی محصول نهایی تحت عنوان دوره ی تست محصول تعیین می شود در این دوره، کارفرما اقدام به تست محصول می کند و ایرادات احتمالی را به اسکرام مستر می گوید تا توسعه دهندگان رفع کنند. پس از رفع تمام نقایص، پایان اسکرام اعلام می شود.
    
    

محدودیت های اسکرام:

جدی ترین محدودیتهای تیم های اسکرام معمولا شامل موارد زیر است:

1. فاصله جغرافیایی
2. در تیم های با اعضای بسیار متخصص نیاز است که این اعضا درمورد فعالیت در سایر شاخه ها نیز تشویق شوند.
3. وقتی اسکرام در بین چند گروه تقسیم شده است، هماهنگی این گروه ها ممکن است سخت باشد. در این زمان می توان از الگوی اسکرام-اسکرام استفاده کرد یعنی از هر اسکرام، نماینده ای در سطح بالاتر وجود داشته باشد. مثلا فرض کنیم که چهار تیم هرکدام به یک اسکرام مشغولند ولی در همگی شامل یک پروژه می شوند. در این زمان باید از هر تیم یک نماینده در اسکرام اصلی حضور داشته باشند و به صورت روزانه همان مراحلی که در اسکرام انجام می شود را انجام دهند تا چهار گروه با یکدیگر هماهنگ باشند.
4. در مواردی که محصول نهایی دارای تست های پیچیده است (مانند نرم افزار های پزشکی)

بر اساس نظریات: شوبر، تاکوچی، نوناکا، ساترلند، اسلیگر، هیروتاکا، شوابر، جانسون، گونتر ورهین، ماکسیمینی

مدل و بوم کانبان (مرتبط با اسکرام)

کانبان یک تعریف تخصصی و کاربردی در مدیریت پروژه در زبان ژاپنی است که الگوی آن از مدل تویوتا اقتباس شده است. صرفنظر از تعاریف آکادمیک، از بوم کانبان جهت مدیریت زمان، سرمایه انسانی، دارایی ها، و رفع موانع در تولید (خصوصا طراحی و تولید نرم افزار) استفاده می شود که قابلیت بالایی در تلفیق با الگوی اسکرام دارد. شکل و مراحل استفاده از تخته ی کانبان بصورت زیر است:

1. بر روی یک تخته یا بوم، تمام کارهایی که باید انجام شود را با توجه به اولویت زمانی که باید انجام شود ، از راست به چپ می نویسیم (انگلیسی زبانها از چپ به راست)
2. برای هرکدام یک متولی و زمان اجرا مشخص می کنیم (مثلا آقای باقری تا 31 خردادماه)
3. مشخص می کنیم که آن کار در چه مرحله ای از پیشرفت است (مثلا 65% پیشرفت)
4. اگر مشکلی در اجرای کار وجود دارد، در کنار آن می نویسیم (مثلا در یک پروژه ساختمانی: نتایج آزمایشگاه مصالح هنوز نیامده است)
5. برای رفع مشکل نیز مسئول و زمان مشخص می کنیم ( مثلا آقای اکبری تا 10 خرداد نتایج را از آزمایشگاه می گیرد)
6. مراحل بعدی که وابسته به مراحل قبلی است را مشخص می کنیم (مثلا بتون ریزی مستلزم آرماتوربندی است) توجه شود که ممکن است برخی از مراحل وابسته به چند کار مختلف در مراحل قبلی باشد.
7. تمام مراحل و کارهایی که انجام می شوند را مستندسازی می کنیم تا بعدا قابل استفاده باشند.

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

بر اساس نظریات: ووماک، اوهنو، لاداس، راینرتسن، بنسون، کالتنهکر

رابط کاربری UI چیست؟

نامهای دیگر: رابط انسان و ماشین – رابط انسان و کامپیوتر

به هر نوع محیطی که برای استفاده انسان از هر نوع ابزار طراحی می شود، رابط کاربری می گویند بنابراین محدود به انواع دیجیتالی نمی شود (مثلا حتی در طراحی یک صندلی نیز می توان به جنبه هایی از رابط کاربری توجه کرد) اما در این گفتار، اشاره به رابط کاربری دیجیتال است. اهداف طراحی رابط کاربری دیجیتال شامل موارد زیر است:

1. در آن بتوان از تمام قابلیت های سیستم-ماشین استفاده کرد.
2. نیاز نباشد که کاربر برای استفاده از آن به اصول برنامه نویسی و زبان ماشین آشنایی داشته باشد.
3. دارای محیط کاربرپسند باشد.
4. استفاده از آن آسان باشد.

رابط های کاربری ممکن است برای اهداف مختلفی طراحی شوند اما مهمترین پارامتر در طراحی آن، راحت بودن کاربر عادی که هیچگونه تخصصی ندارد در استفاده است. انواع راب های کاربری شامل موارد زیر است:

1. سیستم های عامل مانند ویندوز و لینوکس و  اندروید
2. برنامه های کاربردی مانند آفیس و هر برنامه دیگری که کاربر با آن ارتباط دارد
3. سامانه های مبتنی بر بستر وب مانند سایتها و پورتال ها
4. سیستم های کاربری صنعتی مانند کنترل دستگاه های CNC
5. سیستم های کنترل لوازم خانگی مثلا پنل یخچال یا ماکروفر
6. هر نوع سیستم دیجیتالی دیگر

رابط های کاربری می توانند دارای انواع مختلفی برای ارتباط با انسان باشند مثلا:

1. رابط بینایی: هر چیزی که از راه بینایی با انسان ارتباط برقرار می کند مانند مانیتور، تلویزیون، پرینتر، موبایل و...
2. رابط شنوایی: معروفترین رابط های کاربری شنیداری را می توان دستیار صوتی مانند کورتانا، سیری، و دستیار صوتی گوگل دانست.
3. رابط لمسی: از این نوع رابط ها معمولا برای استفاده افراد نابینا استفاده می شود.
4. رابط ترکیبی: که از چند نوع ابزار ارتباطی استفاده می کنند (مانند کنسول های بازی که صدا و تصویر را از طریق باندها و نمایشگر به کاربر انتقال می دهند و حس لامسه از طریق دسته های بازی که ویبراتور دارند)
5. رابط کامل: به تازگی سعی شده رابط هایی طراحی شوند که با تمام حواس انسان ارتباط داشته باشد و در آن از فناوری هایی مانند واقعیت مجازی استفاده می شود.
6. ذکر این موضوع لازم است که اگر قرار باشد این ارتباط به صورت دوطرفه باشد (یعنی کاربر نیز اطلاعات و ورودی های سیستم را از طریق عوامل دیداری، شنیداری یا لمسی به ماشین وارد کند) لازم است که از انواع هوش مصنوعی استفاده شود.

بر اساس نظریات: کوهن، مارس، باستون، گریفین، وسیاس، سیگل، بردول، سیتی، جردن، ریچارد، هاردینگ

مراحل طراحی رابط کاربری (مرتبط با UI)

1. ابتدا کلیه اهدافی که از آن رابط کاربری انتظار می رود را لیست می کنیم.
2. مراحل طراحی برند باید قبل از شروع طراحی رابط کاربری به پایان رسیده و اسناد برند موجود باشد تا در هنگام طراحی رابط کاربری از آن استفاده شود (رابط کاربری مطابق هویت برند طراحی شود)
3. لازم است حتما آن رابط کاربری متناسب با سلایق کاربران و دارای مزیت رقابتی نسبت به رقبا طراحی شود بنابراین باید حتما قبل از طراحی رابط کاربری، تحقیقات جامعی درمورد بازار انجام شده و اسناد آن در زمان شروع طراحی موجود باشد.
4. در هر مرحله سعی می شود که رابط کاربری قابل استفاده برای کودکان باشد (یعنی آنقدر آسان باشد که کودکان هم بتوانند بدون کوچکترین مشکل از تمام قابلیت های آن استفاده کنند). طراحی رابط برای کودکان یک اصل اساسی است.
5. محل ورود کاربر به این رابط و تمام مراحل تعامل او با محیط را رسم می کنیم.
6. سپس تمام مراحل گردش کار در محیط را رسم می کنیم (رسم سناریو).
7. در هر نقطه که لازم است فرایند خاصی رخ دهد (مثلا ارجاع اطلاعات در بانک اطلاعاتی و...) را مشخص می کنیم.
8. بسیار مهم است که در طراحی رابط کاربری به عوامل زیبایی شناختی مانند روانشناسی رنگها و اصول دیداری توجه شود. بهترین راه برای تسریع این مورد آن است که رابط های کاربری قدرتمند و محبوب در همان حوزه را آنالیز کنیم.
9. هرگونه پارامتر ابهام انگیز در هنگام استفاده از محیط کاربری را شناسایی و رفع می کنیم (بهترین راه برای شناسایی نکات مبهم این است که رابط کاربری توسط برخی کاربران به صورت مستقیم تست شود). مهمترین راهکار برای رفع ابهامات در محیط کاربری شامل: استفاده از توضیحات در کنار آبجکت ها، آماده سازی دفترچه راهنمای آموزشی، استفاده از آیکونهای با معنی استاندارد (مثلا آیکون خروج همیشه یکسان است)، استفاده از رنگ (مثلا رنگ قرمز به عنوان اخطار استفاده می شود)، تفکیک مولفه های مرتبط با یکدیگر در چند دسته بندی، و... است.
10. تا جایی که ممکن است محیط رابط کاربری را از وجود پارامترهای بی اهمیت خلوت می کنیم. این خلوت سازی شامل محیط گرافیکی (محیط کاربری نباید بسیار شلوغ و گمراه کننده باشد)، کاهش اطلاعات ورودی (نیاز به دریافت اطلاعات بی اهمت نیست)، و خلاصه سازی اطلاعات خروجی (نیاز نیست گزارشات تفصیلی با اطلاعات بی اهمیت ارائه شود) می گردد.
11. در طراحی رابط کاربری، تا جای ممکن باید انجام کار توسط ماشین انجام شود. مثلا چنانچه نرم افزار ما به سامانه ثبت احوال متصل شود، می تواند اطلاعات کاربران را صرفا با وارد کردن یک کد ملی از بانک اطلاعاتی ثبت احوال دریافت کند و دیگر نیاز نیست که کاربر تمام اطلاعات را وارد کند.
12. طراحی رابط کاربری برای پنل مدیریتی نیز بسیار مهم است و باید سعی شود که پنل مدیریت نرم افزار نیز بسیار آسان باشد به نحوی که نیاز به تخصص های پیچیده برای نگهداری از نرم افزار نباشد. (پنل مدیریتی نیز برای استفاده توسط کودک طراحی شود).
13. زمان انجام کارها در رابط کاربری را برای کاربران جدید بررسی می کنیم. یک محیط کاربری خوب هرگز نباید انجام کارها را طولانی تر از آنچه که قبلا انجام می شده کند از این جهت لازم است ابتدا انتظارات عملکردی کارکنان از سیستم و زمان انجام هر عملکرد در حالت عادی به صورت کامل گردآوری شود. محیط کاربری باید تا جای ممکن اصلاح شود که زمان انجام کارها را کوتاه تر کند.
14. هرگز نباید رابط کاربری در طول یک فرایند از نظر ظاهری و عملکردی تغییر کند زیرا همین تغییر باعث می شود انجام فرایند برای کاربر سخت شده و سرعت انجام کار در آن کاهش یابد. اگر محیط کاربری در طول یک فرایند تغییر می کند، باید اصلاح و یکسان سازی شود.
15. بهترین نوع رابط کاربری آن است که کاربر بتواند آنرا به سادگی برای خود سفارشی سازی کند.
16. در پایان تا جایی که می توانیم، همین چرخه را آسانتر و آسانتر می کنیم تا حدی که بیشتر از آن ممکن نباشد.
17. در طراحی رابط کاربری باید ابزارهای ذخیره لاگ فرض شده باشد (یعنی خطاهای سیستمی بصورت منظم در یک بانک اطلاعاتی ذخیره شود تا بتوان در آپدیت های بعدی اصلاح کرد). توجه شود که سیستم لاگ نویسی باید آنقدر ساده باشد که اپراتور با دانش سطحی بتواند ایراد را تشخیص دهد.
18. پس از پایان طراحی رابط کاربری، لازم است بررسی شود که تمام نیازهای اولیه تامین شده باشد.
19. یکی از مهمترین تست هایی که باید برای برنامه انجام شود، امنیت اطلاعات و امنیت کاربران و سطح دسترسی ایشان است. این موارد باید حتما از طریق لیست هایی که قبلا به همین منظور تهیه شده اند در هنگام طراحی رعایت شده باشد.
20. اگر قصد داریم یک رابط کاربری را آپدیت یا اصلاح کنیم، باید به عادتهای کاربران به ظاهر فعلی توجه کنیم و از ایجاد تغییر جدی در آن پرهیز کنیم تا کاربرانی که به محیط عادت کرده اند اذیت نشوند.
21. مرحله نهایی که بسیار مهم است این است که رابط کاربری و برنامه توسط جمعی از کاربران تست شود و بررسی شود که آیا برنامه را ارزشمند می دانند یا خیر.
22. چنانچه مقرر است که برنامه توسط افرادی که معلولیت هایی دارند نیز استفاده شود، باید برای ایشان نیز رابط کاربری مناسبی اندیشیده شود.
23. اگر در طراحی رابط کاربری از عبارات ناواضح، گنگ، یا گمراه کننده استفاده شده است (و یا در جایی نیاز به ضوتیحات حس می شود)، باید محیط به قدری واضح سازی شود که نیاز به راهنمایی کاربران نباشد. یکی از بهترین راه ها آن است که با توجه به فیدبک های مخاطبین، ساختار رابط کاربری اصلاح شود بنابراین، اصلاح رابط کاربری یک فرایند همیشگی است.

توجه: نه تنها در طراحی رابط کاربری بلکه در تمام مراحل ساخت برنامه باید از کدهای استاندادرد و زبانهای برنامه نویسی مرسوم استفاده شود تا چنانچه لازم باشد که نرم افزار اصلاح یا گسترش داده شود، بتوان این کار را به آسانی و بدون وابستگی به یک شخص خاص انجام داد.

بر اساس نظریات: اریک استیون، گرین، بیلینگهارست، سویت، ساتزینگر، راسکین، اودل، نورمن، نیلسن، نورمن، راث، ولف، بلاندفورد، هولتزبلات

سند مشخصات رابط کاربری UIS (مرتبط با UI)

در این سند تمام  مولفه ها مرتبط با طراحی رابط کاربری به صورت بسیار دقیق و با جزئیات کامل ذخیره می شود تا چنانچه تیم دیگری بخواهد نرم افزار را عیب یابی، آپدیت، یا گسترش دهد بتواند از آن استفاده کند. مهمترین مشخصه های سند UIS شامل موارد زیر است:

1. طراحی های دستنویس ظاهری رابط کاربری که در قبل از اجرا تنظیم شده اند.
2. توضیحاتی که درمورد اقدامات انجام شده در هرکدام از بخشهای رابط گرافیکی اجرا شده است.
3. فازهای اجرایی به همراه شرح اقدامات در هر مرحله.
4. لیست خطاهایی که در زمان طراحی نرم افزار شناسایی شده و رفع گردیده است.
5. اعلام مسائل باقیمانده که در این فاز از طراحی رابط کاربری به پایان نرسیده اند (مثلا طراحی و اجرای یکی از ابزارها به فازهای توسعه موکول شده است)
6. هرکدام از تغییرات یا اقداماتی که در هرکدام از فازهای طراحی و اجرا رخ داده است با ذکر تاریخ
7. ترسیم نقشه ی جریان منطقی (فرض کنید که یک رابط کاربری از چندین فرم تشکیل شده باشد. در این زمان باید ارتباط فرم ها و ارتباطات بین آنها در سندی مشخص شده باشد که اصطلاحا به آن BluePrint نیز گفته می شود.)

بر اساس نظریات: لیبرمن، سلکر، مارتینز، بره، ارت، اودل، ساتزینگر

تجربه کاربری UX چیست؟

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

بر اساس نظریات: نیلسن، لاو، وینسلو تیلور، فورد، نورمن، کورت، بولی، کانیاوسکی، بری، مکلافلین

داستان کاربر (زیرمجموعه UX)

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

1. اصلی ترین اهداف کاربر در استفاده از نرم افزار از طریق فرم های نظرسنجی مشخص می شود (مثلا کاربر قصد دارد در یک دوره آموزشی شرکت کند، یا آزمون بدهد).
2. تمام عملکرد کاربر در تمام مراحل استفاده از نصب گرفته تا استفاده از نرم افزار مشاهده و مستندسازی می شود.
3. نقاطی که کاربر در آنها گیر می کند و یا واکنش نامناسبی دارد، و همچنین زمان آنکه کاربر بتواند کاری که می خواهد را انجام دهد یادداشت می شود.
4. در پایان از کاربر پرسیده می شود که چقدر به اهداف خود رسید و چقدر رضایت دارد.
5. این آزمایش بر روی چندین کاربر انجام می شود (اگر قبلا ابزارهایی در نرم افزار برای سنجش این موارد فرض شده باشد، حتی می توان بدون اطلاع کاربر نیز پایش را انجام داد تا رفتار کاربران را فهمید که البته باز هم شامل احساسات کاربر نشده و لازم است از خودشان پرسیده شود).
6. حالا با توجه به داده هایی که کسب شده است، رفتارهای اصلی، اساسی، و فراگیر کاربران را بر روی بردار زمانی مشخص کرده و کل داستان کاربر را به بخشهای مختلفی تقسیم می کنیم. (هرچه تعداد این بخشها بیشتر باشد، دقت داستان کاربر بیشتر است اما باید دقت کرد که درگیر انبساط بیش از حد داستان نشویم)
7. حالا ایرادات، بنبست ها، و زمانهایی که کاربران در هرکدام از مراحل داشته اند را در بخشهای مشخص شده می نویسیم.
8. در مرحله نهایی سعی می کنیم ایرادات را رفع کرده و هدررفت زمان کاربران در هر مرحله را کمتر کنیم.
9. این چرخه تا رفع تمام نقایص ادامه دارد و وابسته به رضایتمندی حداکثری کاربران است یعنی هر بار که مشکلی توسط کاربران گزارش شد، لازم است مجددا بر روی بورد نوشته شود

بر اساس نظریات: دیمیتریویچ، یووانوویچ، رالف، بک، جفریس، کون، فاولر، پاتون، برینکمپر

مراحل طراحی تجربه کاربری (زیرمجموعه UX)

به شرح زیر است

الف: سند عناصر طراحی تجربه کاربری:

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

1. طراحی بصری UX: که شامل قواعد طراحی رابط کاربری UI می شود و بر روانشناسی گشتالت و قونین ادراک بصری استوار است. (به صورت جداگانه بیان شده است)
2. معماری اطلاعات: نیاز به تحقیق دارد
3. طراحی تعاملی UX: که عموما تمرکز بر استفاده از فیدبک های کاربران در طراحی یک نرم افزار دارد. این می تواند شامل دانش قبلی در این زمینه و همچنین جمع آوری فیدبک از کاربران فعلی جهت اصلاح نرم افزار شود. یکی از مهمترین رویردها در طراحی تعاملی شامل «طراحی کاربرمحور» می شود که جداگانه بیان می شود.
4. کاربردپذیری UX: این مورد شامل تکنیک های متعددی است که جداگانه بیان می شود.
5. دسترسی: این بخش تمرکز بر منحنی یادگیری دارد که در بیان خلاصه یعنی: کاربر برای استفاده از نرم افزار نیاز به یادگیری نداشته باشد و یا حداقل راهنمایی لازم باشد.
6. پرسونای مخاطب: لازم است تحقیقاتی درمورد شناخت شخصیت کاربران هدف انجام شده و نرم افزار مطابق آن طراحی شود. در هنگام طراحی پرسونا، به عواملی مانند کهن الگو ها، ریشه های فرهنگی، نحوه تصمیم گیری، علایق مخاطب، چیزهایی که کاربر از آن متنفر است، چیزهایی که باعث لذت یا آزار مخاطب می شود، جبهه گیری های سیاسی و اجتماعی و... پرداخته می شود و هرچه دقیقتر باشد، طراحی بهتری انجام خواهد شد.

ب: طراحی وایرفریم:

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

ج: تست تجربه کاربری:

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

1. تست قابلیت استفاده
2. تست A &B (یعنی مقایسه راه های مختلف برای انجام یک کار)
3. تست ساختار معماری اطلاعات
4. تست نقشه نرم افزار و جریان کاربر
5. بررسی لاگ های سیستم درمورد ایرادات ثبت شده
6. بررسی سناریوها درمورد اتفاقاتی که احتمال می رود رخ دهند
7. ترسیم داستان کاربر

بر اساس نظریات: نیلسن، هلتزبلات، مرهولز، گرت، لوگرن، مارکوس، باترز، کوپر، رایمان، نوسل، تردر، کیس، لوئر، برومبرگر، باکستر، کین

طراحی کاربرمحور (زیرمجموعه UX)

این مدل صرفا مربوط به طراحی تجربه کاربری نیست و ارتباط بسیار نزدیکی با مباحث بازاریابی نیز دارد. در طراحی کاربرمحور سعی می شود که در هرکدام از مراحل طراحی نرم افزار به جنبه رضایتمندی کاربران توجه شود (یعنی در هر مرحله از ساخت نرم افزار از کاربران که می توانند گروهی از داوطلبین باشند، در همان مورد نظرسنجی می شود). مهمترین وجه های طراحی نرم افزار با این رویکرد شامل موارد زیر است:

• بستر: محیط ارائه نرم افزار (مانند سایت، اپلیکیشن موبایل، برنامه های رایانه ای و...) باید مطابق سلایق جامعه هدف انتخاب شود اما پیشنهاد می شود تمام آنها را پشتیبانی کند تا تمام جامعه هدف بتوانند از آن استفاده کنند.
• ساختار تیم: تیم طراحی نرم افزار باید دارای کارشناسانی از رشته های مختلف باشد مثلا اگر قصد داریم یک نرم افزار پزشکی را طراحی کنیم، لازم است چند پزشک نیز در گروه باشند تا نرم افزار مطابق سنت های رفتاری آن گروه ساخته شود. برای مثال، ممکن است جامعه پزشکی به درج کلیدهای راهنما در پایین صفحه عادت داشته باشند. در برخی مدلها ممکن است برخی از کاربران بصورت داوطلبانه و یا در قبال دریافت دستمزد در کنار تیم طراحی و اجرای نرم افزار باشند تا به صورت لحظه ای نظرات خود را اعلام و تیم اجرایی آنرا اجرا کنند.
• پرسونا: بدیهی است در هنگام طراحی کاربر محور باید داده های کافی از پرسونای مخاطب که مشخصات مخاطب را در قالب یک کهن الگو بیان کند لازم است. سپس از طریق پاسخ به سوالات زیر مشخص شود که چقدر به خواسته های این پرسونا پاسخ داده می شود:
  • کاربران چه کسانی هستند؟
  • اهداف کاربران چیست؟
  • سواد رایانه ای کاربران چقدر است؟
  • در بستری که طراحی می شود، چگونه به نیازهای کاربران پاسخ داده می شود؟
  • آموزشها و راهنمایی های احتمالی به کاربران چیست و باید چگونه ارائه شود؟
  • کاربران فکر می کنند که این بستر باید چگونه به آنها خدمات ارائه دهد؟
  • نحوه کنترل کاربران گونه است؟
  • رابط کاربری باید از چه کانالهای احتمالی (دیداری، شنیداری، لمسی و...) پشتیبانی کند؟
• سهولت: تا جای ممکن سعی می شود استفاده از نرم افزار آسان باشد و نیاز به دانش قبلی نداشته باشد. نرم افزار باید حداکثر تطبیق را با انتظارات و آموخته های قبلی کاربر داشته باشد تا لازم نباشد که کاربران خود را برای استفاده از نرم افزار مطابقت دهند.
• خود راهنمایی کننده: حداکثر تلاش انجام می شود که کاربران در مواجهه با محیط نرم افزار بتوانند بدون راهنمایی از آن استفاده کرده و امکانات آن را یاد بگیرند.
• تست گرم (توسط کاربر): حتما دقت شود که محصول پس از طراحی باید توسط بخشی از جامعه هدف تست شده و نتایج تست به دقت گردآوری شود تا چنانچه نیاز به اصلاح وجود دارد انجام شود.
• تست سناریو: سناریوهای مختلفی در انواع استفاده های کاربر از نرم افزار فرض شده و نتایج آن یادداشت می شود. چنانچه چیزی باعث رنجش کاربر شود رفع می گردد.

بر اساس نظریات: روبین، وردنبورگ، مائو، اسمیت، کری، کلینگ، باوم، شولر، نامیوکا، بیر، هولتزبلات، ماتور، جانودیس، همفیل، کافازو