Estándares de UX Writing para SICOF ERP

Este documento establece los estándares y buenas prácticas para el contenido textual en las interfaces del sistema SICOF ERP. Su propósito es garantizar consistencia, claridad y eficiencia en la comunicación con los usuarios. Básicamente define cómo debemos comunicarnos con nuestros usuarios finales a través de la interfaz.

La claridad debe primar sobre cualquier otro aspecto. Los usuarios no deben tener que descifrar el significado de los textos.

✅ Correcto: - “Ingrese el monto a pagar” - “Seleccione el rubro presupuestal”

❌ Incorrecto: - “Ingrese el valor de la obligación monetaria a satisfacer” - “Elija el ítem categórico de la estructura presupuestaria”

Mi objetivo es facilitarles el trabajo mientras mantenemos la calidad de la experiencia de usuario. La claridad no es negociable - si el usuario tiene que pensar más de 2 segundos qué significa algo, estamos fallando.

Usar el mínimo de palabras necesarias para transmitir el mensaje, eliminando redundancias.

✅ Correcto: - “Guardar cambios” - “Certificado creado exitosamente”

❌ Incorrecto: - “Proceder a guardar los cambios realizados” - “El certificado ha sido creado con éxito satisfactoriamente”

Mantener uniformidad en terminología, formatos y patrones a lo largo de todo el sistema.

✅ Correcto: - Usar siempre “Eliminar” para la misma acción - Mantener “Rubro presupuestal” en todos los contextos

❌ Incorrecto: - Alternar entre “Eliminar”, “Borrar” y “Suprimir” para la misma acción - Cambiar entre “Rubro presupuestal” y “Partida presupuestaria”

Los mensajes deben orientar al usuario hacia la solución, no solo señalar problemas.

✅ Correcto: - “El monto excede el saldo disponible ($10,000,000). Reduzca el valor o seleccione otro rubro.”

❌ Incorrecto: - “Error: Monto inválido. El saldo es insuficiente.”

Estoy disponible para aclarar cualquier duda sobre estos principios. Cualquier feedback sobre esto es súper bienvenido.

• Usar capitalización coherente: Primera letra mayúscula en todas las etiquetas, excepto en preposiciones y artículos internos.
• Jerarquía visual en etiquetas: Diferenciar visualmente entre etiquetas principales y secundarias mediante peso tipográfico, no solo por tamaño.
• Mantener longitud máxima: Para etiquetas de campos, no exceder 25 caracteres.
• Campos obligatorios: Nombre + asterisco rojo () → “Descripción ”
• Campos opcionales: Nombre + “(Opcional)” → “Código Proyecto (Opcional)”

• Evitar textos largos en campos pequeños; mantener placeholders visibles sin truncamiento.
• Mostrar formato esperado en campos con validaciones específicas.
• Usar placeholders como ayuda, no para reemplazar etiquetas.
• Mantener el texto del placeholder más corto que el campo para que sea completamente visible.

• Jerarquía visual de botones:
  • Botones primarios: Fondo completo (#1E8D83)
  • Botones secundarios: Borde (#1E8D83) con fondo transparente
  • Botones terciarios: Texto simple sin borde
• Agrupar acciones relacionadas y separar visualmente grupos de acciones diferentes.
• Mantener consistencia en el uso de verbos para acciones similares en toda la aplicación.

• Botón principal de creación: “Nueva disponibilidad”
• Botones de navegación en stepper: “Anterior”, “Siguiente”
• Botón de finalización: “Enviar para aprobación”
• Botón de guardado parcial: “Guardar como borrador”
• Acción de aprobación: “Aprobar”
• Acción de rechazo: “Rechazar”

• Código de colores consistente:
  • Verde (#1E8D83) para estados positivos (Aprobado)
  • Amarillo (#FFB020) para estados en proceso (Por aprobar)
  • Rojo (#D14343) para estados negativos (Rechazado)
  • Gris (#6C737F) para estados neutrales (Borrador)
• Incluir iconos descriptivos junto a los mensajes de estado para refuerzo visual.
• Validaciones en tiempo real con mensajes que aparecen mientras el usuario completa el formulario.
• Mostrar errores cerca del campo problemático, preferiblemente debajo.
• Ofrecer soluciones cuando sea posible (“Intente con un valor menor” en lugar de solo “Valor demasiado alto”).

• Encabezados de columna: Sustantivos singulares, breves.
  • ✅ “Estado” / “Fecha creación” / “Valor solicitado”
  • ❌ “El estado” / “La fecha de la creación” / “El valor que se solicitó”
• Células vacías: Usar guion medio en vez de dejar espacios en blanco.
  • ✅ “-”
  • ❌ “[Vacío]” o dejar en blanco
• Paginación: Formato simple con números.
  • ✅ “Mostrando 1 a 10 de 20 resultados”
  • ❌ “Esta página muestra los resultados del 1 al 10 de un total de 20”

• Formato numérico consistente: Usar separadores de miles con coma y decimales con punto.
• Abreviar números grandes en dashboards (1.2M en lugar de 1,200,000) cuando el espacio es limitado.
• Incluir unidades siempre que se muestren valores numéricos (%, $, etc.).
• Mantener brevedad en los textos de información general del dashboard.

• Limitar a 5-6 pasos en el stepper para no sobrecargar al usuario.
• Usar números para identificar cada paso (1, 2, 3, 4).
• Mostrar progreso de forma visual, con pasos completados, actual y pendientes claramente diferenciados.
• Proporcionar contexto sobre dónde se encuentra el usuario dentro del proceso completo.

1. “Datos generales”
2. “Rubros y montos”
3. “Documentos soporte”
4. “Revisión final”

• Panel de ejecución: Sección del dashboard que muestra porcentajes y montos de ejecución presupuestal.
• Disponible actual: Monto presupuestal disponible considerando solicitudes en proceso.
• Actividad reciente: Sección que muestra las últimas acciones realizadas en el sistema.
• Crear con plantilla: Opción para iniciar una disponibilidad basada en una plantilla existente.

• Ruta de aprobación: Secuencia de revisores que deben autorizar la disponibilidad.
• Aprobador: Usuario con permisos para autorizar disponibilidades.
• Solicitante/Elaborador: Usuario que crea la disponibilidad.
• Solicitudes en proceso: Disponibilidades que aún no han sido aprobadas o rechazadas definitivamente.

• Usar etiquetas de color con el texto del estado
• Incluir iconos representativos junto al texto
• Mantener consistencia en la ubicación de indicadores de estado
• Proporcionar detalles adicionales al hacer hover sobre el estado

• Formato: dd/mm/aaaa
• Mostrar nombres de meses solo cuando el espacio lo permita
• ✅ Correcto: “25/03/2025”, “25 de marzo de 2025” (cuando hay espacio)
• ❌ Incorrecto: “2025-03-25”, “03/25/2025”, “25/03/25”

• Usar símbolo $ seguido del valor
• Incluir separador de miles (,)
• Mostrar decimales solo cuando sean relevantes
• ✅ Correcto: “$1,250,000”, “$1,250,000.50” (cuando los decimales son relevantes)
• ❌ Incorrecto: “1250000”, “$1.250.000”, “$ 1,250,000.00” (decimales innecesarios)

• Usar el símbolo % junto al número sin espacio
• Mostrar un decimal solo cuando sea necesario
• ✅ Correcto: “80%”, “33.5%” (cuando el decimal es relevante)
• ❌ Incorrecto: “80 %”, “80 por ciento”, “80.00%”

• Problema específico: Identificar claramente qué está mal
• Causa: Explicar por qué ocurrió (cuando sea relevante)
• Solución: Indicar cómo resolverlo
• Tono: Neutral, nunca culpar al usuario

✅ Correcto: - “El monto excede el saldo disponible ($10,000,000). Reduzca el valor o seleccione otro rubro.” - “No se pudo conectar al servidor. Verifique su conexión y vuelva a intentarlo.”

❌ Incorrecto: - “Error: Monto inválido” - “Fallo de conexión. Contacte al administrador.”

Recuerdo que en nuestras pruebas de usabilidad iniciales, los mensajes de error genéricos causaban muchísima frustración en los usuarios. Con mensajes específicos y orientados a la solución, la experiencia mejoró notablemente.

• Pregunta clara: Verificar qué se confirmará
• Consecuencias: Mencionar efectos importantes, especialmente en acciones destructivas
• Opciones: Etiquetar botones con acciones específicas, no solo “Sí/No”

✅ Correcto: - “¿Está seguro de eliminar permanentemente el documento Solicitud_Recursos.pdf?” - Botones: “Eliminar” / “Cancelar”

❌ Incorrecto: - “¿Confirmar eliminación?” - Botones: “Sí” / “No”

• Confirmar acción: Indicar claramente qué se completó
• Detalles relevantes: Incluir información útil (números de referencia, etc.)
• Próximos pasos: Sugerir acciones siguientes cuando sea pertinente

✅ Correcto: - “Disponibilidad #325 creada exitosamente. Ha sido enviada para aprobación.” - “Rubro agregado correctamente. Saldo disponible actualizado.”

❌ Incorrecto: - “Operación exitosa.” - “Creación completada.”

• Propósito: Explicar para qué sirve la sección/función
• Instrucciones: Proporcionar guía concisa sobre cómo proceder
• Ubicación: Colocar donde sea más relevante para el contexto de uso

✅ Correcto: - “Las solicitudes en proceso afectan el saldo disponible mostrado. Esto garantiza que no se comprometan recursos ya solicitados por otros usuarios.” - “Seleccione una ruta de aprobación para visualizar el flujo de aprobadores.”

❌ Incorrecto: - “El saldo se ve afectado por solicitudes en proceso.” - “Debe seleccionar una ruta.”

• No depender solo del color: Complementar con texto o iconos para transmitir información
• Textos alternativos: Proporcionar para imágenes funcionales
• Instrucciones claras: No depender de características visuales (“botón verde”)
• Terminología consistente: Usar los mismos términos para las mismas funciones

✅ Correcto: - “Estado: Aprobado ✓” (en color verde) - “Seleccione el botón 'Continuar' para avanzar”

❌ Incorrecto: - Solo usar color verde sin texto ni ícono para indicar aprobación - “Haga clic en el botón verde”

• Lenguaje sencillo: Evitar términos complejos o técnicos innecesarios
• Oraciones cortas: Facilitar la lectura y comprensión
• Abreviaturas: Explicar la primera vez que aparecen
• Jerga: Minimizar el uso de jerga técnica

Documento actualizado: 17/03/2025
Elaborado por: Jesús Mejía - Diseñador UX