Dobre referencje do przykładów dokumentacji dla użytkowników końcowych i porady [zamknięte]

10

Nasze oprogramowanie było używane przez wielu użytkowników, a dział szkoleń poprosił nas o wszelkie wskazówki dotyczące formatu dokumentacji użytkownika końcowego.

Czy ktoś wie, gdzie mogę znaleźć dobre przykłady dokumentacji użytkownika końcowego oprogramowania, z której dział szkolenia może skorzystać w celu uzyskania inspiracji, lub witryny z dobrą poradą?

Jest to podobne do tego pytania, jednak szukam dokumentacji użytkownika końcowego do użytku przez użytkowników nietechnicznych.

design documentation users Jan
źródło
1
„Gdzie mogę znaleźć dobre przykłady dokumentacji użytkownika końcowego oprogramowania” Krok 1. Kup oprogramowanie. Krok 2. Przeczytaj dokumentację. Co powstrzymuje Cię przed pobieraniem dokumentacji z istniejącego oprogramowania, którego już używasz? Uważam, że większość pakietów użytkowników końcowych ma pełną dokumentację on-line. Co powstrzymuje Cię przed czytaniem dokumentacji Microsoft dla pakietu Office?
S.Lott,
Uważam, że większość dokumentacji, którą przeczytałem, jest napisana w sposób, który nie jest atrakcyjny do czytania, a większość książek, które mam, są na ogół związane z programowaniem skierowane do odbiorców technicznych. Widzisz, kiedy ktoś ostatnio przeczytał instrukcję Microsoft? Dlatego szukałem inspirujących przykładów.
John
Hmm, interesujące q.
Wież
@John: „większość dokumentacji”. W porządku. Więc po odrzuceniu „większości”, co pozostało? Nie wiemy, dlaczego odrzucasz niektóre z najczęściej używanych dokumentów na świecie jako „nie zachęcające do lektury”. Możesz rozszerzyć swoją listę skarg i dodać swoją osobistą krótką listę przykładów dokumentacji oprogramowania, która nie jest wykluczona z testu „nie zachęcającego do czytania”. Nie znamy cię zbyt dobrze, więc nie możemy odgadnąć, dlaczego masz na myśli „nie apelować do czytania”.
S.Lott,
2
Uważajmy, abyśmy nie wymagali pytań z tak konkretnymi kryteriami tego, co jest „dobre”, że staje się zlokalizowane i nie dotyczy większości ludzi. Nie interesują mnie schematy kolorów.
JeffO

Odpowiedzi:

1

Możesz zacząć od wywiadów z użytkownikami wewnętrznymi na temat oprogramowania i dowiedzieć się, jakie informacje chcieliby wiedzieć.

Duża część dokumentacji, którą napisałem o oprogramowaniu, miała na myśli jedną lub wielu odbiorców. Twój dział szkoleniowy prawdopodobnie skorzystałby ze szkieletu tematów (jak spis treści). Następnie możesz omówić, które tematy są istotne, a które nie mają znaczenia dla ich celów szkoleniowych.

Niektóre tematy mogą obejmować:

  1. Docelowi odbiorcy)
  2. Wymagania techniczne
  3. Jak zainstalować (jeśli dotyczy)
  4. Proces (tj. Jaką funkcję biznesową wykonuje oprogramowanie?)
  5. Zestaw funkcji (jakie funkcje ma oprogramowanie?)
    • Możesz mieć podejście do tego zadania, np. Dodaj użytkownika lub Dodaj dokument
    • Możesz mieć podejście obiektowe, np. Użytkownicy, Role
    • Możesz mieć podejście oparte na menu, np. Menu Plik, menu Widok
  6. Wreszcie, być może sekcja Nadchodzące funkcje i FAQ może działać jako rosnące repozytorium wiedzy o Twoim produkcie.

Staraj się przewidywać, w jaki sposób użytkownicy końcowi korzystają z twojego oprogramowania, w oparciu o twoją wiedzę na temat jego tworzenia, twoją wiedzę na temat jego działania, a także na podstawie (miejmy nadzieję) wywiadów z użytkownikami końcowymi.

Co najważniejsze, spróbuj stworzyć dokumentację, którą chcesz przeczytać, użyj zabawnych przykładowych nazw, aby zademonstrować, i używaj wielu zrzutów ekranu z adnotacjami.

Mam nadzieję że to pomoże

funkymushroom
źródło
2

Przeczytałem kilka „Przewodników użytkownika końcowego” i napisałem jeden, i uważam, że istnieje wiele elementów, które poprawiają ich skuteczność:

  • Pokaż obrazom, w jaki sposób wydano polecenie lub wykonano pewne działanie (na przykład zrzuty ekranu).
  • Skoncentruj się na potrzebie zrobienia czegoś i sposobie jego realizacji. Unikaj technicznych opisów, na przykład, jak zoptymalizowane jest to działanie.
  • Po umieszczeniu schematu blokowego opisującego moduły oprogramowanie zostało podzielone i otrzymałem uwagi, że nie jest to bardzo przydatne.
  • Spróbuj przewidzieć możliwe problemy, które może mieć użytkownik, aby sekcja Rozwiązywanie problemów stała się przydatna. Musisz także przetestować swój program z użytkownikami, którzy nie byli zaangażowani w jego rozwój, nawet współpracownikami, którzy pracowali przy innych projektach.
  • Unikaj nudnych opisów. Wszelkie dalsze informacje mogą być umieszczone w dodatku lub czegoś podobnego.

Mam nadzieję, że może ci się to przydać.

Nicolás
źródło
1

Wspominasz, że zostanie wykorzystany do treningu.

Jeśli szukasz dokumentu szkoleniowego zamiast dokumentu referencyjnego, moją ulubioną taką witryną jest tutorial Joela Spolsky'ego na temat Mercurial tutaj .

  1. Prosta, przejrzysta prezentacja. Miło na to patrzeć.
  2. Autorytatywny, ale osobisty ton. Wydaje się, że jesteś na świetnym wykładzie na studiach.
  3. Proste zdjęcia, niezbyt duża liczba rzeczywistych zrzutów ekranu. Przeczytaj na odwrocie serwetki, aby dowiedzieć się, dlaczego to działa.

Jeśli twój dokument treningowy był 1/2 tak fajny jak samouczek Mercura Joela, przeczytałbym go. Ale potrzebujesz kogoś z a) pasją do pisania oraz b) niewiarygodną głębią wiedzy, aby ją zdobyć, nawet jeśli możesz skopiować 3 punkty powyżej. Mam nadzieję, że to działa.

MikeRand
źródło
0

Nie wiem, czy to pasuje do twoich potrzeb, ale istnieją systemy używane do dokumentacji technicznej, które sfinks przychodzą na myśl, które ułatwiają tworzenie dokumentacji online. Czy coś takiego można wykorzystać do tego, co Cię interesuje?

Właśnie natknąłem się na ReadTheDocs, który robi to samo, ale jest hostowanym rozwiązaniem.

Piper Merriam
źródło
0

Sprawdź Society for Technical Communication (STC) . Wielu zdobywców nagród napisało produkcję, która jest ogólnie dostępna. Mogą również mieć dostępne próbki. Zostanie członkiem zapewni również dostęp do większej ilości informacji.

Jim Rush
źródło