These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers, from implementation to long-term success. The practices are written to work for most users and situations, but as always use best judgment when implementing.

Provide Users with Meaningful Field Names

• Use the label parameter to apply friendly names to dimensions or measures for end users, while maintaining database-friendly names within the view and model files. You might consider renaming a couple of common terms, like "Count" to "Number of" and "Sum" to "Total." If you aren't sure which words are meaningful to users, work with a business user to build out some common reports, and see what words they use to describe what they are looking for.

Try This	Instead of This

• Avoid exposing multiple fields with the same name. For example, count-type measures are automatically created within Looker with the name Count. This results in most view files containing a count measure with the same name. Multiple fields with the same name can be confusing for users. Adding labels or renaming count measures, to indicate the object that is being counted, will prevent confusion. Other fields to keep in mind include created dates and updated dates.
• Provide clear names for type: yesno type fields. For example, use Is the Item Returned instead of Returned for naming a field that indicates whether or not an items has been returned.
• Name ratios descriptively. For example, Orders Per Purchasing Customers is clearer than Orders Percent.
• Name fields consistently and represent values consistently across the model. Use value_format or value_format_name for applying formatting such as currency symbols, percentages, and decimal precision to numerical fields, to help make everything readable.

Group Similar Fields Together for Easier Navigation

• Use the group_label parameter to consolidate dimensions and measures from individual or multiple joined views that are related. For example, grouping all geographic information into a Geography group will pull all address and location information together within the field picker, rather than having it all listed alphabetically.

• Break up large, denormalized tables using the view_label parameter. Utilize the view_label parameter within fields to group fields together logically into separate headings within the field picker. Large, denormalized tables with a lot of fields can be difficult to navigate, so this gives the illusion of multiple views in the left-hand Explore field picker.

Less Is More

• Avoid exposing too much to users upon an initial Looker roll-out. Start small, and then expand the options. You don't have to expose all the tables or dimensions and measures at once. You can expose the fields that are most important, and then continue to build more functionality as business users become more confident with data exploration.
• Hide dimensions that are not relevant to users from the user interface. Use the hidden parameter on dimensions that will never be used through the user interface (such as ID fields or database update dates).
• Use the fields parameter within Explores and joins to limit the number of fields available to users. Included fields should be only those relevant to the Explore. This reduces bloat and provides a better experience for end users. Unlike the hidden parameter, this enables fields to be included or excluded on an Explore-by-Explore basis.
• Hide any Explores that exist solely for populating specific Looks, dashboard tiles, or filters using the hidden parameter for Explores. Explores that are not meant for exploration by end users should be hidden from the user interface.
• Use the fewest number of Explores possible while still allowing users to easily get access to the answers they need. Consider splitting out Explores into different models for different audiences, to limit the options available for each user group. The optimal number of Explores is different for every business, but having too many Explores tends to be confusing for end users. Consider using the group_label parameter for Explores within a model, in order to group them in a sensible way within the Explore dropdown menu.

Add Descriptions So Users Know Which Fields and Explores to Use

• Use the description parameter on dimensions and measures to provide additional information to end users about the logic or calculations used within the model. This is particularly important for dimensions and measures that leverage complex logic or calculations. However, descriptions should also be considered for ensuring that users understand the definitions behind simpler fields.
• Explore descriptions should be defined for users. Add a short description to each Explore to specify the purpose and audience using the description parameter.

Build Common Workflows into Looker

• Add drill_fields to all relevant measures. Drill fields enable users to click into aggregate values in order to access detailed data. Use the set parameter to create reusable sets of fields that can then be applied to any number of measures within a view.
• Add drill_fields to all hierarchical dimensions. For example, adding a drill_field for City into a State dimension will enable users to select a state and then drill deeper into the cities within that state. Note that this hierarchical drilling will automatically be applied within time dimension groups.
• Set up links that enable users to easily navigate and pass filters to other Looker dashboards, or to systems or platforms external to Looker. See our documentation on the link parameter for examples of passing filters through drills.