سخنرانی 14

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

رابط کاربری   - این ترکیبی از مدل اطلاعات منطقه مسئله ، روش ها و روش های تعامل کاربر با مدل اطلاعات و همچنین مؤلفه هایی است که از شکل گیری مدل اطلاعات در حین کار با سیستم نرم افزاری اطمینان می یابد. (اسلاید 14.1) .

یک مدل اطلاعات به عنوان یک نمایش مشروط از یک منطقه مشکل درک می شود ، که با استفاده از اشیاء رایانه ای (بصری و صوتی) تشکیل شده است که نشان دهنده ترکیب و تعامل مؤلفه های واقعی منطقه مشکل است.

روش ها و روش های تعامل با مدل اطلاعات با ترکیب سخت افزار و نرم افزار موجود در اختیار کاربر و ماهیت مسئله حل می شود. اثربخشی کاربر نه تنها با عملکرد سخت افزار و نرم افزاری که در اختیار وی قرار می گیرد بلکه با در دسترس بودن این ویژگی ها برای کاربر تعیین می شود. به نوبه خود ، استفاده کامل از قابلیتهای بالقوه منابع موجود به کیفیت رابط کاربری بستگی دارد.

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

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

طبق این مطالعه ، رابط از سه بخش اصلی تشکیل شده است - جریان اطلاعات به کاربر ، تعامل و روابط بین اشیاء. علاوه بر این ، قسمت "قابل رویت" کوه یخ بسیار کوچکتر از قسمت پنهان "نامرئی" آن است (اسلاید 14.2). نوک کوه یخ اطلاعاتی برای کاربران (رنگ ، انیمیشن ، صدا ، شکل اشیاء ، محل قرارگیری اطلاعات روی صفحه ، گرافیک) تنها 10٪ است و به هیچ وجه مهمترین مؤلفه رابط کاربری نیست. بخش بعدی رابط کاربری (30٪ مدل طراح) تکنیک برقراری ارتباط با کاربر و بازخورد با وی است. و سرانجام ، قسمت زیرین کوه یخ (60٪) مدل طراح - مهمترین بخش آن - خصوصیات اشیاء و رابطه بین آنها است.

14.1. اصول طراحی رابط کاربری

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

برای ایجاد چنین احساس "آزادی درونی" برای کاربر ، رابط باید دارای چندین ویژگی باشد (اسلاید 14.4) :

طبیعی بودن رابط.

قوام رابط

دوستی با رابط (اصل "بخشش کاربر")

اصل "بازخورد".

سادگی رابط.

انعطاف پذیری رابط.

جذابیت زیبایی.

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

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

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

قوام در داخل محصول.همان تیم باید هر کجا که ملاقات کند ، عملکردهای یکسانی را انجام دهد و به همان شیوه انجام دهد.

قوام در محیط کار.با حفظ سازگاری با رابط ارائه شده توسط سیستم عامل (به عنوان مثال ویندوز) ، یک برنامه کاربر می تواند به دانش و مهارت های کاربر که قبلاً هنگام کار با برنامه های دیگر بدست آورده بود ، اعتماد کند.

قوام در استفاده از استعاره ها.اگر رفتار یک شیء برنامه فراتر از آنچه معمولاً منظور از استعاره مربوطه است فراتر رود ، ممکن است کاربر در کار با چنین شیء دچار مشکل شود.

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

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

اصل "بازخورد".   همیشه برای اقدامات کاربر بازخورد ارائه دهید. هر اقدام کاربر باید تأیید بصری و گاه صوتی را دریافت کند که نرم افزار دستور وارد شده را پذیرفته است. در این حالت ، نوع واکنش ، در صورت امکان ، باید ماهیت عمل انجام شده را در نظر بگیرد.

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

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

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

راه دیگر برای ایجاد یک رابط کاربری ساده اما مؤثر ، قرار دادن و ارائه عناصر بر روی صفحه با در نظر گرفتن معنی معنایی و رابطه منطقی آنها است. این به شما امکان می دهد تا از تفکر انجمنی کاربر در فرآیند استفاده کنید.

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

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

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

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

اصل استعاری نیز اساس فناوری WISIWIG است - تجسم فوری بر روی صفحه نمایش نتایج اقدامات. این بدان معناست که صفحه باید وسایل چاپ را شبیه\u200cسازی کند و اگر کاربر بخواهد بخشی از متن را به صورت italics چاپ کند ، باید آن را به صورت italics در صفحه تایپ کند. در صورت از بین رفتن پرونده ، کاربر می بیند که این پرونده از لیست پرونده های نمایش داده شده روی صفحه ناپدید می شود. رابط در شکل طبیعی ، اطلاعاتی را در مورد وضعیت جسم در اختیار کاربر قرار می دهد و تأیید می کند که این عمل انجام شده است. می توان گفت که این استعاره با فرمول نزدیکتر است " آنچه را که در نتیجه اقدامات خود دریافت کردید می بینید ".

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

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

کمیت کیفیت رابط کار دشواری است ، اما ارزیابی کم و بیش عینی آن بر اساس شاخص های خاص زیر قابل دستیابی است.

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

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

سرعت حل مشکل با استفاده از این برنامه؛ در عین حال ، سرعت سیستم و سرعت ورودی داده ها از صفحه کلید ، زمان لازم برای رسیدن به هدف کار حل نشده ، نباید ارزیابی شود. براین اساس ، معیار ارزیابی برای این شاخص می تواند برای مثال تعریف شود: کاربر باید حداقل 20 سند را در یک ساعت با خطای بیش از 1٪ پردازش کند.

رضایت کاربر ذهنی هنگام کار با سیستم (که می تواند به عنوان یک درصد یا به عنوان یک ارزیابی در مقیاس n-point اندازه گیری شود).

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

رسمی سازی زمینه استفاده

رسمیت معیارهای موفقیت عینی

تجزیه و تحلیل اهداف

رسمی سازی نقش های تجاری کاربر

رسمی سازی عملکرد

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

بررسی اجمالی رابط سیستم رقابتی

رسمیت عادات و انتظارات کاربر

رسمی سازی زمینه استفاده

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

ویژگی های کاربر: تجربه رایانه ، دانش دامنه ، انگیزه ها ، اندازه / اهمیت گروه های کاربر ، الگوهای (موقعیت های معمولی) استفاده.

اهداف و اهداف کاربران؛

اهداف پروژه: چه عواملی باعث ایجاد پروژه ، مراحل ایجاد پروژه ، چه نتایجی باید به دست آمده ، چه اطلاعاتی لازم است و چه موقع.

فناوری توسعه و سکویی که کاربران در آن کار خواهند کرد.

محیطی که در آن پروژه ایجاد و مورد استفاده قرار می گیرد (فیزیکی ، بازار ، سازمانی و فرهنگی).

در ورودی: دسترسی به کاربران موجود و بالقوه سیستم ، کارشناسان و مستندات پروژه.

خروجی: توضیحی از زمینه استفاده از سیستم ، احتمالاً توضیحی دقیق تر از ویژگی های کاربر.

طبقه بالا به محتویات

رسمیت معیارهای عینی برای موفقیت.

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

بر این اساس ، در این مرحله یک کار واقعی برای طراحی رابط ایجاد می شود. به عنوان مثال:

یک گروه کاربر دائماً ترکیب خود را تغییر می دهد و الگوی استفاده در نظر گرفته شده به ندرت استفاده می شود. لازم است روی سهولت درک رابط تمرکز کنید.

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

20٪ تعداد خطاهای انسانی را کاهش می دهد.

در ورودی: دسترسی به کاربران ، کارشناسان و مستندات پروژه.

در راه خروج: لیستی از معیارهای عینی برای موفقیت.

طبقه بالا به محتویات

تجزیه و تحلیل اهداف

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

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

نتیجه این فرایند باید لیستی از اهداف باشد ، به عنوان مثال ، برای یک توستر ، لیست نهایی اهداف باید بسیار ساده به نظر برسد: "باید قطعات کوچکی از مواد غذایی ، به طور عمده نان را سرخ کنید".

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

در ورودی: دسترسی به کاربران ، کارشناسان و مستندات پروژه

در خروجی: لیستی از اهداف معرفی یک رابط کاربری جدید با خصوصیات وزن هر یک.

طبقه بالا به محتویات

رسمی سازی نقش های تجاری کاربر

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

در این مرحله می توانید از روش نظارت بر افرادی که وظیفه خود را با استفاده از ابزارهای موجود انجام می دهند ، استفاده کنید و این سیستم رقبا (در صورت وجود) و اشیاء دنیای واقعی است. منبع خوبی برای تجزیه و تحلیل اغلب حتی افراد را مشاهده نمی کند ، بلکه تجزیه و تحلیل نتایج کار آنها - اگر معلوم شود نتیجه کار عملا مستقل از ابزاری است که استفاده می شود ، این بدان معنی است که شما فقط به عملکردی نیاز دارید که بر نتیجه تأثیر بگذارد (یعنی. عملکردهایی که هیچ کس از آنها استفاده نکرده باشد مورد نیاز نیست).

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

خروجی: توضیحات نقشهای شغلی کاربر.

طبقه بالا به محتویات

رسمی سازی عملکرد

در این مرحله و براساس اطلاعاتی که در مراحل قبلی ایجاد شده است ، بالاخره لیستی از عملکردهای نسخه جدید سیستم تشکیل می شود. TK که قبلاً تولید شده است ، بعضی از قسمت های عملکردی لازم را شامل نمی شود ، یا شامل کارایی است که در واقع مورد نیاز کاربران نیست.

در ورودی: دسترسی به کاربران ، کارشناسان و مستندات پروژه ، اطلاع از جوانب اصلی حوزه موضوع.

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

طبقه بالا به محتویات

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

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

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

فرض کنید برای برنامه ایمیل آینده باید اسکریپت تهیه کنید. ظاهراً برای این کار سه سناریو لازم است:

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

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

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

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

در ورودی: دسترسی به کاربران ، کارشناسان و مستندات پروژه ، اطلاع از جوانب اصلی حوزه موضوع.

در هنگام خروج: سناریوهای کاربری کاربر (سناریوهای توسعه یافته معمولاً به شکل نمودارهایی ارائه می شوند که کل فرایند استفاده از سیستم برای انجام یک کار خاص را توصیف می کند).

طبقه بالا به محتویات

بررسی اجمالی رابط سیستم رقابتی

بیشتر مخاطبان هر سیستم مهارت استفاده از چندین سیستم رقیب را دارند. اگر رابط توسعه یافته کاملاً متفاوت از رقبا باشد ، کاربران مجبور به تغییر مجدد خواهند شد. علاوه بر این ، سیستم های رقیب غالباً حاوی راه حل های موثری هستند که برای اتخاذ آنها مفید است (یا ، بیشتر در هنگام طراحی رابط در نظر گرفتن آنها).

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

در ورودی: دسترسی به سیستم های رقیب.

خروجی: مروری بر مزایا و معایب رابط سیستم های رقیب.

طبقه بالا به محتویات

رسمیت عادات و انتظارات کاربر

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

در ورودی: دسترسی به کاربران.

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

این مقاله برای کسانی که تازه شروع به ایجاد واسط می کنند مفید خواهد بود - شما ایده ای را برای حرکت به سمت شما دریافت خواهید کرد. ما به تجربه حداکثر چیز جدیدی قول نمی دهیم - حداکثر دانش شما یک تصویر هماهنگ را تشکیل می دهد. بنابراین از کجا شروع کنیم به طراحی؟

دویدن برای خواندن کتاب و مقالات گوگل برای الهام گرفتن ایده خوبی نیست. رابط های خواندن خود طراحی نشده اند و بهتر نمی شوند. البته ، یک نظریه خوب است ، اما ، به هر صورت ، نمی توانید از تئوری فاصله بگیرید. همچنین مراجعه به مواد مرجع در مرحله اولیه بی معنی است - این باید با سؤالات مشخص انجام شود. و جستجوی بی پایان برنامه های طراحی باعث بهره\u200cوری نمی شود.

پس برای شروع طراحی چه باید کرد؟

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

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

داستان ایجاد کنید

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

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

با این رویکرد ، ما شروع به "دست نخورده" داستان می کنیم. در فرآیند اختراع تاریخ ، مهمترین کار این است که تمام سناریوهای ممکن را عملی کنید.

با ورود به سیستم ، ماکسیم اولین پرداخت خود را در نمایندگی ، مشخصات خودروی وی ، اسناد مربوط به خودرو ، نام مدیر خود می بیند. اگر خرید وی منوط به هرگونه تبلیغی باشد ، در مورد شرایط عمل (مثلاً شستشوی رایگان یک ماشین لوکس در ماه آگوست) ، اعلانی در سیستم مشاهده خواهد کرد.

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

بدون تاریخ ، هیچ محصولی ، پروژه ای ، رابط کاربری وجود ندارد. یک داستان منسجم رفتار کاربر را توضیح داده و آنچه را که فاقد آن است را درک خواهد کرد.

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

با یک فعل بسوزانید

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

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

بگذارید بازی کنم!

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

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

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

1. جمع آوری داده ها

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

• با مشتری ارتباط برقرار می کندبرای درک معنی و فلسفه برنامه؛
• تماشای تحولات: نمونه های اولیه آماده (حتی اگر آنها فقط در یک دستمال وجود داشته باشند)؛
• برنامه های رقیب را تجزیه و تحلیل می کند   (و احتمالاً تست قابلیت استفاده برنامه های رقبا را انجام می دهد)؛
• نگه می دارد مصاحبه ساختاری مشتری   یا مشتریان بالقوه

2. طراحی

در این مرحله از رابط طراح برنامه:

• شبکه ، رنگ ها ، قلم ها و پس زمینه را تعریف می کند.
• و اغلب کنترلهای سفارشی مانند منوهای کشویی ایجاد می کند.

طبعاً در هر مرحله بحث و در صورت لزوم تجدید نظر مجانی صورت می گیرد. سفارش شما   دریافت خواهید کرد یا به عنوان فایل های تصویری فتوشاپیا به شکل کد HTML یا XAML.

4- اجرای

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

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

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

5. تست قابلیت استفاده

جذب یک طراح رابط کاربری خوب به پروژه ، لزوم انجام تست های قابلیت استفاده سیستماتیک را از بین نمی برد. تکیه فقط به "طراح رابط کارآمد" به دلایل زیر مضر است:

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

• سریع: 2-7 روز در هر آزمون؛
• ارزان   - یک یا دو مرتبه قدر ارزانتر از مطالعات بزرگ؛
• در مخاطب مورد نظر خود. ما او را پیدا خواهیم کرد. آیا شما به آمریکایی ها از 30-35 سال میانه ، علاقه مند به عروس های روسی هستید؟ لطفاً

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

زمان بندی

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

انجام اصلاحات به درخواست شما به زمان بیشتری نیاز دارد. اگرچه ما برای ویرایش هزینه اضافی نمی پردازیم ، اما اینها می توانند در مهلت های انجام یک پروژه تأثیر بگذارند. اغلب ، ویرایش ها زمان بیشتری را برای ایجاد صفحه نمایش به زمان مستقیم می دهند.

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

هزینه

طراحی و طراحی یک صفحه نمایش واحد نیز هزینه مشابهی دارد:

• طراحی / طراحی صفحه اول   ارزش دارد 48 800 ر. صفحه اول گرانتر است ، زیرا برای کل برنامه بسیار مهم است. هنگام تهیه آن ، باید ساختار کل برنامه را در نظر بگیریم.
• طراحی / طراحی صفحه نمایش های دیگر – 18 350 ر. برای هر کدام

بنابراین ، تهیه یک نمونه اولیه (یا طرح) از پنج صفحه 48 48 800 روبل هزینه خواهد داشت. + 18 350 روبل. x 4 \u003d 122 200 ر.

نشانگر هزینه تست قابلیت استفاده 52 500 روبل. - 126 000 مالش.

پروژه های بزرگ

توضیحات بالا مربوط به پروژه های توسعه رابط نرم افزار کوچک است. پروژه های بزرگ   خواهد بود مفید برای زیر کارها است، و چرخه ای را برای هر یک از آنها انجام دهید. به عنوان مثال ، اگر ما رابط Skype را توسعه می دادیم ، می توانستیم ماژول های زیر را برجسته کنیم:

• رابط ارتباط صوتی؛
• رابط ارتباط تصویری؛
• مدیریت لیست تماس؛
• و غیره

برای هر یک از ماژول های ذکر شده توصیه می شود مراحل را طی کنید ، سپس به ماژول بعدی بروید. این روش توسعه نامیده می شود چابک   (می خواند "چابک"). مرسوم است که هر بار که می خواهید مشتریان و دختران زیبا را تحت تأثیر قرار دهید ، این روش را رعایت و ذکر کنید :-)

من می خواهم به شما توصیه های ساده اما متناقض را ارائه دهم: هر آنچه راجع به طراحی گفته می شود را باور نکنید.

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

چنین حقایق "مشترک" بسیاری وجود دارد ، و آنها در کنار هم باعث ایجاد اسطوره های طراحی وحشتناک و وحشتناک می شوند - می خواهم امروز درباره مهمترین آنها صحبت کنم.

اسطوره شماره 1. طراحی یک سرویس اضافی است.

   یک طراح مهم برنامه های عمومی

بسیاری از افراد فکر می کنند که مرحله طراحی یک سرویس اضافی است که می توان از آن غفلت کرد. این چنین نیست.

ما محصولات IT را برای چه ساخته ایم؟ اگر در ذهن ما و حافظه خوبی هستیم ، آنها را برای حل مشکلات تجاری (خودمان یا مشتریان خود) ایجاد می کنیم - چندان مهم نیست. راه حل این مشکلات تجاری ، به نوبه خود ، بر اساس انجام وظایف کاربر ایجاد شده توسط محصول و با در نظر گرفتن شرایط بازار ، محدودیت های فناوری و سایر موارد است.

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

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

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

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

اسطوره شماره 2. طراحی گران است

   مدیر پروژه بودجه را از مشتری دریافت می کند

عقیده ای وجود دارد که مرحله طراحی فقط باعث افزایش هزینه محصول می شود.

در همین راستا ، من به نقل از کارل وایگرز - پدرسالار مهندسی سیستم ، نویسنده کتاب شگفت انگیز "توسعه نیازهای نرم افزاری" و فقط یک شخص باهوش.

کارل وایگر یک بار تحقیق در مورد بازار توسعه فناوری اطلاعات آمریکا انجام داد و آن را محاسبه کرد 40٪ بودجه عمرانی بطور متوسط \u200b\u200bهدر می رودو این پول به دلیل تقصیر توسعه دهندگان کج یا مشتریان بد از بین نمی رود بلکه فقط به این دلیل است که دو طرف - مشتری و توسعه دهنده - فقط نتوانستند میان خودشان توافق کنند.

چهل درصد - و این مربوط به آمریکا است ، جایی که یک رابطه کاملاً متفاوت بین مشتری و توسعه دهنده حاکم است! به نظر من برای روسیه این رقم حتی بیشتر است - حدود یک و نیم برابر.

در این حالت ، طراحی صحیح سیستم ، مطابق محاسبات همان وایگر ، 15-20٪ بودجه توسعه را به خود اختصاص می دهد (و این رقم با تجربه ما کاملاً تأیید می شود).

یک اثر جالب به نظر می رسد: ما 15-20٪ ثابت را برای طراحی صرف می کنیم ، اما در عین حال هزینه های "خالی" را نیز به حداقل می رسانیم (همان 40٪ بودجه) که می تواند به طور بالقوه یک پروژه را دفن کند و علاوه بر این ، زمان به دست آوردن یک محصول کارآمد را بسیار به تاخیر بیاندازد.

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

اسطوره شماره 3. طراحی نوشتن TK است

   فیل ساخته شده TK

اغلب می شنوید که طراحی ، روند نوشتن TK است که می تواند به قرارداد وصل شود. این چنین نیست.

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

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

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

اسطوره شماره 4. طراحی مربوط به رابط های کاربر است.

محصولی کاربر پسند

به دلایل بسیاری ، طراحی در بازار توسعه وب (و نه تنها در بازار ما) با رابطها کاملاً همراه است.

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

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

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

اسطوره شماره 5. یک مدیر همچنین می تواند طراحی کند

   مدیر پروفایل

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

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

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

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

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

اسطوره شماره 6. روانشناسان باید طراحی کنند

   محتوای فنی محصول با توجه به روانشناس

برخی از شرکتها - حتی بزرگترین آنها - معتقدند افرادی که دارای آموزش روانشناسی هستند باید در طراحی شرکت کنند. این اسطوره از این باور رشد می کند که طراح باید منحصراً از منافع کاربران دفاع کند. همانطور که قبلاً فهمیدیم ، این طور نیست - طراح با کل محصول به طور کلی سروکار دارد و منافع کاربران و مشتری را نیز در نظر می گیرد ، نه به ویژگی های سیستم اشاره می کند. همه اینها مهارت های فنی را می طلبد که اکثر روانشناسان از آن محروم هستند.

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

اسطوره شماره 7. طراحی باید توسط مهندسین انجام شود.

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

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

طراح کیست؟

چه کسی باید طراح باشد؟ این یک سؤال بسیار پیچیده است که می توانم به طور خلاصه به این روش پاسخ دهم.

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

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

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

هیچ روش طراحی واحدی وجود ندارد

   طراح نمی تواند روی احساسات پروژه بایستد

رویکردهای زیادی برای طراحی وجود دارد و یک خواننده بی تجربه می تواند به راحتی با فراوانی ترفندها ، رویکردها و اختصارات با سخاوتمندانه با طعم اصطلاحات طعم دهنده شود (با تمام این UX ، UI ، CX ، HCD و سایر IDDQD ها با همتایان کج روسی).

با این حال ، برخی تلاش می کنند مدلهای طراحی جهانی را به دست آورند ، اما در پایان معلوم می شود که در تلاش برای ترکیب 20 رویکرد موجود در طراحی (به طور مشروط) موجود ، ما با 21 رویکرد به پایان می رسیم - و به نظر می رسد که روشها شروع به تولید خود می کنند.

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

این هم یک اسطوره است که شخصاً قاطعانه مناسب من نیست. یک رویکرد واحد برای طراحی وجود دارد ، اما نیاز به مکالمه جداگانه ، بزرگ و بسیار شخصی دارد. بنابراین ، با اجازه شما ، این اسطوره را بعداً رد خواهیم کرد - نزدیک به پایان ماه سپتامبر ، وقتی مقاله بزرگ من در مورد این موضوع در Cossa منتشر می شود.

به جای نتیجه گیری

امروز چه فهمیدیم؟

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

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