Prática recomendada: criar uma experiência positiva para os usuários do Looker
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Essas práticas recomendadas refletem as recomendações compartilhadas por uma equipe multidisciplinar de profissionais experientes. Esses insights vêm de anos de experiência trabalhando com clientes do Looker, desde a implementação até o sucesso a longo prazo. As práticas foram criadas para funcionar na maioria dos usuários e situações, mas você precisa usar seu bom senso ao implementar.
Os desenvolvedores do LookML podem seguir estas dicas para melhorar a experiência dos usuários com o Looker:
Essas recomendações são explicadas em mais detalhes nas seções a seguir.
Forneça nomes de campos significativos aos usuários
Use o parâmetro label para aplicar nomes fáceis de usar a dimensões ou medidas, mantendo os nomes amigáveis ao banco de dados nos arquivos de visualização e modelo. Você pode renomear alguns termos comuns, como Contagem para Número de e Soma para Total. Se você não tiver certeza de quais palavras são significativas para os usuários, trabalhe com um usuário empresarial para criar algumas consultas comuns e veja quais palavras os resultados da consulta usam para descrever o que os usuários estão procurando. Por exemplo, suponha que as visualizações Itens de inventário, Itens de pedidos, Pedidos e Produtos tenham uma medida chamada Contagem. É possível usar o parâmetro label para dar a cada uma dessas medidas um nome exclusivo e significativo, como Número de itens de inventário, Número de itens do pedido, Número de pedidos e Número de produtos.
Evite expor vários campos com o mesmo nome. Por exemplo, as medidas de type: count são criadas automaticamente no Looker com o nome Contagem. Isso faz com que a maioria dos arquivos de visualização contenha uma medida de contagem com o mesmo nome. Vários campos com o mesmo nome podem confundir os usuários. Adicionar rótulos ou renomear medidas de contagem para indicar o objeto que está sendo contado evita confusão. Outros campos a serem considerados incluem Data de criação e Data de atualização, como nos grupos de dimensões.
Dê nomes claros para os campos de type: yesno. Por exemplo, use O item foi devolvido? em vez de Devolvido para nomear um campo que indique se um item foi devolvido.
Nomeie as proporções de forma descritiva. Por exemplo, Pedidos por clientes que fazem compras é mais claro do que Porcentagem de pedidos.
Nomeie os campos e represente os valores de forma consistente no modelo. Usar o parâmetro value_format ou value_format_name para aplicar formatação, como símbolos de moeda, porcentagens e precisão decimal a campos numéricos, ajuda a deixar tudo mais claro para os usuários.
Agrupar campos semelhantes para facilitar a navegação
Use o parâmetro group_label para consolidar dimensões e medidas de visualizações individuais ou múltiplas vinculadas. Por exemplo, agrupe todas as informações geográficas em um grupo Geografia para reunir todas as informações de endereço e local no seletor de campos, em vez de listar tudo em ordem alfabética:
dimension: city {
group_label: "Geography"
type: string
sql: ${TABLE}.city ;;
}
dimension: country {
group_label: "Geography"
type: string
map_layer_name: countries
sql: ${TABLE}.country ;;
}
Divida tabelas grandes e desnormalizadas usando o parâmetro view_label. Use o parâmetro view_label nos campos para agrupar campos logicamente em títulos separados no seletor de campos. Tabelas grandes e desnormalizadas com muitos campos podem ser difíceis de navegar, o que cria a ilusão de várias visualizações no seletor de campos do recurso "Explorar" à esquerda.
Evite expor muito aos usuários inicialmente
Evite expor muito aos usuários no lançamento inicial do Looker. Comece aos poucos e depois amplie as opções. Não é preciso expor todas as tabelas ou dimensões e medidas de uma só vez. Você pode expor os campos mais importantes no início e, em seguida, continuar a desenvolver mais funcionalidades à medida que os usuários da empresa se tornam mais confiantes na exploração de dados.
Ocultar dimensões que não são relevantes para os usuários na interface. Use o parâmetro hidden em dimensões que nunca serão usadas pela interface do usuário, como campos de ID ou datas de atualização do banco de dados.
Use o parâmetro fields nas Análises e nas mesclagens para limitar o número de campos disponíveis para os usuários. Inclua apenas os campos relevantes para a Análise detalhada. Isso reduz o inchaço e oferece uma experiência melhor para os usuários. Ao contrário do parâmetro hidden, o parâmetro field permite que os campos sejam incluídos ou excluídos de forma individual.
Ocultar as Análises que existem apenas para preencher Looks, blocos do painel ou filtros específicos usando o parâmetro hidden para Análises. As análises detalhadas que não são destinadas à exploração pelos usuários devem ser ocultas da interface do usuário.
Use o menor número possível de análises detalhadas, mas permita que os usuários acessem facilmente as respostas que precisam. Considere dividir as análises detalhadas em diferentes modelos para públicos-alvo distintos e limitar as opções disponíveis para cada grupo de usuários. O número ideal de análises é diferente para cada empresa, mas ter muitas delas tende a confundir os usuários. Use o parâmetro group_label para análises em um modelo, que permite agrupar as análises de maneira adequada no menu suspenso Análise.
Adicionar descrições para que os usuários saibam quais campos e análises usar
Use o parâmetro description em dimensões e métricas para fornecer mais informações aos usuários sobre a lógica ou os cálculos usados no modelo. Isso é especialmente importante para dimensões e métricas que usam cálculos ou lógica complexa. Dito isso, é uma boa ideia considerar descrições para campos mais simples para garantir que os usuários entendam as definições.
Defina descrições de exploração para os usuários. Adicione uma breve descrição a cada Análise para especificar o propósito dela e o público-alvo.
Criar fluxos de trabalho comuns no Looker
Adicione drill_fields a todas as medidas relevantes. Os campos de detalhamento permitem que os usuários cliquem em valores agregados para acessar dados detalhados. Use o parâmetro set para criar conjuntos reutilizáveis de campos que podem ser aplicados a qualquer número de medidas em uma visualização.
Adicione drill_fields a todas as dimensões hierárquicas. Por exemplo, adicionar um drill_field para Cidade em uma dimensão Estado permite que os usuários selecionem um estado e, em seguida, aprofundem em cidades dentro desse estado. Essa análise detalhada hierárquica será aplicada automaticamente nos grupos de dimensão de tempo.
Configure links que permitam aos usuários navegar e transmitir filtros com facilidade para outros painéis do Looker ou para sistemas ou plataformas externos. Consulte nossa
documentação sobre o parâmetro link para conferir exemplos de como transmitir filtros para exercícios.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-25 UTC."],[],[],null,["# Best practice: Create a positive experience for Looker users\n\n*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 you should use your best judgment when implementing.*\n\n\nLookML developers can consider following these tips to improve their users' experience with Looker:\n\n- [Provide users with meaningful field names](#1)\n- [Group similar fields together for easier navigation](#2)\n- [Avoid exposing too much to users initially](#3)\n- [Add descriptions so users know which fields and Explores to use](#4)\n- [Build common workflows into Looker](#5)\n\n\nThese recommendations are explained in further detail in the sections that follow.\n\nProvide users with meaningful field names\n-----------------------------------------\n\n- Use the [`label`](/looker/docs/reference/param-field-label) parameter to apply user-friendly names to dimensions or measures 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 some common queries, and see what words the query results use to describe what users are looking for. As an example, suppose the **Inventory Items** , **Order Items** , **Orders** , and **Products** views each have a measure called **Count** . You can use the `label` parameter to give each of these measures a unique and meaningful name, such as **Number of Inventory Items** , **Number of Order Items** , **Number of Orders** , and **Number of Products**.\n- Avoid exposing multiple fields with the same name. For example, measures of `type: count` 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 confuse 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 Date** and **Updated Date** , such as in [dimension groups](/looker/docs/reference/param-field-dimension-group).\n- Provide clear names for fields of [`type: yesno`](/looker/docs/reference/param-dimension-filter-parameter-types#yesno). For example, use **Was the Item Returned?** instead of **Returned** to name a field that indicates whether an item has been returned.\n- Name ratios descriptively. For example, **Orders Per Purchasing Customers** is clearer than **Orders Percent**.\n- Name fields and represent values consistently across the model. Using the [`value_format`](/looker/docs/reference/param-field-value-format) or [`value_format_name`](/looker/docs/reference/param-field-value-format-name) parameter to apply formatting such as currency symbols, percentages, and decimal precision to numerical fields will help make everything clearer to your users.\n\nGroup similar fields together for easier navigation\n---------------------------------------------------\n\n- Use the [`group_label`](/looker/docs/reference/param-field-group-label) parameter to consolidate dimensions and measures from individual or multiple joined views that are related. For example, group all geographic information into a **Geography** group to pull all address and location information together within the field picker, rather than having it all listed alphabetically: \n\n ```\n dimension: city {\n group_label: \"Geography\"\n type: string\n sql: ${TABLE}.city ;;\n }\n\n dimension: country {\n group_label: \"Geography\"\n type: string\n map_layer_name: countries\n sql: ${TABLE}.country ;;\n }\n \n ```\n\n\n- Break up large, denormalized tables using the [`view_label`](/looker/docs/reference/param-field-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.\n\nAvoid exposing too much to users initially\n------------------------------------------\n\n- 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 most important fields at first and then continue to build in more functionality as business users become more confident with data exploration.\n- Hide dimensions that are not relevant to users from the user interface. Use the [`hidden`](/looker/docs/reference/param-field-hidden) parameter on dimensions that will never be used through the user interface (such as ID fields or database update dates).\n- Use the [`fields`](/looker/docs/reference/param-explore-join-fields) parameter within Explores and joins to limit the number of fields that are available to users. Included fields should be only those relevant to the Explore. This reduces bloat and provides a better experience for users. Unlike the `hidden` parameter, the `field` parameter enables fields to be included or excluded on an Explore-by-Explore basis.\n- Hide any Explores that exist solely for populating specific Looks, dashboard tiles, or filters using the [`hidden` parameter for Explores](/looker/docs/reference/param-explore-hidden). Explores that are not meant for exploration by users should be hidden from the user interface.\n- 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](/looker/docs/access-control-and-permission-management#controlling_feature_and_data_access). The optimal number of Explores is different for every business, but having too many Explores tends to confuse users. Consider using the [`group_label`](/looker/docs/reference/param-explore-group-label) parameter for Explores within a model, which will let you group them in a sensible way within the **Explore** drop-down menu.\n\nAdd descriptions so users know which fields and Explores to use\n---------------------------------------------------------------\n\n- Use the [`description`](/looker/docs/reference/param-field-description) parameter on dimensions and measures to provide additional information to users about the logic or calculations that are used within the model. This is particularly important for dimensions and measures that leverage complex logic or calculations. That being said, it's a good idea to also consider descriptions for simpler fields to be sure that users understand the definitions behind them.\n- Define [Explore descriptions](/looker/docs/reference/param-explore-description) for users. Add a short description to each Explore to specify the purpose of the Explore and the audience who will use it.\n\nBuild common workflows into Looker\n----------------------------------\n\n- Add [`drill_fields`](/looker/docs/reference/param-field-drill-fields) to all relevant measures. Drill fields enable users to click into aggregate values in order to access detailed data. Use the [`set`](/looker/docs/reference/param-view-set) parameter to create reusable sets of fields that can then be applied to any number of measures within a view.\n- Add [`drill_fields`](/looker/docs/reference/param-field-drill-fields) to all hierarchical dimensions. For example, adding a `drill_field` for **City** into a **State** dimension will let users 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.\n- Set up links that enable users to easily navigate and pass filters to other Looker dashboards or to systems or platforms that are external to Looker. See our [documentation on the `link` parameter](https://docs.looker.com/reference/field-params/link?lookml=new#passing_a_querys_filter_values_into_a_link) for examples of passing filters through drills."]]
