Design review e feedback de produto

Nível: B1

Objetivo

Comentar telas e fluxos de produto em inglês durante uma design review, usando vocabulário de UX (usability, accessibility, edge case, empty state, error state) e frases claras para dar e receber feedback.

Explicação

Em uma design review profissional, três perguntas organizam o feedback: o que o usuário vê nesta tela?, o que pode dar errado aqui? e o fluxo faz sentido do começo ao fim? Responder essas perguntas em inglês exige vocabulário de UX e padrões de frase claros.

Vocabulário essencial de design review

Os cinco termos aparecem em quase toda conversa sobre UI:

• usability — quão fácil é usar a interface. Comentários começam com `From a usability perspective, ...`.
• accessibility — quão bem a interface funciona para todos os usuários, inclusive pessoas com deficiência visual, motora ou cognitiva. `From an accessibility perspective, ...`.
• edge case — situação rara ou limite, como um carrinho com 50 itens ou um nome com caracteres especiais. `What happens if the cart is empty?` é uma pergunta típica de edge case.
• empty state — a tela que aparece quando não há dados, por exemplo, `lista de notificações vazia` ou `sem resultados de busca`. Em inglês: `What does the user see when there are no results?`
• error state — a tela que aparece quando algo falha, como `pagamento não processado` ou `formulário inválido`. `What does the error message say?`

Três partes de um comentário claro

Um comentário útil em uma design review tem três partes, nesta ordem:

1. O que você vê na tela — descreva o estado atual com termos da UI.

• `On the checkout screen, the CTA button is at the bottom.`

1. O problema ou risco — explique o impacto para o usuário.

• `From a usability perspective, this could be confusing because users might miss it.`

1. A sugestão concreta — proponha uma alternativa específica.

• `I'd suggest moving the CTA above the fold.`

Pular uma das três partes deixa o feedback vago. `This is confusing.` é um comentário fraco; `On the checkout screen, the CTA is below the fold. From a usability perspective, this could be confusing because users might miss it. I'd suggest moving it above the fold.` é um comentário profissional.

Perguntas-chave para abrir uma review

Quatro perguntas movem a conversa adiante sem julgar a proposta:

• `Can you walk me through this flow?` — pedir para o autor explicar o passo a passo.
• `What does the user see when there are no items?` — investigar o empty state.
• `What happens if the payment fails?` — investigar o error state.
• `Are we covering this edge case?` — checar um caso limite.

Para fechar com clareza, use padrões de feedback educado já vistos em code reviews: `From a usability perspective, ...`, `From an accessibility perspective, ...`, `I'd suggest ...`, `Have you considered ...?` A diferença é o domínio: aqui o alvo é a experiência do usuário, não linhas de código.

Comentando fluxos, não só telas

Uma design review não analisa telas isoladas, mas o fluxo entre elas. Pergunte como o usuário chega até ali e o que acontece depois:

• `How does the user get to this screen?`
• `What happens after they tap the CTA?`
• `Is there a way back if they change their mind?`

Para encadear feedbacks em várias telas, use conectores simples: `Also, on the next screen, ...`, `Another concern, ...`, `One more thing, ...`.

Exemplos

Erros comuns

• Fazer um comentário sem descrever a tela: `This is confusing.` deve ser `On the checkout screen, the CTA is below the fold. From a usability perspective, this could be confusing.`
• Confundir usability e accessibility: usability é sobre facilidade geral de uso; accessibility é especificamente sobre usuários com deficiência e diretrizes como contraste, foco de teclado e leitura por leitores de tela.
• Dizer `the error state is when the user do something wrong` em vez de `the error state appears when the user does something wrong`: error state é um substantivo que descreve a tela, não uma ação.
• Esquecer o empty state: revisar só o happy path deixa buracos no fluxo. Sempre pergunte `What does the user see when there's nothing to show?`
• Falar apenas da tela atual e não do fluxo: `On this screen the button is unclear.` é fraco; prefira `On this screen the button is unclear, and there's no clear way back to the previous step. Have you considered adding a back link?`

Prática guiada

Transforme cada comentário vago em um comentário claro de design review com as três partes (o que se vê, o problema, a sugestão).

• Vago: `The button is hard to find.`

Claro: `On the checkout screen, the main CTA is below the fold. From a usability perspective, users might miss it. I'd suggest moving it above the product list.`

• Vago: `The error message is bad.`

Claro: `On the payment error state, the message just says 'Something went wrong.' From a usability perspective, this is too vague. Have you considered showing the reason and a next step, like 'Your card was declined. Please try another payment method'?`

Repare que cada revisão tem: a tela onde o problema aparece, a justificativa de UX e uma alternativa concreta.

Resumo

Em uma design review, descreva a tela (`On the X screen, ...`), justifique o problema com `From a usability/an accessibility perspective, ...` e proponha uma mudança com `I'd suggest ...` ou `Have you considered ...?`. Use `What does the user see when ...?` para investigar empty states, `What happens if ...?` para error states e `Are we covering this edge case?` para casos limite. Para comentar fluxos, use `Can you walk me through this flow?` e conecte feedbacks entre telas com `Also, on the next screen, ...`.

História: Design review e feedback de produto

Nível: B1

História em inglês

The checkout mockup

On Tuesday morning, the product team at Northwind opened a design review for the new checkout flow. Liam, the designer, shared his mockup on the screen. Maya, the senior engineer, started with an open question: "Can you walk me through this flow, from cart to confirmation?" Liam clicked through the screens: cart, address, payment, review, and confirmation. He added, "The happy path is pretty smooth, but I want feedback on the edge cases."

Empty state and error state

Maya asked, "What does the user see when the cart is empty?" Liam opened another screen: a friendly illustration with the text 'Your cart is empty' and a button to keep shopping. Maya said, "Good. From a usability perspective, the empty state is clear, and the CTA is easy to find." Then she asked, "What happens if the payment fails?" Liam showed an error state with the message 'We couldn't process your payment. Please try again.' Maya replied, "From a usability perspective, the error state is too vague. Have you considered showing the reason and a next step, like 'Your card was declined' with a link to another payment method?"

Accessibility and an edge case

After that, Maya looked at the disabled 'Pay' button on the payment screen. She said, "From an accessibility perspective, the contrast on the disabled button is below the recommended ratio. I'd suggest darkening the text or using a clear 'Pay' label instead of just an icon." Liam nodded and asked, "What about an edge case? For example, a user with no saved address?" Maya replied, "Right now the screen just shows an empty form. From a usability perspective, I'd suggest showing a primary CTA to add a new address, so the user knows what to do next." Daniel, the product manager, wrote it all down: empty state approved, error state needs revision, accessibility fix on the button, and a clearer edge case on the address screen. At the end of the review, Liam thanked the team and scheduled one more round of feedback before approving the new flow.

Tradução linha por linha

Notas de vocabulário

• design review = reunião formal para revisar uma proposta de UI/UX antes da implementação.
• Can you walk me through this flow? = abertura clássica para pedir que o autor explique o fluxo passo a passo.
• happy path = caminho padrão do usuário, sem erros nem casos limite.
• edge case = situação rara ou limite que precisa de tratamento explícito no fluxo.
• What does the user see when the cart is empty? = pergunta para investigar o empty state, ou seja, a tela sem dados.
• empty state = tela mostrada quando não há dados, como um carrinho vazio ou busca sem resultados.
• What happens if the payment fails? = pergunta para investigar o error state, ou seja, a tela exibida quando uma ação falha.
• error state = tela mostrada quando algo dá errado, como pagamento rejeitado.
• From a usability perspective, ... = abertura típica para justificar um feedback sobre facilidade de uso.
• Have you considered ...? = abertura educada para sugerir uma alternativa; aqui, melhora do error state.
• From an accessibility perspective, ... = abertura típica para justificar um feedback sobre usuários com deficiência.
• the contrast is below the recommended ratio = explicação técnica de um problema clássico de acessibilidade visual.
• round of feedback = rodada de feedback; ciclos curtos de revisão antes de aprovar a proposta.

Perguntas de compreensão

1. What was the subject of the design review at Northwind?
2. How did Maya open the design review?
3. What did Liam show for the empty state of the cart?
4. Why did Maya say the error state was too vague?
5. What did Maya suggest to improve the error state?
6. What was the accessibility issue on the payment screen?
7. What edge case did Liam bring up about the address screen?
8. What did the team agree to do at the end of the review?

Prática com a história

1. Reescreva como comentário educado: 'The error message is bad.'
2. Complete: 'From an ___ perspective, the contrast on the disabled button is too low.'
3. Traduza: 'O que o usuário vê quando não há notificações?'
4. Faça uma pergunta em inglês para investigar o que acontece se o pagamento falhar.