💻 Cuando la tecnología se vuelve el obstáculo

¿En qué momento dejamos que la tecnología mande más que el usuario?

Cada tanto me cruzo con situaciones que me frustran. No por la app, no por el equipo… por la forma en que pensamos las cosas en tecnología.

🔧 El problema clásico

Ejemplo clásico:
Una API gigante, llena de datos, claves y campos que nadie pidió… pero que obligan al front a transformarlo todo para que tenga algún sentido.

Al final pasa algo rarísimo:
La app termina atada a la estructura de la API… en vez de que la API responda a lo que necesita la experiencia del usuario.

🚨 Síntomas de que algo anda mal

Y eso se nota en el día a día:

1. Flujos fragmentados

Flujos que dependen de pantallas intermedias porque cierto dato “solo aparece ahí”.

Ejemplo real:
Para completar un perfil de usuario, tenés que pasar por 3 pantallas diferentes porque cada endpoint devuelve solo una parte de la info.

2. Deeplinking imposible

Imposibilidad de hacer deeplinking porque la info llega migajeada.

Consecuencia:
No podés compartir un link directo a un producto o sección específica porque la app necesita cargar datos de 4 endpoints diferentes en orden secuencial.

3. Almacenamiento defensivo

Datos que hay que almacenar “por las dudas” para poder reconstruir algo más adelante.

Resultado:
El frontend se convierte en una base de datos temporal llena de estados que nadie debería tener que gestionar.

4. Transformers everywhere

Curadores y transformers por todos lados para que el resultado más o menos encaje.

Realidad:
El 60% del código del frontend es mapeo de datos, no lógica de negocio ni UX.

🤔 La pregunta incómoda

Y a veces pienso:
¿No nos desviamos un poco del objetivo?

¿No debería la tecnología adaptarse al usuario y no al revés?

El ciclo vicioso

1. Backend diseña API según su modelo de datos
2. Frontend recibe estructura que no matchea con la UX
3. Frontend crea capa de transformación
4. UX se adapta a lo que “es posible” con esa estructura
5. Usuario sufre la experiencia fragmentada

💡 ¿Qué podríamos hacer mejor?

1. Diseñar desde la UX hacia atrás

En lugar de:

Base de datos → API → Frontend → UX

Deberíamos pensar:

UX → Frontend → API → Base de datos

Pregunta clave: ¿Qué necesita el usuario en esta pantalla?
No: ¿Qué datos tenemos disponibles?

2. APIs orientadas a casos de uso

En vez de endpoints genéricos que devuelven todo, crear endpoints específicos para cada flujo de usuario.

Ejemplo:

• ❌ GET /user (devuelve 50 campos)
• ✅ GET /user/profile-completion (devuelve solo lo necesario para esa pantalla)

3. Backend for Frontend (BFF)

Una capa intermedia que:

• Agrega datos de múltiples fuentes
• Transforma la estructura según necesidades del cliente
• Maneja la complejidad de integración

Beneficio: El frontend recibe exactamente lo que necesita, nada más.

4. Contratos definidos por el consumidor

El frontend define qué necesita (Consumer-Driven Contracts).
El backend se adapta para proveerlo.

No al revés.

🎯 Casos reales donde esto importa

E-commerce

Problema: Para mostrar un producto necesitás llamar a 5 endpoints diferentes.
Impacto: Tiempo de carga lento, experiencia fragmentada, usuarios que abandonan.

Onboarding

Problema: Formulario dividido en 10 pasos porque cada paso depende de un endpoint diferente.
Impacto: Tasa de abandono del 70% antes de completar el registro.

Dashboards

Problema: Cada widget hace su propia llamada, sin coordinación.
Impacto: 20+ requests al cargar la página, performance horrible.

💭 Reflexión final

No estoy diciendo que sea fácil.
Sé que hay constraints de legacy, de equipos separados, de prioridades diferentes.

Pero creo que como industria deberíamos preguntarnos más seguido:

¿Estamos construyendo tecnología que sirve al usuario?
¿O estamos construyendo experiencias que sirven a nuestra arquitectura?

Porque al final del día, al usuario no le importa si tu base de datos está normalizada o si tu API es RESTful pura.

Le importa si la app funciona bien, es rápida, y hace lo que necesita sin fricción.

---

🔄 El cambio empieza con conversaciones

Si trabajás en tech y te comiste estas frustraciones alguna vez, no estás solo.

El primer paso para mejorar es reconocer el problema.
El segundo es hablar de él.
El tercero es hacer algo al respecto.

La tecnología debería ser invisible para el usuario.
Debería habilitar experiencias, no limitarlas.

Y eso solo pasa cuando ponemos al usuario en el centro, no a la arquitectura.