Qué es un rediseño de software

Rediseñar software no es cambiar los colores. Es volver a ordenar la experiencia completa de un producto que ya está en uso: qué información va primero, cómo se agrupa, qué se puede postergar y qué tiene que estar a la vista en el momento de decidir.

Muchos softwares se construyeron pensando en los datos, no en las personas que los usan. Funcionan, pero exigen que el usuario aprenda la lógica interna del sistema para poder trabajar. El rediseño devuelve el foco a las personas sin tirar abajo lo que ya funciona.

Cuándo conviene rediseñar

Los síntomas se parecen bastante entre productos distintos. Si reconocés tres o más de estos, el problema no es de capacitación:

01Cada duda termina en un ticketEl soporte no da abasto y responde siempre lo mismo. La interfaz no explica, y la explicación la pone una persona.
02La gente lo resuelve por afueraPlanillas paralelas, mensajes internos y registros informales para hacer lo que el software debería resolver.
03Todo pesa igualNo hay jerarquía entre lo crítico y lo accesorio: ningún campo se marca como clave, avanzado u opcional.
04Hay que completar todo para ver algoEl producto exige cargar el formulario entero antes de devolver el primer resultado útil.
05El onboarding no existe o es un manualNadie llega solo a la primera acción con valor sin que alguien se la muestre.
06Los devs reconstruyen lo mismoSin sistema de diseño, cada pantalla nueva se resuelve otra vez desde cero y con criterios distintos.

Cómo trabajo

El proceso tiene cinco etapas y no es del todo rígido, porque cada producto llega con un problema distinto. Comprende: entiendo el negocio, el producto y a quién lo usa, con entrevistas y análisis del flujo de trabajo real, incluidas las herramientas de afuera. Analiza: evaluación heurística y testing con usuarios para separar lo que molesta de lo que se rompe. Unifica: arquitectura y sistema de diseño, patrones coherentes de punta a punta. Construye: las pantallas con todos sus estados. Entrega: documentación versionada, lista para implementar.

La base es siempre la misma: buenas conversaciones antes de mover un píxel.

Qué recibís
  • Las pantallas completas en Figma, con todos sus estados y variables, listas para implementar.
  • Sistema de diseño con componentes, tokens de color, tipografía y espaciado, y su capa de motion.
  • Prototipo navegable de punta a punta, para validar el rediseño antes de construirlo.
  • Documentación de UX por módulo, con historias de usuario y criterios de aceptación.
  • Los assets subidos por mí al repositorio. Te lo voy a proponer siempre: si los subo yo, tu equipo de desarrollo se ahorra ese trabajo y el diseño llega al producto sin perder calidad en el camino.

Un caso: WaterProof

WaterProof es la plataforma con la que The Nature Conservancy estima, antes de invertir, cuánto se ahorra protegiendo la naturaleza para asegurar el agua de una ciudad. Detrás corren modelos científicos (InVEST, RIOS). Entré como UX Expert y fui la única diseñadora del proyecto.

Era un software que exigía completar todo antes de mostrar valor. Quedó como uno que acompaña la decisión.

440Pantallas diseñadas (220 en español, 220 en inglés)
113Componentes del sistema de diseño, con estados y variables
100%Aprobado por The Nature Conservancy y validado por IT

Un hallazgo transversal marcó el tono del rediseño. Como resumió uno de los expertos entrevistados: "no todo el mundo la puede usar; necesita un lenguaje que entienda un tomador de decisión, que no tiene tiempo ni le interesa el tecnicismo".

Ver el caso completo

Preguntas frecuentes

¿Cuánto dura un rediseño de software?

Depende del tamaño del producto y de cuánto haya que investigar antes de decidir. Un módulo acotado se resuelve en semanas; un producto completo, como WaterProof, llevó el diseño de 220 pantallas con todos sus estados. En la primera llamada sale una estimación con el alcance sobre la mesa.

¿Hay que rehacer el backend?

No. El rediseño de WaterProof respeta el backend existente y fue validado por el equipo de IT antes de aprobarse. Se rediseña la experiencia sobre lo que ya funciona; si algo del modelo de datos obliga a un cambio, se marca y se decide con el equipo de desarrollo, no por afuera.

¿Trabajás con el equipo de desarrollo o entregás y te vas?

Con el equipo. Cada decisión se valida con desarrollo antes de darla por cerrada, y la entrega incluye la documentación de UX por módulo con historias de usuario y criterios de aceptación. Un diseño que el equipo no puede construir no está terminado.

¿Se puede rediseñar por partes?

Sí, y suele ser lo más sano. Se ordena la arquitectura completa primero, para saber hacia dónde va todo, y después se rediseña módulo por módulo. Así el producto no se congela mientras dura el trabajo.

Hablemos

Si algo de esto se parece a tu producto, la forma más rápida de saber si puedo ayudarte es una llamada de 30 minutos. Reservá un horario o escribime a vaninasysiuk@gmail.com.