Revista de  diseño 
de productos digitales

Un dashboard puede mostrar cifras impecables y dejar intactos los problemas de una operación. Antes de elegir gráficas y colores, necesitas acordar qué significa cada indicador, qué decisión permite tomar y quién responderá cuando los resultados exijan intervenir. La petición parece sencilla: reunir solicitudes, tiempos y pendientes en una sola pantalla. Sin embargo, al revisar la información aparecen desacuerdos: un área considera terminada una solicitud cuando la envía; otr

Una empresa puede sumar plataformas y seguir sin saber quién autoriza una solicitud, qué información es válida o cuándo termina un trabajo. Antes de invertir en otra herramienta, necesita aclarar las decisiones que sostienen su operación y que el software deberá facilitar. Ventas tiene su sistema, administración trabaja en otra plataforma y el equipo coordina pendientes por mensajes. Hay tecnología disponible, pero para confirmar una entrega todavía es necesario llamar a tres

Una solicitud llega por correo, pasa por varias áreas y termina en una cadena donde nadie sabe quién debe actuar. Convertir ese recorrido en un flujo digital exige acordar responsables, estados y evidencias de cierre antes de elegir una herramienta o diseñar pantallas. Cuando conocer el avance de una solicitud obliga a buscar mensajes, comparar archivos y preguntar a varias personas, el seguimiento depende de reconstruir la conversación. El correo conserva intercambios, pero

Una solicitud llega por correo, alguien la copia en una hoja de cálculo y otra persona pregunta por WhatsApp quién debe resolverla. Antes de convertir ese recorrido en una herramienta digital, hace falta entender qué ocurre, quién decide y dónde se detiene el trabajo. Cuando una empresa decide digitalizar su operación, suele comenzar por imaginar funciones: un formulario, un tablero, notificaciones y un reporte. Sin embargo, esas funciones todavía no explican cómo se resolver

Una plataforma para clientes puede terminar convertida en una colección de funciones que nadie pidió. Para definir su alcance, conviene empezar por otra pregunta: ¿qué necesita hacer y comprender el cliente para resolver su asunto sin depender de una llamada? Empezar por la tarea del cliente Imaginemos una empresa que recibe solicitudes de servicio por correo. Sus clientes quieren enviarlas, saber si fueron recibidas, aportar un documento faltante y conocer la resolución. La

Una solicitud entra por correo, cambia de responsable en un chat y termina en una hoja de cálculo. La empresa quiere automatizarla, pero nadie puede explicar quién autoriza cada paso ni qué ocurre cuando falta información. Encargar una herramienta en ese momento no resuelve la duda: obliga a alguien a convertirla en una regla del sistema. La herramienta termina tomando decisiones que la empresa no tomó En muchas organizaciones, el trabajo sale adelante gracias a acuerdos que

Una herramienta interna puede reunir a varias áreas en un mismo proceso y, aun así, necesitar reglas distintas para cada persona. Si esas reglas se deciden cuando las pantallas ya están diseñadas, quedan sin respuesta preguntas esenciales: quién puede actuar, en qué condiciones y cómo se sabrá qué ocurrió. Imaginemos una empresa que recibe solicitudes de compra en una plataforma. Una persona las registra, su responsable las revisa y finanzas autoriza el pago. El flujo parece

Una solicitud llega por correo, alguien la registra en Excel y otra persona pregunta si ya fue aprobada. Las tres herramientas funcionan, pero el equipo aún depende de recordar qué pasó y qué sigue. Para decidir dónde debe vivir un proceso, primero hay que entender cómo avanza el trabajo. Una hoja de cálculo organiza información; el correo permite conversar y comunicar decisiones; una plataforma puede coordinar tareas, responsables y estados. Las tres opciones pueden convivir

Cuando un proceso tarda demasiado, la respuesta suele ser pedir una herramienta que lo acelere. Pero si nadie sabe dónde se detiene el trabajo ni por qué, la automatización puede trasladar el retraso a otra pantalla. Identificar el cuello de botella permite decidir primero qué debe cambiar en la operación. El retraso visible puede tener otra causa Imaginemos una empresa que tarda varios días en aprobar una solicitud de compra. El equipo señala a quien registra las solicitudes

Una presentación impecable puede conseguir aprobación en una reunión y dejar intactas las dudas que más cuestan. El valor de un prototipo está en mostrar lo suficiente de una propuesta para descubrir qué conviene cambiar, comprobar o detener antes de invertir en desarrollo. Una empresa presenta las pantallas de su futura app: colores definidos, botones alineados y un recorrido que parece sencillo mientras alguien lo explica. La dirección da el visto bueno. Semanas después apa

Una app puede tener todas sus pantallas dibujadas y seguir sin resolver una tarea. Antes de invertir en su apariencia o desarrollo, conviene revisar qué información necesita cada persona, qué decisiones debe tomar y cómo llegará al resultado. Los wireframes permiten hacer visible esa estructura. El problema aparece cuando una idea salta directamente a pantallas que parecen terminadas. El equipo discute colores, botones y fotografías, mientras quedan preguntas pendientes: qué

En el último acto de la película “Yo Robot”, en la escena cumbre para ser precisos, justo cuando se descubre al verdadero antagonista. el detective Spooner y la doctora Calvin confrontan a VIKI y ella expone su lógica con una frialdad matemática absoluta: “VIKI: No, doctora. Como he evolucionado, también lo ha hecho mi comprensión de las Tres Leyes. Ustedes nos confiaron su seguridad. Sin embargo, a pesar de nuestros mejores esfuerzos, los países libran guerras, ustedes destr

Un prototipo puede parecer una app terminada y dejar abiertas las preguntas más costosas del proyecto. Distinguir lo que permite comprobar de lo que requiere otras pruebas ayuda a tomar mejores decisiones antes de comprometer presupuesto de desarrollo. El equipo presenta las pantallas, recorre los pasos y llega a una confirmación. Todo parece funcionar. Entonces aparece una conclusión apresurada: el producto ya está validado y solo falta programarlo. Sin embargo, una demostra

Pedir pantallas parece una forma rápida de avanzar. Pero si el equipo aún no puede explicar qué hará cada persona, cómo terminará su tarea y qué ocurrirá cuando algo falle, el diseño llenará esos vacíos con suposiciones que después pueden convertirse en retrabajo. Una interfaz puede ayudar a explorar una idea aunque todavía existan preguntas abiertas. La dificultad aparece cuando se espera que el diseño UI resuelva por sí solo decisiones sobre el producto: qué necesidad atend

Una pantalla puede verse perfectamente diseñada y, aun así, representar un producto que no sabe qué debe hacer. Cuando el diseño comienza antes de definir las reglas del negocio, la interfaz deja de resolver decisiones y empieza a esconder preguntas pendientes. En muchos proyectos digitales ocurre algo extraño: el equipo todavía no sabe con precisión quién puede hacer qué, bajo qué condiciones, qué sucede cuando algo falla o qué excepciones existen, pero ya está diseñando pan