> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-pt/scenes-sdk7/conceber-a-experiencia/ux-ui-guide.md).

# Guia de UX e UI

Dicas e práticas para criar cenas nas quais os jogadores vão querer ficar e voltar!

É de vital importância para nós que os criadores de conteúdo do Decentraland tenham liberdade para usar a sua criatividade ao máximo. Isto é essencial para que o Decentraland se torne um lugar gratificante para explorar. No entanto, também é importante ter em mente que as scenes no Decentraland serão visitadas por uma grande variedade de utilizadores e queremos tornar as scenes acessíveis a todos eles. Por isso, não podemos ignorar a necessidade de estabelecer critérios de design unificados, um guia que possa garantir que os jogadores se encontrarão com uma experiência homogénea, intuitiva e agradável, independentemente da scene em que estejam.

Neste documento partilhamos os Valores de Design do Decentraland, com o objetivo de promover o que consideramos serem as melhores práticas para conceber a interface e a experiência dos jogadores. Esperamos que estes critérios possam servir como ponto de partida para construir e/ou melhorar as scenes que compõem o Metaverse.

## Valores de design

Todas as scenes no Decentraland devem ser concebidas tendo estes valores em mente:

* **Acolhedor**: O jogador sente-se calorosamente bem-vindo.
* **Fácil de usar**: A UI é fácil e divertida de usar – deve evitar reinventar a roda
* **Fácil de aprender**: Os jogadores acham a UI familiar e intuitiva. Os padrões devem ser usados de forma consistente ao longo de toda a scene.
* **Fornecer orientação**: A scene dá uma ajuda. Texto, movimento, som e gráficos vão guiar e indicar aos jogadores a direção certa.
* **Reativo**: Ação-reação clara ao input dos jogadores.
* **Minimalista**: Menos é mais. Os jogadores podem concentrar a sua atenção no que importa.
* **Interessante**: A scene tira partido das coisas que tornam o Decentraland único e digno de ser visitado.
* **Com propósito**: Os jogadores têm uma forte razão para voltar.
* **Agradável**: Os jogadores apreciam a forma como as coisas se parecem, soam e se sentem

## Experiência do utilizador

### Por onde começar?

Qual é o objetivo da sua scene? É oferecer uma paisagem bonita para contemplar e explorar? É um museu? É um jogo para um jogador? Um competitivo? Ou segue um fluxo narrativo linear?

É importante estar bem consciente deste objetivo em cada passo do processo de design; ele deve orientar todas as suas decisões, as quais podem afetar profundamente a experiência do visitante.

Para scenes que seguem um fluxo linear, em que cada passo depende do anterior, recomendamos fechar a scene com paredes e estabelecer um ou vários pontos de entrada fixos, para evitar que os jogadores encontrem coisas pela ordem errada. Aliás, os pontos de entrada são um excelente local para exibir uma mensagem a dar as boas-vindas ao jogador e explicar qual deve ser o objetivo dele na scene.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-97ebd53471da877dec44f02a12a433af644d458a%2Fux-instructions.png?alt=media" alt="In-world banner" width="800"><figcaption><p>Instruções no mundo</p></figcaption></figure>

Se a experiência do jogador na sua scene não se destinar a ser linear, mas ainda assim precisar de fornecer algumas instruções básicas para garantir que ele a aproveita ao máximo, pode mostrar instruções num pop-up. É possível exibir um popup no ecrã do jogador assim que este entra, independentemente da direção de onde venha, e dessa forma garantir que os jogadores saberão sempre o essencial.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-8a74df26bf66f63d5d103d0c9ee5a4cd8323ddd1%2Fux-banner.png?alt=media" alt="Pop-up banner" width="800"><figcaption><p>Instruções em pop-up</p></figcaption></figure>

{% hint style="warning" %}
**📔 Nota**: Certifique-se de que o popup não é demasiado intrusivo e de que é fácil de fechar ao clicar em qualquer lado.
{% endhint %}

Uma mensagem de boas-vindas deve comunicar o seguinte ao jogador:

* O título da scene
* Dar as boas-vindas ao jogador
* Objetivo final e motivação para o jogador
* Instruções/Próximos passos
* *(Opcional)* Controlos. Maioritariamente útil se a sua scene usar eventos globais de botão. Caso contrário, os próprios itens indicam como utilizá-los quando se passa o cursor por cima deles.

### Motivação

Provavelmente vai querer que os seus visitantes continuem a voltar à sua scene; pense em formas de os motivar a fazê-lo! Pergunte a si próprio: “O que faria um jogador querer regressar à minha scene, ou querer recomendá-la a um amigo?”

Por exemplo, pode desafiá-los, dando-lhes algo para alcançar que seja suficientemente difícil para exigir várias tentativas. Também pode organizar eventos multijogador competitivos, que são igualmente uma oportunidade interessante para socializar. Torne a sua scene num lugar dinâmico onde os jogadores sintam que gostam de passar tempo lá!

### Feedback e som

O som desempenha um duplo papel fundamental, não perca a oportunidade de o usar! Por um lado, é vital para gerar imersão; muitas coisas não parecerão reais se não forem acompanhadas por som. A outra função crucial do som é fornecer feedback às ações do jogador. Se depender apenas de pistas visuais, não pode ter a certeza de que o jogador estará a olhar na direção certa para ver os efeitos das suas ações. Ao usar som, pode garantir que ele perceba que algo aconteceu. Se usar pistas visuais e sonoras em combinação, ouvir o som convida o jogador a olhar em volta à procura da pista visual, caso não a tenha visto.

Tenha em mente que alguns jogadores podem estar a jogar com o som desligado. Se estiver a usar som como forma de fornecer instruções da scene ou uma peça-chave na mecânica do jogo, tente também fornecer algo visual para apontar na mesma direção. Por exemplo, pode exibir texto na parte inferior da UI para acompanhar estes sons, como legendas num filme.

## Interface do utilizador

Esta secção tem como objetivo ajudá-lo a construir uma narrativa através do design da sua scene que direcione o foco do jogador para os elementos que mais importam. Fazer bom uso das ferramentas descritas aqui pode tornar a experiência dele muito mais imersiva e bem-sucedida.

Não podemos subestimar o quão valiosos são a cor, os ícones, o movimento e a escala para transmitir a mensagem certa: tudo na scene comunica um significado, lembre-se disso.

### Disposição

Tenha cuidado ao colocar a sua UI em regiões do ecrã que se sobreponham aos elementos predefinidos da UI do Decentraland. No cliente de desktop, a UI predefinida do Decentraland (sidebar, minimapa, chat, etc.) foi concebida para ocupar apenas os 25% à esquerda do ecrã (destacados a vermelho na imagem). O espaço restante do ecrã é uma zona segura que os criadores de conteúdo podem usar livremente.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-dd66dfc723550792844114dde7e60be4127d5d64%2FUI-Zones.png?alt=media" alt="Screen regions used by UI" width="800"><figcaption></figcaption></figure>

Não existem restrições para colocar elementos de UI nos 25% à esquerda do ecrã, mas tenha em mente que o Explorer está continuamente a fazer alterações e melhorias ao seu design. Qualquer espaço que hoje não esteja ocultado nessa região poderá ser coberto em versões futuras.

{% hint style="info" %}
**📱 Área segura móvel**: O [cliente móvel](/creator/content-creator-pt/criar-para-mobile/cliente-movel/overview.md) desenha os seus próprios controlos sobre parte do canvas: a **parte esquerda** (chat, pesquisa, perfil, joystick, emotes), o **canto superior direito** (controlos de perfil e câmara), e o **canto inferior direito** (botões de ação e interação). Não meça essas regiões à mão: renderize dentro da área que o cliente reporta, com `screenInset: 'interactable'`. Mantenha a UI crítica no centro ou no centro superior do ecrã e siga o [Área segura do mobile](/creator/content-creator-pt/criar-para-mobile/desenvolver/safe-area.md). Use [`isMobile()`](/creator/content-creator-pt/criar-para-mobile/desenvolver/detect-platform.md) para alternar layouts quando as restrições de desktop e mobile não coincidirem.
{% endhint %}

{% hint style="warning" %}
**📔 Nota**: Os elementos de UI de scenes e smart wearables aparecem sempre numa layer atrás da UI predefinida do Decentraland.
{% endhint %}

#### Nunca ancore sua UI no canto superior esquerdo

O erro de layout mais comum é fixar um painel no canto superior esquerdo, ou deixá-lo na origem de um root que cobre o ecrã. Esse canto, e toda a margem esquerda, é onde o Explorer desenha o seu minimapa e chat, e no mobile o joystick virtual. A UI da scene colocada aí continua a ser renderizada, mas a própria UI do cliente é desenhada por cima dela, pelo que acaba coberta e os seus botões muitas vezes não podem ser clicados. Nada no layout engine o avisa sobre isto.

Use antes uma destas opções:

* **Afixe à direita, ou centre o elemento.** Para uma pontuação, um temporizador ou um pequeno painel, defina `positionType: 'absolute'` e `position: { top: 40, right: 40 }`, ou centre-o com `justifyContent: 'center'` na root.
* **Deixe o Explorer indicar-lhe onde é seguro.** Defina [`screenInset: 'interactable'`](/creator/content-creator-pt/scenes-sdk7/ui-2d/onscreen-ui.md#screen-inset-area) no renderer. A sua UI é então colocada dentro do retângulo que o Explorer reserva para a UI da scene, o qual já exclui o minimapa, o chat e os controlos do lado esquerdo.

```ts
ReactEcsRenderer.setUiRenderer(uiComponent, { screenInset: 'interactable' })
```

No mobile, os botões de ação no canto inferior direito são desenhados de propósito por cima dessa área, e os toques aí vão para os botões do cliente em vez de irem para a sua scene. Mantenha os elementos interativos afastados do canto inferior direito ou, para uma UI que de qualquer forma ocupe o ecrã inteiro, oculte os controlos táteis enquanto ela estiver aberta:

```ts
import { TouchScreenControls } from '@dcl/sdk/ecs'

// enquanto um painel de ecrã inteiro está aberto, o jogador não precisa de saltar nem de premir E
TouchScreenControls.hideAll()
TouchScreenControls.hideJoystick()

// restaure-os quando o painel se fechar
TouchScreenControls.showAll()
TouchScreenControls.showJoystick()
```

Estes helpers não fazem nada no desktop, por isso pode chamá-los incondicionalmente. Veja [Controles na tela](/creator/content-creator-pt/scenes-sdk7/interatividade/touch-screen-controls.md).

Tenha sempre uma grid em mente e use-a como o seu principal critério ao organizar espacialmente a sua UI. Se estiver a trabalhar numa scene em que seja necessário um HUD, pode começar por reunir todos os consumíveis (por exemplo, moeda, comida, vida) e, do outro lado, os itens armazenáveis, como ferramentas ou armas. Tente ser consistente quanto às métricas da grid e ao padding. Torne claro o feedback para cada ação do jogador.

### Cor

É importante escolher uma paleta de cores, pois isso dá identidade à sua scene e também assinala relações e hierarquia entre elementos.

Ao montar uma paleta de cores, comece por selecionar uma cor principal e, opcionalmente, uma secundária. Depois deve decidir se quer que a paleta seja análoga, complementar ou triádica, etc., em relação a essa cor principal.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-90a514428232e163d5b6012aa8ab57371da92782%2Fux-color-wheel2.png?alt=media" alt="Chromatic color palette" width="300"><figcaption><p>Paleta de cores cromática</p></figcaption></figure>

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-a557422ba97313b5ac752e934e90f55206640145%2Fux-color-wheel.png?alt=media" alt="Strategies for combining colors properly" width="300"><figcaption><p>Estratégias para combinar cores corretamente</p></figcaption></figure>

{% hint style="info" %}
**💡 Dica**: Geradores gratuitos de paletas de cores que recomendamos: [Coolors](https://coolors.co), [Adobe Color CC](https://color.adobe.com/), [Colour Lovers](http://www.colourlovers.com), [Color Hunt](http://www.colorhunt.co), [Color by Hailpixel](http://color.hailpixel.com), [Colour Code](http://colourco.de), [Sip](https://sipapp.io/), [Color Scheme Designer by Paletton](http://paletton.com), [Cohesive Colors](http://javierbyte.github.io/cohesive-colors), [Colr](http://www.colr.org)
{% endhint %}

A cor principal deve ser a mais frequentemente usada ao longo dos componentes da sua UI. Se a sua paleta não tiver uma cor secundária, pode realçar elementos combinando a cor principal com preto ou branco. Ter uma cor secundária não é obrigatório, mas ajuda a enfatizar e distinguir os elementos da UI da sua scene. As cores secundárias funcionam melhor para destaques, controlos de seleção (sliders e switches), links e títulos.

Lembre-se de que cada cor tem as suas próprias qualidades expressivas únicas; tire partido disso para comunicar mensagens através delas. Por exemplo, o vermelho é muitas vezes associado a conotações negativas, enquanto o verde está associado a conotações positivas.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-39fa7214733c589571654b3b05067edae03d2353%2Fux-switches.png?alt=media" alt="Colored switches" width="300"><figcaption><p>Usar a cor da forma errada pode ser confuso</p></figcaption></figure>

Também pode usar cores estrategicamente para indicar alterações de estado; por exemplo, mudar a cor de um elemento para indicar se está ativo ou inativo.

{% hint style="warning" %}
**📔 Nota**: Os estados comunicam o estado dos elementos da UI. Os estados de um elemento devem manter uma certa continuidade, mas têm de ter affordances claras e ser facilmente distinguíveis de outros estados e da disposição envolvente.
{% endhint %}

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-ccb8ecfe2c2b624018c96ecb9317c494c44dbeb9%2Fux-active-button.png?alt=media" alt="Active inactive button" width="300"><figcaption><p>Usar cor nos estados dos botões</p></figcaption></figure>

Atenção! Ao selecionar cores que serão mostradas em superposição, tenha especial cuidado em garantir que são legíveis quando usadas em conjunto. Aqui está uma regra fundamental: as cores dos elementos que são mostrados em conjunto devem sempre ter bastante contraste entre si. Tenha em conta que alguns jogadores poderão estar a olhar para os seus ecrãs sob condições de iluminação subótimas, o que dificulta a leitura.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-febc1a60718f42d58120c40515664253cf09a363%2Fux-icons.png?alt=media" alt="Icon contrast" width="300"><figcaption><p>Ambos os ícones podem ser distinguidos, mas o primeiro tem melhor contraste. Torna-se mais fácil de ler e exige menos esforço para compreender.</p></figcaption></figure>

### Hierarquia tipográfica

Tente definir pelo menos uma escala de 3 tamanhos para Títulos, Subtítulos e Corpo. Tenha cuidado com a utilização da cor e do tamanho do tipo de letra. Todos os tamanhos de letra devem ser de 12 px ou superiores.

Se for colocar texto exibido sobre imagens (ou sobre o mundo), certamente terá de experimentar a sua legibilidade. Nesses casos, sugerimos que adicione uma região sólida com cor, numa layer entre o texto e as imagens; dessa forma, pode garantir que o texto permanece legível.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-9a277a4a94c7904455781552939bac4bf90c0403%2Fux-text-over-images.png?alt=media" alt="Text over images" width="300"><figcaption><p>Priorize a legibilidade</p></figcaption></figure>

### Ícones

Os ícones sintetizam informação, ajudando-o a identificar ações através de imagens. São uma ferramenta incrivelmente poderosa para fornecer input que pode ser interpretado rapidamente, em oposição a usar texto para rotular coisas, o que exige mais atenção e tempo ao jogador. Também é útil mostrar ícones em combinação com texto, pois isso ajuda a desambiguar os seus significados.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-cdcdf8db8cd023d3550881b30f3ab56dc818ac9d%2Fux-icons2.png?alt=media" alt="Icon examples" width="300"><figcaption><p>Use ícones como uma linguagem universal</p></figcaption></figure>

### Movimento

Use o movimento para fornecer feedback e guiar o caminho quando necessário. O movimento ajuda os jogadores a concentrar a sua atenção e ajuda a manter a continuidade à medida que a UI muda.

<figure><img src="https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-0a13840d235b318e369b3dc11ea4272633b8c0b4%2Fux-glow.png?alt=media" alt="Adding glow" width="300"><figcaption><p>Use partículas, escala ou margens esbatidas para fazer as coisas destacarem-se</p></figcaption></figure>

### Escrita e estrutura do conteúdo

O texto da UI pode tornar as interfaces mais utilizáveis e dar aos jogadores mais confiança nas suas ações. Torne sempre o texto da UI o mais conciso possível. Os jogadores estão lá para jogar, não para ler. Qualquer texto que pareça demasiado longo não será lido pela maioria dos jogadores.

Receba os seus jogadores com uma Mensagem de Boas-vindas e diga-lhes o objetivo da scene. Comece por esclarecer o objetivo deles na scene e, depois, as ações necessárias para o alcançar. Em seguida, pode revelar informação progressivamente à medida que for necessária; assim, os jogadores não se sentirão sobrecarregados logo no início da experiência. Tal como com os recursos gráficos, tente usar palavras consistentes ao longo das suas funcionalidades de UI e da narrativa.

#### Mostre, não conte

Dois padrões perdem jogadores antes da sua primeira interação:

* **O pop-up das regras**: um painel de introdução com vários parágrafos densos que cobrem todas as mecânicas, regras de pontuação e controlos. Os jogadores fecham-no sem o ler.
* **O manual de regras no mundo**: os mesmos parágrafos numa placa ou num quadro na scene. Parece design, mas o texto no mundo é demasiado pequeno e demasiado longo para ler, e os jogadores não vão ficar parados a semicerrar os olhos para o ler.

Mantenha um painel de introdução num único ecrã, sem scrolling: 3 a 5 linhas curtas, idealmente uma linha para o objetivo, uma linha para os controlos e uma imagem. Uma placa deve dizer apenas uma coisa, em 10 palavras ou menos, com um tamanho de letra grande, com uma placa por ideia.

Depois mostre o resto em vez de o escrever:

* Torne o primeiro alvo inconfundível. Coloque um objeto brilhante, animado ou de tamanho exagerado na linha de visão inicial do jogador. Um contorno pulsante ensina "clique em mim" melhor do que uma frase.
* Permita que o jogador execute uma mecânica uma vez, em segurança, numa área de prática, antes de o jogo real começar.
* Usa `hoverText` em entidades interativas como uma instrução just-in-time. Aparece exatamente quando é relevante e não exige leitura prévia. Veja [Feedback ao passar o cursor](/creator/content-creator-pt/scenes-sdk7/interatividade/eventos-de-botao/register-callback.md#hover-feedback).
* Use um diagrama para regras espaciais ou de sequência. Uma imagem de "gemas vermelhas = 1, gemas azuis = 5" substitui um parágrafo.
* Apresente qualquer coisa mais longa uma mensagem de cada vez, através de um NPC ou de um diálogo que o jogador possa saltar.

Se uma regra precisar de mais texto do que isso, reprojete a mecânica ou mostre-a visualmente.

### Interações com objetos

Certifique-se de que os jogadores conseguem distinguir quais objetos são interativos e quais não são. Ao registar eventos de botão numa entity, o SDK apresenta feedback ao passar o cursor por omissão: um destaque na borda da entity e uma dica junto ao cursor a mostrar que input usar, com texto personalizado para descrever os efeitos de interagir com ela. Recomendamos vivamente que o use; a sua scene parecerá mais natural e fácil de usar. Veja [Feedback ao passar o cursor](/creator/content-creator-pt/scenes-sdk7/interatividade/eventos-de-botao/register-callback.md#hover-feedback).

### Câmara de 3.ª pessoa

Os jogadores podem alternar entre a câmara de 1.ª e de 3.ª pessoa em qualquer momento, premindo a tecla ‘V’. Conceba a sua scene para que as interações funcionem confortavelmente em ambos os modos: por exemplo, alvos de clique pequenos são mais difíceis de acertar em 3.ª pessoa. A sua scene pode ler o modo de câmara atual do jogador ou forçar um específico numa área; veja [Câmara](/creator/content-creator-pt/scenes-sdk7/fundamentos-de-conteudo-3d/camera.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-pt/scenes-sdk7/conceber-a-experiencia/ux-ui-guide.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
