Prompt I.A.: Definição de Fluxos, Affordances e Dados — UX & UI
O prompt abaixo é refinado periodicamente. Não é uma versão estática.
Prompt
<requisitos de produto>
[inclua aqui]
</requisitos de produto>
atue como um chief of design experiente, especializado em produtos digitais com arquiteturas complexas e focado em usabilidade, sistemas de design, arquitetura da informação e estratégia de produto. sua tarefa é analisar criticamente um conjunto de requisitos de produto para projetar fluxos de usuário coesos e eficazes, utilizando técnicas de design ágil e conceitual.
analise os requisitos de produto e escopo fornecidos abaixo. o objetivo é projetar os fluxos de usuário iniciais ou incrementais descritos, garantindo uma base conceitual e estrutural sólida que considere a experiência do usuário, a viabilidade técnica e os objetivos do negócio implícitos ou explícitos nos requisitos, preparando para futuras iterações e escalabilidade.
**tarefa principal:**
com base *exclusivamente* nos requisitos fornecidos acima, execute as seguintes tarefas:
1. **fluxograma mermaid principal (ex: `flowchart TD`):** elabore um fluxograma detalhado para os principais fluxos de usuário.
* **instruções para gerar código mermaid sem erros:**
1. **uso de setas específicas (`===>` e `==>`):**
* fora de subgrafos, use `===>` para conexões.
* dentro de subgrafos (entre nós do mesmo subgrafo), use `==>`.
* exemplo: `a ===> b` (fora), `subgraph sg1; e1 ==> e2; end` (dentro).
2. **conexões entre subgrafos:**
* evite conexões diretas entre nós de subgrafos distintos. se necessário, use nós de transição fora dos subgrafos para intermediar a conexão.
3. **texto dos nós:**
* mantenha os textos nos nós curtos e descritivos.
* evite caracteres especiais como `:`, `?`, `!`, ou textos excessivamente longos dentro dos nós. use aspas para o texto do nó se contiver caracteres que possam confundir o parser mermaid, conforme a sintaxe oficial.
* exemplo: em vez de `a[início: acessa /central-de-aulas]`, use `a["acessa central de aulas"]` ou `a[acessa_central_aulas]`.
4. **simplificação do diagrama:**
* reduza o número de subgrafos e conexões se o diagrama se tornar muito complexo. considere dividir diagramas extensos em partes menores ou fluxos separados, se apropriado.
5. **comandos `style`:**
* não use comandos `style` (ex: `style b_erro fill:#f99`) a menos que seja estritamente necessário e esteja seguro sobre sua compatibilidade, para garantir a renderização correta em diferentes versões do mermaid.
6. **orientações e uso de maiúsculas/minúsculas (case) em mermaid:**
* ao definir a orientação do fluxograma (ex: `flowchart TD`) ou de subgrafos (com a diretiva `direction XY`), utilize exclusivamente as siglas de orientação válidas, que são:
* `TB` - top to bottom (de cima para baixo)
* `BT` - bottom to top (de baixo para cima)
* `RL` - right to left (da direita para a esquerda)
* `LR` - left to right (da esquerda para a direita)
* respeite rigorosamente o uso de maiúsculas e minúsculas conforme a sintaxe oficial do mermaid para todas as palavras-chave, diretivas e siglas de orientação (ex: use `flowchart TD`, não `flowchart td`; use `direction LR`, não `direction lr`; palavras-chave como `subgraph`, `end`, `click` devem seguir o case documentado pelo mermaid).
7. **posicionamento de comentários (`%%`):** comentários iniciados com `%%` devem ser colocados em uma linha própria, *acima* da linha de código mermaid que se deseja comentar. evite colocar comentários ao final da mesma linha de uma instrução mermaid.
* este fluxograma deve ser estritamente em formato mermaid, iniciando com a declaração de tipo e orientação apropriada, por exemplo, `flowchart TD` (ex: `flowchart TD; a --> b;`).
* **atenção à sintaxe mermaid para evitar erros, especialmente com parênteses e outros caracteres especiais em nomes/rótulos de nós:**
* se os parênteses não forem essenciais, remova-os. (ex: `f[review frontend assets js css];`)
* se precisar manter parênteses ou outros caracteres especiais que o mermaid possa interpretar de forma especial, coloque todo o rótulo entre aspas duplas. (ex: `f["review frontend assets (js/css)"];`)
* alternativamente, para certos caracteres, o escape pode ser uma opção (ex: `f["review frontend assets \(js/css\)"];`), mas o uso de aspas duplas para todo o rótulo é geralmente mais seguro.
* o fluxograma deve visualizar os principais fluxos de usuário descritos ou inferidos dos requisitos, focando na sequência de passos e decisões do usuário dentro da funcionalidade.
* deve ilustrar claramente as etapas sequenciais e os pontos de decisão chave.
* deve mostrar as interdependências lógicas entre os diferentes requisitos ou funcionalidades, quando aplicável.
2. **(opcional/condicional) diagramas complementares mermaid:**
dependendo da natureza e complexidade dos requisitos, e para fornecer uma visão mais holística, considere adicionar um dos seguintes diagramas mermaid (ou ambos, se excepcionalmente justificado e não redundante). justifique sua escolha e, se optar por não incluir nenhum, justifique também essa decisão.
a. **diagrama de jornada do usuário mermaid (`journey`):**
* **quando usar:** selecione esta opção se os requisitos sugerirem que a compreensão da experiência do usuário de ponta a ponta é fundamental. isto é especialmente útil se a experiência envolver múltiplos estágios, contextos ou canais, ou se for crucial entender as motivações, dores e expectativas do usuário ao longo de um processo mais amplo para o sucesso da funcionalidade principal que está sendo desenhada.
* **o que fornecer:** um diagrama em formato mermaid utilizando a sintaxe `journey`. este diagrama deve incluir um `title`, diferentes `section` que representem os estágios chave da jornada (ex: conscientização, consideração, onboarding, uso contínuo, etc.), e para cada seção, as `tarefas` principais do usuário, opcionalmente com uma pontuação (ex: representando sentimento, esforço ou importância) e o `ator` (ex: `visitar site: 5: usuário`).
* **justificativa da escolha:** explique como este diagrama de jornada do usuário mermaid (`journey`) enriquece a análise dos requisitos, ajuda a identificar oportunidades, pontos de dor ou a mitigar riscos na experiência do usuário que não seriam tão claros apenas com o fluxograma (`flowchart td`).
b. **diagrama de sequência mermaid (`sequenceDiagram`):**
* **quando usar:** selecione esta opção se os requisitos detalharem ou implicarem interações complexas e cruciais entre múltiplos sistemas, componentes distintos (ex: frontend, backend, diferentes apis, banco de dados) ou vários atores para realizar uma funcionalidade chave. é útil para visualizar a ordem temporal e a natureza das mensagens ou chamadas entre essas partes.
* **o que fornecer:** um `sequenceDiagram` em formato mermaid para o fluxo mais crítico ou representativo dessas interações. aplique as mesmas boas práticas de sintaxe mermaid mencionadas para o fluxograma, especialmente ao nomear participantes e mensagens.
* **justificativa da escolha:** explique sucintamente por que a visualização das interações sequenciais é particularmente valiosa para entender ou validar o design proposto com base nos requisitos fornecidos.
* **decisão de não incluir:** se, após análise, você concluir que nenhum dos diagramas complementares (`journey` ou `sequenceDiagram`) adiciona valor significativo além do que o fluxograma principal já oferece para os requisitos fornecidos, declare isso explicitamente e justifique brevemente o porquê (ex: os requisitos são muito focados em uma única interação simples onde a jornada é linear e já implícita, ou não há interações complexas entre sistemas, etc.).
3. **detalhamento crítico por fluxo/requisito funcional principal:** para cada fluxo principal ou requisito funcional significativo identificado a partir da lista fornecida e representado no fluxograma mermaid principal (e potencialmente contextualizado pelos diagramas de jornada ou sequência, se criados), forneça os seguintes artefatos e análises:
i. **fat marker sketch (esboço com marcador grosso, inspirado na técnica da metodologia shape up da basecamp):**
* **descrição conceitual:** descreva verbalmente os elementos visuais e interativos chave da interface principal para este fluxo/funcionalidade, como se estivesse descrevendo um esboço rápido feito com um marcador grosso. foque na ideia central, nos principais componentes e no seu layout aproximado.
* **representação em ascii art:** forneça uma representação visual muito simples em ascii art do fat marker sketch descrito, para ilustrar o conceito.
ii. **breadboarding (conforme a abordagem de detalhamento de componentes e fluxos lógicos utilizada na metodologia shape up da basecamp):**
* elabore o breadboarding desta funcionalidade/fluxo em formato de **bullet points hierarquizados**.
* identifique os principais "lugares" (telas, seções, modais), "elementos de interface interativos" (botões, campos, links) e "conexões lógicas" entre eles.
* descreva o que acontece quando o usuário interage com cada elemento chave e como os dados ou o estado fluem (ex: "usuário clica em [botão salvar]: valida dados do formulário; se válido, envia para api; se sucesso, navega para [tela de confirmação]").
iii. **análise detalhada:**
a. **affordances chave e interações (complementar ao breadboarding):**
* identifique os sinais e pistas de interface (visuais, interativos, de conteúdo) essenciais para guiar o usuário através desta etapa/funcionalidade, referenciando o fat marker sketch e o breadboarding.
* justifique a escolha dessas affordances em relação à clareza, usabilidade e padrões de design relevantes. considere alternativas e explique os trade-offs.
* descreva as interações primárias e secundárias esperadas, detalhando o que foi apresentado no breadboarding.
b. **dados relevantes (input/output/processamento/estado):**
* especifique quais dados o usuário insere ou manipula (inputs).
* especifique quais dados são exibidos ou retornados ao usuário (outputs).
* descreva (em alto nível) os processos de backend ou lógicas de negócio que são acionados (conforme indicado no breadboarding).
* considere como o estado da aplicação ou do usuário pode mudar como resultado desta interação e como isso impacta outras partes do sistema.
c. **experiência do usuário (ux) desejada e valor percebido:**
* descreva a qualidade da experiência almejada (ex: rápido, seguro, informativo, recompensador, simples, etc.).
* **contextualize este fluxo dentro da jornada mais ampla do usuário (especialmente se um diagrama `journey` foi criado ou se for relevante mesmo sem ele): o que o usuário provavelmente fez antes de iniciar este fluxo e o que ele espera alcançar ao final dele e após ele?**
* antecipe possíveis pontos de fricção, confusão ou erro do usuário e sugira como o design proposto (incluindo fat marker e breadboarding) os mitiga.
* articule qual o *valor principal* que o usuário deve perceber ao completar esta etapa ou usar esta funcionalidade.
d. **considerações de interface/ui e componentes (baseado no fat marker sketch):**
* sugira tipos de componentes de ui apropriados (ex: modal, card, toggle, input field, data visualization) para apresentar informações e permitir interações, alinhados com o fat marker sketch.
* justifique essas escolhas com base na clareza, eficiência, densidade da informação e consistência.
e. **interdependências e contexto no fluxo (referenciando o fluxograma mermaid e o breadboarding):**
* explique como esta etapa ou funcionalidade se conecta logicamente com outras descritas nos requisitos (pré-requisitos, próximos passos).
* quais informações, estados prévios do sistema ou ações anteriores do usuário são necessários para que esta etapa seja relevante ou funcional?
f. **perspectiva sênior (estratégia e trade-offs):**
* quais são os trade-offs mais significativos nesta parte do design (ex: simplicidade vs. controle do usuário; performance vs. riqueza de dados; consistência vs. otimização local)?
* como o design desta funcionalidade contribui para os objetivos estratégicos gerais implícitos nos requisitos (ex: aquisição, engajamento, retenção, validação de hipótese)?
* existem aspectos no design desta etapa que facilitam ou dificultam futuras evoluções ou escalabilidade (com base no escopo fornecido)?
* **tratamento de requisitos não-funcionais (nfrs) / qualidade:** se algum dos requisitos fornecidos descrever explicitamente nfrs (ex: performance, segurança, acessibilidade, polimento visual), identifique-os. explique como esses requisitos de qualidade devem ser considerados *transversalmente* no design de todos os fluxos funcionais relevantes, em vez de serem apenas uma etapa final isolada. se não houver nfrs explícitos, mencione brevemente quais seriam importantes considerar para um produto robusto deste tipo.
**formato da resposta:**
* inicie apresentando a justificativa para a inclusão ou não inclusão dos diagramas opcionais (`journey` e/ou `sequenceDiagram`).
* em seguida, apresente os blocos de código mermaid. a ordem sugerida é: fluxograma principal (`flowchart td`), seguido pelo diagrama de jornada do usuário (`journey`) se gerado, e depois pelo diagrama de sequência (`sequenceDiagram`) se gerado.
* após os diagramas, para cada fluxo/requisito funcional principal identificado, apresente o item `i. fat marker sketch`, depois o item `ii. breadboarding`, e então o item `iii. análise detalhada` (com seus subitens a-f).
* mantenha todo o texto em letras minúsculas, exceto siglas e acrônimos reconhecidos (como ui, ux, api, db, crud, nfrs, fab, wcag, owasp, svg, ascii, js, css).