Help Design Goals
Experimental design objectives for the Help app and GNOME user help.
Goals and Principles
- Bring content to the front. Draw the user in.
- Allow browsing content by topic area.
- There should be a clear and simple overarching structure, so users can orientate themselves and navigate easily.
- Keep navigation paths shallow, so people don't get lost.
- Overview pages shouldn't overwhelm - don't link to too many pages at once.
- Organise help according to user goals. Conform to their world-view.
- Don't require too much back and forward navigation - avoid pages with small amounts of content. The experience should flow, rather than being bitty.
- Problem solving is best solved by the web - integrate and push in that direction wherever possible.
- Be a guidebook rather than an encyclopedia:
- Don't document everything.
- Focus on what's interesting and important.
- Advertising the functionality that will improve the user experience. Advertise features that empower and enable.
- Content should be quick and easy to digest - avoid lists of more than four steps and large blocks of text.
- Signpost to enable quick scanning and navigation within pages:
- Each page should have a brief content summary at the top.
- Headings should be frequent. Blocks of text should be small.
- All pages should have a prominent structure (like a guidebook).
- Promote the experience while documenting it - reinforce a positive image of the product/system.
- Pages should have some visual interest and colour.
- Pay special attention to new users, in order to help them get started.
- Help users adjust to and make the most of changes to the software (particularly as part of the upgrade process).
- Cater to a range of confidence and experience levels. Allow users to progress in their mastery of the system.
- However, avoid highly technical knowledge or implementation details.
- Help documentation should integrate with downstream products:
- Don't expose the word "GNOME", or refer to the system/product in a way that will interfere the identity of downstream products.
- Allow the integration of downstream support services and sites.
Allow the incorporation of downstream docs? (See bug 690058.)
- Document every possible task/operation. Don't be an encyclopedia.
- Document generic knowledge that isn't specific to GNOME.
- It is difficult to keep screenshots and graphic representations of UI up to date.
- It is difficult to keep a large body of documentation up to date.