Случай на използване в дизайна Пример за използване на персонализирани скриптове от стартиране на Trucker Path

Николай Ковалюнас, продуктов дизайнер в Trucker Path, разработчик на приложения за камиони, написа колона за vc.ru за това как да използвате персонализирани скриптове в работен процес.

Всеки бизнес първоначално е насочен към решаване на проблем. В ИТ индустрията, където потребителят често взаимодейства с продукта чрез интерфейс, дизайнът е ръководството и решението на проблема на потребителя. Продуктовият дизайнер се занимава с търсене на ефективно решение и се опитва да осигури добро потребителско изживяване.

Just Use Case е един от най-добрите начини да направите това. За себе си формулирах, че Use Case е писмено описание на това как потребителят може да взаимодейства със системата, за да постигне конкретна цел.

Всеки случай на използване е поредица от прости стъпки, през които потребителят трябва да премине, за да постигне целта. В повечето случаи Use Case описва какво прави системата, а не как. Всъщност това правило трябва да се спазва, когато се създава Use Case.

Use Case може, макар и не задължително, да бъде допълнен с визуален компонент. Опитът показва, че простата диаграма на работния процес прави случая на използване по-лесен за разбиране и получаване на обратна връзка.

Какво е Use Case

В зависимост от сложността и детайлността, Use Case може да съдържа следните елементи:

Име (Име) - името на случая на използване: кратко, разбираемо, отразяващо същността.
Кратко описание - Текст, описващ този случай на употреба.
Участници (Actors) - списък на участниците във взаимодействието. Често се състои от един човек.
Предпоставки - условия,който трябва да бъде изпълнен преди започване на изпълнението на този случай на употреба.
Тригерът е събитие или условие, което кара потребителя да започне да изпълнява случая на употреба.
Основен сценарий (Basic Flow) – последователност от действия, които участникът извършва за успешно постигане на цел. Може също да се нарича нормален поток, първичен сценарий и щастлив път.
Алтернативни сценарии (Alternative Flows) - описание на алтернативни сценарии за изпълнение на Use Case. Важно условие за алтернативни сценарии е участникът в крайна сметка успешно да постигне целта.
Изключителни потоци - всичко, което може да накара участник да не успее да изпълни случая на използване.
Публикуващи условия - резултатът след изпълнението на случая на използване.

За щастие на практика не винаги е необходимо да се използват всички точки. Всичко зависи от това за какво и за кого го пишете.

Писане на Use Case

Всъщност примерът е взет от реален опит. В Trucker Path имах задача да импортирам списък с превозвачи чрез CSV. Да започваме.

Както можете да видите, не сме използвали всички компоненти на Use Case, което е съвсем нормално. Сега нека напишем последователност от стъпки за Basic Flow.

Основен поток (B1)

Страхотно, първата версия е готова. Забележете, че незабавно се откриват слабости и несъответствия, които могат незабавно да бъдат отстранени. В резултат на това проектираното взаимодействие е логично и разбираемо. Не забравяйте да опишете действията на системата в допълнение към действията на потребителя. Липсата на това описание е една от най-честите грешки.

Случаят на използване може да бъде придружен от бързо скицирани основни екрани - по-лесно е да предадете на другия човек същността на случващото се. По-долу е даден пример за такива екрани. Често можете да се справите само със скици в тетрадка, така чепо-бързо.

Сега най-важното. Какво се е случило, трябва да обсъдите с продуктовия мениджър. В идеалния случай, ако имате възможност да го направите лично. Понякога е полезно да поканите някой друг от инженерния екип. Основната цел е да получите обратна връзка, да обсъдите детайлите на решението, да видите доколко идеята е жизнеспособна за реализация. Привличайки продуктовия мениджър в работата, получаваме вече частично договорено решение. Това означава, че ще има по-малко непредвидени промени в бъдеще.

Какво означава това за нас? Обемът на работа е намален с 30-40%, което е доста осезаемо. Ако започнем да рисуваме дизайна веднага, ще загубим много време, защото в крайна сметка работата ще трябва да бъде преработена. И така веднага открихме несъответствие между предложеното и оптималното решение.

Какво следва

След това прецизираме основния поток въз основа на обратната връзка и отново го обсъждаме с продуктовия мениджър.

В резултат на това писането на Use Case ще отнеме няколко повторения. Помнете прогресивния JPEG метод: всеки път решението трябва да става все по-добро. В процеса можете да добавите алтернативни и изключителни сценарии, основното е да знаете мярката и да не се опитвате да покриете всички възможни опции. Писането на Use Case заради самия Use Case няма смисъл. Струва си да пишете, за да разрешите проблема бързо и ефективно.

Заключение

Ако все още се съмнявате дали трябва да използвате такова нещо в работния си процес, ще очертая накратко седем причини да обичате Use Case:

Дизайнът на интерфейса и потребителското изживяване са бързи и лесни.
Интерфейсът е по-разбираем и логичен, повишавайки ефективността на работа и учене.
Грешките в проектираното потребителско изживяване се идентифицират бързо.
По-значими елементи на интерфейсапо-лесен за пренасяне до горното ниво.
Има разбиране какво може да се обърка в процеса на взаимодействие на потребителя с продукта.
Use Case помага на дизайнера да обясни на другите членове на екипа как трябва да се държи продуктът.
Помага да се спести време за производство на дизайн чрез премахване на ненужните части от продукта.