Un diseño que no se puede construir como está dibujado no es un diseño, es un dibujo. Los nuestros se producen en el mismo Pod que los entrega.
La falla habitual es organizacional. El diseño pasa en una compañía, la ingeniería en otra, y la entrega entre las dos es un archivo. Cada ambigüedad en ese archivo se convierte en una decisión que alguien de ingeniería toma solo, rápido, sin el contexto que produjo el dibujo.
Como aquí el diseño y la entrega viven en el mismo Pod, cada flujo se valida como prototipo navegable antes de la implementación, y el sistema de diseño se construye como componentes reales y no como una librería de símbolos que nadie puede usar.
También investigamos antes de dibujar. No un estudio de seis semanas, pero sí suficiente contacto con usuarios reales para saber cuál de los tres flujos plausibles corresponde a cómo la gente ya piensa la tarea.
Flujos, wireframes y diseño de interfaz para productos reales.
Validación navegable de la dirección antes de que empiece la implementación.
Entrevistas y pruebas dimensionadas a la decisión que hay en frente.
Componentes, tokens y documentación que ingeniería de verdad puede usar.
Contraste, orden de foco y semántica decididos durante el diseño.
Una entrega que corresponde a lo que se construye, porque lo construye el mismo Pod.
La experiencia de usuario es una pregunta sobre estructura. Cuáles pantallas existen, en qué orden, qué pasa cuando falta algo, y si el camino corresponde a cómo alguien ya piensa el trabajo. Si esto sale mal, ninguna cantidad de trabajo de interfaz lo recupera.
La capa de interfaz carga la marca y hace el trabajo momento a momento de ser legible, presionable y sin ambigüedades. La construimos como un sistema de diseño de componentes reales y no como una página de símbolos, para que la segunda pantalla cueste menos que la primera.
La mayoría de las solicitudes de "diseño" llegan queriendo decir la segunda. La primera es donde normalmente se pierde el dinero, porque una interfaz hermosa sobre el flujo equivocado es una ruta más rápida al lugar equivocado.
Paso 01
La pregunta que tu diseño tiene que responder queda escrita antes de dibujar nada.
Paso 02
Tus flujos se vuelven un prototipo navegable. Redirigir un prototipo cuesta una fracción de redirigir una implementación, que es toda la razón por la que existe.
Paso 03
Las pruebas de usabilidad pasan antes de la implementación y no después de tu lanzamiento, mientras la respuesta todavía es gratis de aplicar.
Paso 04
El diseño corre más o menos un ciclo por delante de la implementación, en el mismo Pod que la entrega. Ningún archivo pasa por encima de un muro, así que la ambigüedad recibe una conversación en vez de una suposición.
Paso 05
Los patrones que se repiten se vuelven componentes de tu sistema de diseño, así cada superficie posterior te cuesta menos de diseñar y menos de construir.
La investigación tiene mala fama en los equipos de producto, y se la ganó honestamente. Los estudios de seis semanas que llegan después de que la decisión ya se tomó son teatro, y todos los involucrados lo saben.
Así que dimensionamos la investigación a la decisión que tenemos en frente. Si la pregunta es cuál de tres flujos plausibles corresponde a cómo la gente ya piensa una tarea, eso son cinco o seis conversaciones y dos días, no una fase de descubrimiento. Si la pregunta es si vale la pena entrar a toda una categoría de producto, eso es un trabajo más grande y debería ser un proyecto aparte en vez de colarse dentro de una construcción.
La prueba que aplicamos es simple. Si el hallazgo no podría cambiar lo que construimos después, no hacemos el estudio. Esa restricción mantiene la investigación lo suficientemente barata para que de verdad ocurra, que es la única forma en que afecta algo.
A veces la respuesta honesta es que todavía no tienes nada que diseñar, porque la forma de la cosa no está decidida. Ese trabajo es descubrimiento, y produce artefactos y no pantallas.
Lo que sacas de ahí es el material desde el que se puede construir tu estimación. Un backlog descompuesto en épicas e historias de usuario, una arquitectura de alto nivel que declara con qué tiene que hablar tu sistema, y un plano de servicio que muestra dónde tu producto toca tu operación. Esos tres convierten una visión en un alcance que se puede cotizar en story points.
El descubrimiento es un proyecto aparte, no algo que se cuela dentro de tu construcción. También es el primer paso correcto más seguido de lo que la gente espera, y te lo vamos a decir en vez de entregarte pantallas de un producto que nadie ha delimitado.
Aquí el diseño y la ingeniería salen de la misma capacidad, así que el trabajo de diseño compite con las funcionalidades en vez de vivir en un presupuesto aparte que se te olvida. Eso hace que valga la pena saber qué es lo que de verdad cuesta.
La respuesta son los estados, no las pantallas. Una pantalla es un dibujo. Una pantalla con variantes vacía, cargando, parcial, error, sin conexión y permiso denegado son seis, y esas variantes son exactamente lo que se salta en una entrega y después inventa alguien de ingeniería a la carrera.
Si ya tienes algo construido, la forma más barata de saber si vale la pena comprar esta capacidad es vernos evaluar tu producto primero. Una auditoría heurística escrita, en dos o tres días hábiles, sin costo.
Todos los Indigo Design Awards que ha ganado este trabajo de diseño desde 2019, con la categoría en la que se otorgó y el producto que lo recibió.
Una revisión heurística escrita de lo que ya construiste
La capacidad a la que el diseño le va un ciclo por delante
Caso de estudio, y ganador de un Indigo
Cómo se cotiza el trabajo de diseño junto con la construcción
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.
