My philosophy boils down to these few points, and this is how I try to build products I work on:

1. Enable your power users

Remove arbitrary restrictions and build for your ideal user.

• Arbitrary numerical/size restrictions (except when used with pricing tiers & messaged appropriately. see #4 Disabled Features)
• Reasons like “users only ever add X of these” are almost always broken given enough time
• Disabling useful features for arbitrary reasons (especially when they’d function otherwise)
• (There should be a technical limit to prevent abuse, but it should be something nobody ever reaches)

2.Consistency is Key

Group similar features, or place them in similar locations across pages. This premise is all about discovery. Users should be able to discover new / unlockable functionality based on things they already know. Similar tools and functions should be in similar places to facilitate this.

Furthermore, similar objects should be filtered on a single page, instead of split into multiple pages. This allows people to more easily see what features could be used if they wish (or if they unlock it, see #4 Disabled Features). This also reduces clicks for accessing recent items.

Solving this class of usability problems makes software feel more intuitive. Examples of guidelines for this are:

• If providing lists with filtering / search options, these should be placed in the same spot globally.
• Across multiple pages, if similar functions are present, use the same design / locations to allow users to find them naturally.
• Similar “Things” should be listed on the same page with filtering. If something makes sense to be a single database table, it makes sense to show them combined.

3. Link between related tools / objects

Provide linking between related things to allow users to understand relationships. Users sometimes have issues visualizing parent / child relationships in software. To help this, we need to ensure all parent / child / sibling relationships between objects are easily linkable between each other in interfaces.

This helps users understand what your software “is” conceptually. For example, you have a data source view and a reporting view, these should be inter-linked to allow the relationship to be seen & used.

4. Disabled Features

If a feature is disabled and could be enabled at another price/access tier, it should be disabled with an upgrade message. This isn’t just a sales tool, but also makes the question of “why can’t I see or use this” easier to answer. #5 Administrative Features is an exception to this.

If there is a technical reason something is disabled, the error messaging should reflect that. Technical error messaging should explain in plain english why something isn’t working, without leaking secret information or stack traces.

5. Administrative Features

Administrative features should be always hidden except to those who are allowed to use them. There’s always a line between user and admin tools. Anything not given to common users should be completely hidden on the client (and properly permissioned on the server-side)

Users shouldn’t have to ask about or see administration tools.

6. Naming and Semantics

Naming is important are important, but users can see through your marketing spiel, and will refer to products with what they feel is most appropriate. Aligning to this implicit standard is important for easy communication. Product positioning can only go so far, if it’s not a natural alignment with what your product does, using poor naming choices will cause friction.

Appropriately naming product features after their actual use is important for discoverability, so a user can guess what something does before they click it.

Along the same lines, using a confusing name for a feature that it’s usually never referred to as goes against user perception of the product and creates confusion for new users.

Furthermore, The Product <-> Sales <-> Marketing feedback cycle is important, but doesn’t justify breaking usability and user expectations to adhere to the marketing / sales pitch of the month.

7. Reduce click counts

Reduce click counts to reach important features. Hiding important/major functionality under sub navigation, hidden sidebars, or ”…” menus is usually not ideal, as it makes it not easily discoverable and increases click counts to get to their target location on your app.

8. Tooltips & Explainers

Add tooltips and helper text to as many things as possible. Adding just a sentence of explainer tooltip text might solve a user question before it arises.

9. Predictability

Actions should be predictable. Clicking save shouldn’t do something completely unrelated. Furthermore, irreversible actions should be clearly denoted as irreversible, and need additional confirmation. Even then, it’s important to back up things users delete for a little while to allow for recovery of accidental deletions.

10. Re-Inventing the Wheel

Build things that function the way users expect. Don’t re-invent the wheel for simple things that have been done countless times. Unless it’s important for your product (or is your product) to do things a different way, don’t re-invent common practices for account management, search, password, and navigation flows.

All of the items in this list could probably be condensed into this single point. Your product needs to be understandable and usable without training.