Buoni riferimenti per gli esempi di documentazione per l'utente finale e consigli [chiuso]

Potresti voler iniziare intervistando i tuoi utenti interni sul software e scoprire che tipo di informazioni vorrebbero sapere.

Gran parte della documentazione che ho scritto sul software ha avuto in mente uno o più pubblici. Il tuo dipartimento di formazione probabilmente trarrebbe vantaggio da uno scheletro di argomenti (come un TOC). Quindi puoi discutere quali argomenti sono rilevanti e quali sono irrilevanti rispetto ai loro obiettivi di formazione.

Alcuni argomenti potrebbero riguardare:

1. Pubblico / i di destinazione
2. Requisiti tecnici
3. Come installare (se applicabile)
4. Processo (vale a dire quale funzione aziendale esegue il software?)
5. Caratteristiche (quali caratteristiche ha il software?)
   • Potresti avere un approccio basato su attività a questo, ad es. Aggiungi un utente o Aggiungi a Documento
   • Potresti avere un approccio basato sugli oggetti, ad es. Utenti, ruoli
   • Potresti avere un approccio basato su menu, ad es. Menu File, menu Visualizza
6. Infine, forse una funzionalità e FAQ in arrivo sezione potrebbe agire come un repository crescente conoscenza del vostro prodotto.

Cerca di anticipare il modo in cui i tuoi utenti finali utilizzano il tuo software, basandoti sulle tue conoscenze di sviluppo, sulla tua conoscenza di ciò che fa e anche sulla base (auspicabilmente) delle tue interviste con gli utenti finali.

Soprattutto, prova a creare documentazione che vorresti leggere, usa divertenti nomi di esempio per dimostrare e usa molte schermate annotate.

Spero che questo aiuti

Ho letto diverse "guide per l'utente finale" e ne ho scritto uno, e ritengo che ci siano molti elementi che ne migliorano l'efficacia:

• Mostra con immagini come viene emesso un comando, o fatto qualche azione (schermate per esempio).
• Concentrati sulla necessità di fare qualcosa e sul modo di farlo. Stai lontano dalle descrizioni tecniche su come è ottimizzata l'azione, ad esempio.
• Una volta inserito un diagramma di flusso che descrive i moduli, il software è stato diviso e ho ricevuto commenti che non erano molto utili.
• Cerca di prevedere i possibili problemi che un utente potrebbe avere, in modo che la sezione Risoluzione dei problemi sia utile. Devi anche testare il tuo programma con utenti che non sono stati coinvolti nel suo sviluppo, anche i tuoi colleghi che hanno collaborato ad altri progetti.
• Evita descrizioni noiose. Qualsiasi ulteriore informazione può essere inserita in un'appendice o qualcosa di simile.

Spero che questo possa esserti utile.

Hai detto che sarà usato per l'allenamento.

Se stai cercando un documento di formazione piuttosto che un documento di riferimento, il mio sito preferito è il tutorial di Joel Spolsky su Mercurial qui .

1. Presentazione semplice e pulita. È bello da guardare.
2. Autorevole, ma personale nel tono. Sembra di essere in una grande lezione del college.
3. Immagini semplici, non una quantità copiosa di schermate effettive. Leggi Il retro del tovagliolo per capire perché funziona.

Se ti stai allenando, i documenti erano 1/2 come il tutorial di Mercurial di Joel, l'avrei letto. Ma hai bisogno di qualcuno con a) la passione per la scrittura eb) un'incredibile profondità di conoscenza per farcela, anche se potresti copiare i 3 punti sopra. Spero che funzioni.

Non so se questo si adatta alle tue esigenze, ma ci sono sistemi là fuori usati per la documentazione tecnica sfinge essendo uno che viene in mente che facilita la creazione di una documentazione online. Potrebbe essere usato qualcosa del genere per ciò che ti interessa?

Ho anche trovato ReadTheDocs che fa la stessa cosa ma è una soluzione ospitata.

Dai un'occhiata alla Society for Technical Communication (STC) . Molti dei loro vincitori del premio hanno scritto una produzione generalmente disponibile. Possono anche avere campioni disponibili. Diventare un membro fornirà inoltre l'accesso a un corpo di informazioni più ampio.