01
Nova terminologia e novos campos.
Mudança de terminologia
O que antes chamávamos de achado agora se chama sinal (sinal de futuro) — é o termo do foresight pros padrões que o radar cataloga. A partir desta atualização, o time adota "sinal" em todos os artefatos novos.
Pendência
A documentação oficial anterior (radar-de-futuros.md, o PDF e o Guia Essencial) ainda usa "achado" e precisa ser atualizada — bem como referências em pesquisa.html e no index.html do hub.
Novos campos por sinal
Cada sinal agora tem três campos adicionais que mapeiam suas relações com outros sinais do radar. Não são textos livres — são listas de sinais relacionados:
- Sinais que impulsionam — quais outros sinais podem fazer este crescer ou ganhar força.
- Sinais que tensionam — quais outros sinais, se consolidados, podem frear ou dificultar este sinal de se consolidar.
- Desdobramentos deste sinal — quais outros sinais serão impulsionados se este se estabelecer.
Implicações pro design
- O modelo de dados ganha relações grafo-like entre sinais. O radar deixa de ser só um catálogo plano e vira uma rede.
- Na página de detalhe do sinal, vale prever um bloco "Sinais relacionados" com as três categorias claramente separadas (impulsionam / tensionam / desdobramentos), cada uma com sua lista clicável.
- No canvas do radar, abre possibilidade de destacar visualmente os sinais conectados quando o usuário foca um — linhas, halos, atenuação dos desconectados, etc.
- No formulário público de sugestão, vale conversar com o Alcir se a comunidade preenche esses campos relacionais ou se a definição das relações fica a cargo do Comitê (provavelmente o segundo).
- Em filtros e exploração, abre caminho pra recortes do tipo "ver tudo o que impulsiona este sinal" ou "ver o cone de desdobramentos a partir dele".
02
Tokens do Hub Wireframe.
Aplicados após análise do Figma DS V3 + inspeção do site sicredipioneira.com.br ao vivo. Documentados aqui pra Moema/time ajustar se necessário.
Tipografia (Google Fonts)
- Exo 2 — display, headings, labels caps. Pesos: 400 / 500 / 600 / italic 400–500.
- Nunito — body, parágrafos, descrições. Pesos: 400 / 500 / 600 / 700.
Cores
| Token | Hex | Uso |
|---|
| --accent | #3FA110 | Verde Sicredi primary (CTA, highlights, kickers) |
| --accent-dark | #146E37 | Verde escuro institucional (reservado) |
| --accent-soft | #EAF5E0 | Verde claro de fundo (placeholders de imagem) |
| --ink | #323C32 | Texto principal |
| --ink-2 | #5C6B5C | Texto secundário |
| --ink-3 | #9CAA9C | Texto terciário, ícones discretos |
| --bg | #FAFAFA | Background da página |
| --surface | #FFFFFF | Background de cards |
| --rule | #E5E5E5 | Bordas, divisores |
| --warn | #B3463A | "Fracos" nos cards de referência |
Escala tipográfica
- Hero (Display 1): Exo 2 SemiBold (600), 48–88px, leading 1.05
- H2 de seção: Exo 2 Medium (500), 32–34px, leading 1.15
- H4 de card: Exo 2 Medium (500), 22–28px, leading 1.2
- Labels caps: Exo 2 Regular (400), 10–11px, letter-spacing 0.14–0.16em, uppercase
- Body: Nunito Regular, 14–18px, leading 1.55–1.7
Decisões editoriais que não vêm do DS
Livre adaptação, podem mudar:
- Italic acentuado em verde no hero — escolha editorial pra dar personalidade ao hub. O DS não prescreve isso, mas Exo 2 italic existe e ficou bem.
- Uso de Exo 2 caps com letter-spacing no lugar de uma família monospace — alinhado com o estilo "Capitalized" e "Tag" do DS.
- Cards com borda de 1px e radius 10–12px — escolha visual, o DS provavelmente define isso de outro jeito.
Quando o DS oficial estiver mais maduro/publicado, dá pra revisitar essas escolhas.
03
Escopo do trabalho de design.
Estamos desenhando apenas a área pública do Radar de Futuros. Tudo o que é administrativo está fora do nosso escopo.
Dentro do escopo
- A visualização pública do radar (o canvas circular, com seus filtros, legendas, painel de detalhe do sinal).
- A sugestão de novos sinais pela comunidade (formulário público de envio).
- Páginas complementares do site institucional — Comitê, Ferramentas, Publicações, Chamadas, História — a serem abordadas mais adiante no projeto.
Fora do escopo
O admin do radar, onde o Comitê de Futuro registra, aprova e edita sinais. Tudo que se refere a fluxos administrativos (CRUD de sinais, gestão da lista de megatendências, parecer do Comitê, controle de acesso, logs) não será desenhado por nós. O Guilherme cuida desse lado.
04
Modelo visual do Radar 2.0.
A versão 2.0 muda como o radar se organiza visualmente em relação à documentação oficial. Importante seguir este modelo, não o da documentação original, ao desenhar a visualização.
O que mudou nos eixos visuais
| Eixo do radar | Documentação oficial | Modelo 2.0 (vigente) |
|---|
| Anéis (do centro pra fora) | Ação recomendada — Agir, Preparar, Observar | Igual — Ação recomendada |
| Setores (fatias do círculo) | Aspectos STEEP (5 fatias fixas) | Megatendências (n fatias, dinâmico) |
STEEP continua existindo — só não é visual
O aspecto STEEP segue sendo um campo obrigatório de cada sinal, registrado como classificação de dados. Ele simplesmente não é mais um eixo da visualização do radar. Pode aparecer como filtro, badge, metadado no painel de detalhe — mas não estrutura a posição do sinal no canvas.
Número de fatias deixa de ser fixo
Como a lista de megatendências é gerenciável pelo Comitê (cresce, encolhe e muda ao longo do tempo), o radar precisa acomodar visualmente um número variável de fatias. Isso afeta diretamente o desenho do canvas — não dá mais pra assumir 5 setores fixos como no STEEP.
05
Obrigatoriedade da megatendência.
Existem duas perspectivas sobre se um sinal precisa ter megatendência, e elas parecem se contradizer mas não se contradizem:
- Do ponto de vista do backend: megatendência é opcional. É uma salvaguarda técnica: se o Comitê excluir uma megatendência no admin, os sinais que estavam ali não somem junto — eles ficam temporariamente sem megatendência até serem realocados.
- Do ponto de vista do design (área pública): megatendência é obrigatória. Todo sinal precisa pertencer a uma megatendência para ser posicionado em alguma fatia do radar. Não existe estado válido de "sinal público sem megatendência" na visualização.
Regra pro design
O formulário público de sugestão de novo sinal exige que o usuário escolha uma megatendência. A visualização não precisa prever o estado "sem megatendência" — esse estado só existe transitoriamente no admin e nunca chega ao público.
06
Outras decisões e contexto.
Documentação oficial que continua válida
O radar-de-futuros.md (e o PDF equivalente) descreve corretamente — embora ainda usando o termo "achado" (ver atualização de terminologia na seção 01):
- O conceito do sinal e suas classificações (Tipo, Relevância, Maturidade, Chance de ocorrência, Impacto na região, Inovação e engajamento).
- Os 4 tipos de sinal (Tendência, Sinal Fraco, Evento Raro, Cisne Negro Local). Cuidado com a sobrecarga terminológica: "Sinal Fraco" é um tipo de sinal, diferente do termo guarda-chuva "sinal".
- A lista atual de megatendências (ponto de partida).
- A descontinuação de "Cenários Futuros" e "Pilares Estratégicos".
- A renomeação de "Impacto" para "Relevância" e "Cisne Negro Global" para "Evento Raro".
Restrições técnicas do público
Usuários da cooperativa frequentemente acessam de notebooks com resolução 1366×600 (Chromebooks antigos). O design da visualização precisa funcionar bem nesse tamanho.
Time do projeto
- Moema Lange — UX/UI (Dois na Oito).
- Guilherme Kaiser — backend, admin, comunicação com cliente (Dois na Oito).
- Jonathan Aires — referências visuais e de interação (Dois na Oito).
- Alcir — cliente/responsável na Sicredi Pioneira. Super disponível. Mergulhou principalmente na visualização do radar; outras áreas estão cruas e abertas à proposta do time.
Design system
O projeto está congelado no design system antigo da Pioneira até o novo ser publicado. Não vale partir pro novo antes do release oficial — risco de retrabalho.