Diseño de interfaces fintech: tareas financieras claras y sin fricciones

Presenta los saldos con contexto

Un gran número no se explica por sí solo. Identifique la cuenta a la que pertenece y muestre la moneda mediante un símbolo o código familiar. Si el producto distingue montos actuales, disponibles, pendientes o invertidos, etiquete esos conceptos directamente y explíquelos cuando sea necesario. Evite presentar dos tipos de equilibrio diferentes con un estilo casi idéntico y sin definición.

El contexto también puede incluir cuándo se actualizó el monto por última vez o qué actividad aún está pendiente. Elija el detalle que ayude a alguien a interpretar la pantalla, en lugar de agregar números decorativos. Utilice un formato numérico consistente y suficiente espacio para que los dígitos, los separadores decimales y los signos menos sean fáciles de distinguir. Para nombres de cuentas largos, conserve suficiente texto para diferenciarlas en lugar de depender únicamente del color o de un ícono.

• Utilice una etiqueta de cuenta explícita y una moneda cerca del monto.
• Explique términos especializados como "disponible" o "pendiente" en un lenguaje sencillo.
• Mantenga la misma cantidad y estado comprensible con texto más grande y tecnología de asistencia.

Muestra cómo evoluciona el estado de una transacción

Una transacción es un proceso, no sólo una fila en una lista del historial. Proporcione a cada artículo un estado conciso, fecha, monto y contraparte o destino cuando corresponda. Mantenga la etiqueta de estado visible en el texto; El color o un ícono pueden reforzarlo, pero no deben transmitir el significado por sí solos. Distinga la actividad que está en espera, completada, rechazada o que necesita atención según los estados reales del producto.

Por ejemplo, una transferencia hipotética de 45,00 EUR a Alex podría leerse primero "Programada para el 4 de noviembre", luego "Procesamiento" y luego "Completado". Si una conexión se agota después del envío, no anuncie con seguridad el éxito o el fracaso sin pruebas. Diga que el estado aún no está disponible, explique cómo verificarlo nuevamente y deje en claro si volver a intentarlo podría crear otra solicitud. La redacción exacta y las acciones disponibles dependen del comportamiento real de la transacción del producto.

Diseña formularios financieros que eviten confusiones

Solicite información cuando sea necesaria para la tarea y agrupe los campos relacionados para que el formulario se lea en un orden razonable. Utilice etiquetas persistentes como "Destinatario" o "Cantidad"; un marcador de posición es un ejemplo, no un reemplazo de una etiqueta. Si un campo espera un formato particular, indíquelo antes de ingresarlo; por ejemplo, si una cantidad acepta centavos o qué identificador pertenece al campo. La guía de entrada de datos de Apple recomienda aclarar la información solicitada, minimizar la entrada innecesaria y validar los valores a medida que las personas los proporcionan.

Elija controles de entrada que se ajusten a la información y permitan a las personas corregir las entradas. Mantenga los campos opcionales visiblemente opcionales y los campos obligatorios identificables. Si una selección tiene consecuencias, describa las opciones en un lenguaje sencillo en lugar de hacer que las personas infieran el significado a partir de códigos cortos. La guía de campo debe estar lo suficientemente cerca de su control para seguir siendo comprensible cuando la pantalla cambia o se amplía.

Ofrece un paso útil de revisión y confirmación

Antes de una acción importante, resuma la información que alguien está a punto de enviar: fuente, destino, monto, fecha y cualquier cargo o momento mostrado que sea relevante para el flujo. Reúna los detalles más críticos para la toma de decisiones y facilite la localización de las rutas de edición. La acción principal debe describir la acción, como "Programar transferencia", en lugar de un ambiguo "Continuar".

Una pantalla de confirmación debería responder "¿Qué pasó?" y "¿Qué puedo hacer ahora?" Una vista de referencia o recibo puede admitir búsquedas posteriores. Evite tratar el toque de un botón como prueba de que la operación subyacente tuvo éxito; la interfaz debe reflejar el resultado real devuelto por el producto.

• Mantenga el resumen coherente con los valores ingresados ​​y las opciones seleccionadas.
• Las acciones de devolución y edición preservan el trabajo del usuario cuando sea práctico.
• Después de la presentación, indique si la solicitud fue recibida, se está procesando o tiene un resultado confirmado.
• Para una respuesta incierta, explique cómo verificar el estado actual antes de invitar a otro envío.

Haz accesibles los errores y las actualizaciones

Cuando se detecte un error de entrada, identifique el campo y describa el problema en texto. “Cantidad no válida” es menos útil que un mensaje que explique el formato aceptado o el valor faltante. Conserve las entradas válidas para que las personas puedan solucionar un problema sin empezar de nuevo. La guía WCAG 2.2 del W3C exige que se identifiquen y describan los errores de entrada detectados, y que se proporcionen etiquetas o instrucciones cuando se requiera información.

Las actualizaciones de estado también son importantes. Si una página cambia de "Procesando" a "Completado" sin mover el foco, exponga esa actualización de una manera que la tecnología de asistencia pueda determinar. WCAG 2.2 describe los mensajes de estado como cambios que comunican resultados, esperas, progresos o errores sin requerir un cambio de contexto. Mantenga las alertas proporcionadas: anuncie cambios significativos sin interrumpir repetidamente a alguien con cada actualización visual.

Verifique el contraste, el cambio de tamaño del texto, el acceso al teclado o interruptor y los nombres de los lectores de pantalla en la interfaz implementada. Utilice encabezados claros y etiquetas de control, y no indique éxito, error o dirección de la transacción únicamente con el color. Los principios de diseño de Apple enfatizan la retroalimentación clara y ayudar a las personas a recuperarse de los errores; Estos son objetivos útiles, mientras que la accesibilidad real requiere evaluar el producto completo.

Lista de comprobación para revisar una interfaz fintech

Recorra una tarea típica desde su saldo inicial hasta su estado final. Verifique la ruta ordinaria, una corrección y una interrupción como una conexión lenta. Compare pantallas móviles relacionadas en la biblioteca para ver cómo las diferentes interfaces organizan la información y las acciones, luego evalúe su propio flujo en comparación con el comportamiento real del producto.

• ¿Alguien puede decir qué cuenta y moneda describe un saldo?
• ¿Los estados pendientes y completados se nombran claramente y se presentan en texto?
• ¿Tiene cada campo una etiqueta visible y alguna instrucción de formato necesaria?
• ¿Pueden las personas revisar el destino, el monto y el momento antes de enviarlo?
• ¿Los errores identifican el problema y ofrecen una corrección práctica?
• ¿Sigue siendo perceptible una actualización sin que se mueva el color, la visión precisa o el enfoque?
• Cuando el resultado es incierto, ¿la interfaz explica cómo comprobarlo antes de volver a intentarlo?