Style and standards: what to follow

Whenever a company decides to embark on a new IT project, there is always a moment when the development team raises the question of user experience. Of course, you can always turn a blind eye to various adopted standards and recommendation when it comes to UI, user-friendliness, or documentation of your solution. However, if your company truly cares about the end user experience or has any plans in the foreseeable future to obtain some sort of certification, it is strongly recommended that the development team follows style and design standards which best fit the product that is being developed.

Well, I guess it goes without saying that when the design and documentation of a product is consistent, clear and intuitive, and follows the universally acknowledged rules, it benefits all the parties involved. However, the abundance of guidelines poses another question: which ones exactly should one follow and where to find them? It really depends on the specifics of the project as well as the environment in which a new product is being created. For example, in case of Xpand, the products developed and services provided are based on various Microsoft products, such as Microsoft Dynamics NAV. This leads to the obvious choice of guidelines and standards that have been created by Microsoft and which are recommended for all Microsoft partners.

As a matter of fact, the product itself may have its own recommendations which take into account the specifics of that particular product. For example, solutions based on the Microsoft Dynamics NAV platform, like Logiqstar, have a style guide for products based on this ERP. Obviously, guidelines for a specific product or platform will have a higher priority that guidelines designed for multiple platforms.

Thus, if you provide services and produce content for a solution based on a Microsoft product, the priority in terms of guidelines would look as follows (from higher to lower):

 Understanding the priority is important when recommendations for one and the same design case contradict each other in different guidelines.

But where exactly can each be found and are they free?

• Product-specific guidelines – In case of products based on Microsoft Dynamics NAV, product-specific guidelines are located in several places:
  • Part for developers is shipped with the product and can be found directly in the online Help, in the Developer and IT Pro Help section. This documentation contains both help information for developers and design principles specifically for Microsoft Dynamics NAV, such as naming conventions for objects and fields. The same information is available in the open source MSDN for the corresponding version of Microsoft Dynamics NAV;
  • Guidance for authoring Help content for Microsoft Dynamics NAV is provided in the Style Guide for Microsoft Dynamics NAV. This guide is available in the Microsoft Dynamics NAV Help Toolkit which is used for compiling and generating Help projects. You will need a PartnerSource account to be able to download it. However, partially this information is available in MSDN, although the guidelines part is rather limited there.
• General Microsoft guidelines – When referring to general Microsoft guidelines, usually Microsoft Manual of Style for Technical Publications is meant. This is the key resource for those who produce content in English for and about Microsoft products and services. These guidelines cover a wide variety of environments where you product can be developed, including mobile devices. The offline .chm version is not publically available unless you happen to work directly on Microsoft projects, but a paperback edition of the manual or its electronic version is sold for a reasonable price;
• Guidelines within your company - Giving the guidelines created inside your company for your product the lowest priority is an arguable choice, but what we recommend is that you come up with your own principles only when you cannot find any official recommendation in available applicable sources.

Alternatives

There are other popular alternative guidelines that you may choose to adhere to when designing your solution or producing documentation for it, such as:

• Apple Style Guide – If your product is part of the Apple eco-system, this guide is the place to go if you want to ensure your product meets the Apple standards;
• The Chicago Manual of Style – One of the most widely used and respected style guides in the United States. This guide provides recommendations on editorial style and publishing practices, however it does not cover design principles for software products;
• Read Me First! A Style Guide for the Computer Industry – Another well-known resource for established style principles worth following in your project.

Resources mentioned in this article, except the Chicago Manual of Style, were created specifically for computer industry. There is an abundance of other guidelines, designed for other areas (general writing, legal documentation, academic papers, journalism, electronic publishing, etc.). You have to choose the one that meets your business needs and applies to your product environment. Whichever guidelines you choose to follow, and hopefully you will, just remember to remain consistent throughout your product or documentation.

These are the guiding style principles we adhere to at Xpand and encourage everyone else to follow this path.

Bringing your product to the universally accepted standards is like speaking the same language with everybody else who is in the same boat as you and shows respect both to your colleagues and your primary audience – end users.