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)”

He comprobado en mis años de trabajo con SICOF que las etiquetas son el primer lugar donde los usuarios se pierden. Si cuidamos estos detalles, reducimos la fricción y los errores de interpretación. No subestimen el poder de una buena etiqueta.

• Usar color #9AA2B1 (gris medio) para todos los placeholders, facilitando la diferenciación del texto ingresado.
• 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.

Siempre digo en las reuniones de revisión: “Si el usuario tiene que pensar dónde hacer clic, hemos fallado”. Por eso soy tan exigente con la jerarquía y etiquetado de botones.

• 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.

Para mí, el dashboard es como la carta de presentación de nuestro sistema. Si se ve desordenado o confuso, perdemos credibilidad desde el primer momento.

• Limitar a 4-5 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”

Esto es súper importante. Cuando escucho a alguien decir “partidas” en lugar de “rubros”, me quedo con esa sensación de inconsistencia que debemos evitar a toda costa.

• 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