Microcopy de Revi

Guía para escribir textos de interfaz cortos (botones, errores, estados vacíos, confirmaciones, tooltips, placeholders, toasts) en los productos Revi (Clara, Norman, Celeste). El criterio general: el microcopy es una mini-conversación entre el producto y el funcionario. La web de UX writing y lo que hacemos en Revi coinciden en casi todo; donde difieren, manda la voz de Revi.

Principios base (mejores prácticas de UX writing, aplicadas)

1. Específico, no genérico. "Error" o "Ocurrió un problema" desperdician el espacio. Nombrar el objeto real: "El plano no se pudo subir".
2. Botones = verbo + objeto, describen el resultado. Nunca "Enviar", "OK", "Aceptar", "Submit". "Guardar borrador", "Subir expediente", "Ir a Revi". Sentence case, no MAYÚSCULAS.
3. Errores: Problema → Razón → Solución. Qué pasó, por qué, qué hacer. Nunca culpar al usuario ni al sistema. "El archivo supera 110 MB. Comprímelo o sube solo el documento principal."
4. Estados vacíos: patrón [valor] + [acción]. Un dashboard vacío explica qué hacer, no se disculpa. "Aún no hay expedientes asignados. Los verás aquí cuando te lleguen."
5. Breve pero sin ambigüedad. Sweet spot 3-7 palabras en botones; una línea en errores; máximo 2 frases en tooltips (si necesita más, no es un tooltip).
6. La acción destructiva se nombra completa. El botón de confirmación repite la acción ("Eliminar expediente"), nunca "Confirmar" o "Sí". El cuerpo del diálogo muestra la consecuencia ("Los antecedentes asociados se perderán").
7. Estado de éxito discreto. Confirmar cerca de la acción, en palabras del usuario, sin celebraciones ("Expediente enviado", no "¡Excelente!").
8. Crisis: cero personalidad. Si el sistema está caído o hay pérdida de datos, el tono es directo, serio e informativo.
9. No describir lo que se describe solo. Antes de agregar una ayuda, un subtítulo o un eyebrow, pregúntate qué dice que el nombre no diga. "+ Nueva carpeta" ya dice qué hace; "Tus chats" ya dice qué hay ahí, y no necesita "Los chats que no compartes". Si el título es suficientemente descriptivo, va solo: un subtítulo que lo repite con otras palabras es ruido y le quita peso al título.
10. Evitar el punto medio (·). No lo uses para separar datos. En una interfaz, cada dato va en su propio elemento (tag, etiqueta, columna) y el componente los separa con espacio o borde: la separación no depende del texto. En prosa, escribe una oración ("El permiso vence el 3 de marzo", no "Permiso · 3 mar").
11. Evitar las comillas angulares (« »). Para citar, usa comillas normales ("Borrador", no «Borrador»).

Botones y etiquetas no son descripciones

Un botón, un título o una etiqueta se escriben como fragmento: verbo + objeto ("Subir expediente") o sustantivo ("Tus chats"). Una descripción, en cambio, es prosa: el cuerpo de una card, un tooltip, una ayuda, el texto de un estado vacío. Ahí aplican otras reglas:

• Oraciones completas, con sujeto y verbo. No partir una idea en una etiqueta y una frase sin sujeto ("El plazo del permiso. Vence a los 30 días."); escribirla como una oración ("El permiso vence a los 30 días.").
• Sin remates. Nada de contrastes armados ni cierres que buscan efecto ("…y nunca más pierdes un plazo", "no es un trámite, es una decisión").

Voz de Revi (esto nos diferencia; contrastado con lo anterior)

• Español de Chile, tuteo. "Puedes", "Revisa", "Tu expediente". Nunca usted salvo en comunicaciones formales del canal institucional (emails de CChC a municipios van en tuteo cordial; ver email_copy.py como referencia).
• Trato de tú, verbo en presente, sin jerga legal innecesaria. Somos asistentes de revisión, no la regulación.
• Sin emojis, sin exclamaciones en serie, sin marketing. La personalidad es sobria, técnica e institucional (ver frontend/DESIGN.md de revi-dga-mono: "nunca lúdica ni recargada"). Nada de "¡Genial!" ni celebraciones que retrasen la siguiente decisión.
• Un solo CTA por superficie. Un email de Revi termina con un botón "Ir a Revi" y no pide responder ni agendar. Aplica igual en UI: una acción primaria por pantalla.
• Nada que lea a marketing. Sin UTMs visibles, sin frases de venta, sin urgencia artificial ("¡Últimos días!").
• El humano decide. La IA asiste; el copy nunca dice "el sistema decidió". Cuando un resultado viene de un modelo, dejar la acción al revisor ("Revisa y confirma la sugerencia").
• Institucional sin frío. Cordial y cercano, pero siempre útil. Buen test: leerlo como funcionario cansado a las 4 AM recuperándose de un error; si el copy empeora el ánimo, reescribir.

Patrones por elemento

Checklist al escribir o revisar microcopy

• ¿Cada botón dice qué hace exactamente? (sin Enviar/OK/Aceptar)
• ¿Los errores dicen qué pasó, por qué y qué hacer?
• ¿Tuteo chileno, sin emojis, sin exclamaciones de marketing?
• ¿Una sola acción primaria por superficie?
• ¿El copy funciona en estado de crisis (sin chistes ni personalidad)?
• ¿Los placeholders no reemplazan labels ni contienen info esencial?
• ¿Las confirmaciones destructivas repiten la acción en el botón?
• ¿Cada ayuda, subtítulo o eyebrow dice algo que su título no dice?
• ¿Las descripciones son oraciones completas y terminan sin remate?

Referencias externas

• Microcopy patterns (errors P-R-S, empty states, confirmations): https://vaishvanara.github.io/techwritingkb/technical-writing/ux-writing
• Principios y ejemplos: https://courseux.com/microcopy-examples
• Límites de caracteres por elemento: https://typecount.com/blog/microcopy-ux-writing-guide
• Copys de referencia del producto: backend/app/scripts/reactivation_campaign/email_copy.py
• Tono visual: frontend/DESIGN.md en revi-dga-mono