Често испуњени жаргоном, акронимима и упутствима који захтевају да ПхД разуме, корисничка упутства за софтвер понекад се пишу са становишта девелопера а не корисника. Као резултат, водич може направити претпоставке о читалачком нивоу вјештина који су често неточни. Први корак у писању доброг корисничког приручника је да стварни процес писања буде што је могуће даље од инжењера.
Програмер зна више од било кога што чини софтвер радом, али то не значи да би програмер требао написати водич. Напротив, то је посебан недостатак. Још важније од дубоког разумевања унутрашњег функционисања софтвера је разумевање ко ће бити крајњи корисник, који је његов ниво образовања и како ће тај крајњи корисник користити софтвер. У већини случајева, крајњи корисници не морају да знају финије тачке програмирања и бацк-енд радове софтвера - они само треба да знају како да га користе како би олакшали своје послове.
Тестирање корисника
Приручник за кориснике треба да буде у великој мери оријентисан на задатке, а не да буде изразито описан. Пошто је приручник написан да помогне корисницима да разумеју како да изврше одређене задатке, писац треба да има разумевање и за те задатке, и као резултат тога, пролазак кроз сваки дискретни корак сваке карактеристике је апсолутно неопходан. Није неопходно да писац обавезно зна како је програм креиран са становишта дизајна или развоја, али је од суштинског значаја имати добро познавање свих његових особина. Приликом извршавања сваког задатка, потребно је време да запишете сваки корак, укључујући кликове, падајуће меније и друге радње.
Процес интервјуа
Иако девелопер не би требало да пише приручник, она ће и даље бити драгоцен ресурс за писца, и пре него што почне да пише, планира почетни састанак између писца, девелопера и инжењера и потенцијалних крајњих корисника како би се информисало писање писаца од почетка. Интервјуи са стручњацима и инжењерима требају бити забиљежени, са транскриптима направљеним за каснију референцу.
Слике
Кориснички приручник не би требало да буде превише тешки за текст. Уместо тога, укључите либералну употребу графике и снимака екрана. Опис акције је много јаснији са упутствима заснованим на тексту, праћеним екранима који јасно илуструју тај правац. Укључите и пре и после приказа, да бисте приказали како изгледа екран пре предузимања сваке акције, и шта се дешава након што је акција предузета. Једноставан алат за снимање екрана, као што је алатка за изрезивање, укључена у Мицрософт Виндовс, добро функционише за снимање ових слика. Обавезно бројите сваку слику и укључите опис који га укратко описује. Центрирајте га одмах испод параграфа који први уводи концепт који је приказан на слици.
Форматирање
Јасно комуницирање у техничком документу захтијева планирање и пажљиво придржавање стандарда у цијелом водичу. Стандарди у презентацији, језику и номенклатури помажу да се избегне конфузија. Предлошци су доступни и могу бити добра полазна основа за једнообразност, иако се они сигурно могу прилагодити свакој ситуацији. Коришћење маргине од једног инча са једном колоном најбоље одговара потреби за додавањем графике; подешавање у две колоне може се чинити пренатрпаним и може довести до конфузије у постављању слика.
Верзија и праћење
Више од било ког другог типа документа, водич за кориснике софтвера ће вероватно проћи кроз више итерација пре него што буде комплетиран, и вероватно ће проћи кроз процес прегледа од стране више заинтересованих страна. Коришћење функције Трацк Цхангес у програму Мицрософт Ворд је једноставан начин да пратите коментаре и промене сваког појединца. Стварање вишеструких верзија након сваког циклуса прегледа, сваки са различитим називом датотеке, такође помаже процесу заједно и осигурава да су сви учесници задовољни коначним резултатом.
