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.
  • Audience:
    • 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.

AllanDay/HelpDesign (last edited 2015-07-22 22:39:24 by AllanDay)