Прототип

Прототипът е работещо приближение на продукт или функция, създадено, за да отговори на въпрос, преди да бъде конструирано реалното нещо. Прототипите варират от хартиени скици, манипулирани на ръка, през кликаеми екрани, свързани в инструмент за проектиране, до функционален код, работещ с реални данни. Това, което ги обединява, е намерението: прототипът съществува, за да бъде оценен и отхвърлен или преработен, а не за да бъде доставен.

Основната дисциплина е да се реши на какъв въпрос трябва да отговори прототипът, защото това определя необходимата прецизност. За да се разбере дали хората разбират навигационната структура, е достатъчен набор от свързани статични екрани. За да се разбере дали дадено взаимодействие е достатъчно отзивчиво, е необходим кодиран прототип с реално време, защото никой статичен артефакт не може да го предаде. За да се разбере дали една сложна таблица с данни е използваема, са от съществено значение реалистичните обеми данни, тъй като таблица, която работи с десет реда, може да е неизползваема с десет хиляди. Изграждането на по-голяма прецизност, отколкото изисква въпросът, губи време; изграждането на по-малко води до отговори, които не се прехвърлят.

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

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

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

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

На практика, прототипирането се намира на кръстопътя между дизайна и доставката, а резултатът от него е решение, а не артефакт. Дизайн на продукта ангажираност, прототипите се използват за валидиране на концепции с реални потребители преди спецификацията, докато в разработване на продукти Те се използват и за намаляване на риска от технически предположения относно осъществимостта, производителността и интеграцията, преди да се ангажира с архитектура. Разграничаването на тези две цели е важно, тъй като прототип, който отговаря на въпрос за използваемост, и прототип, който отговаря на технически въпрос, рядко е необходимо да са едно и също нещо.