Diseño de producto
Diseño de producto para flujos de trabajo complejos
Investigación de UX, diseño de interfaces y sistemas de diseño para plataformas, herramientas internas y apps, entregados de forma que sus ingenieros puedan construirlos sin adivinar.
Para equipos cuyo producto tiene reglas, roles y casos límite reales, y que necesitan un diseño que resista el desarrollo.
- Entregable
- Prototipos y un sistema de diseño, no maquetas estáticas
- Probado
- Con las personas que usarán el producto
- Traspaso
- Especificado para ingenieros, en inglés o español
- Investigación Entrevistas, observación y analítica
- Estructura Flujos, roles y arquitectura de información
- Prototipo Flujos navegables probados con usuarios reales
- Sistema Componentes, tokens y especificaciones
Primero la investigación
Las decisiones de diseño parten de cómo se hace el trabajo en realidad.
Probado
Los prototipos se revisan con usuarios reales antes del desarrollo.
Construible
Cada pantalla se especifica para los ingenieros que la construirán.
El problema de negocio
El software complejo suele fallar en la interfaz.
La lógica puede ser correcta y el producto fracasar igual, porque quienes lo usan no encuentran lo que necesitan, no confían en lo que ven o tardan el triple de lo que el proceso debería. El diseño es donde se deciden esos costos, casi siempre antes de que alguien los mida.
Los usuarios piden capacitación para tareas rutinarias
La interfaz refleja cómo está construido el sistema, no cómo se hace el trabajo.
Cada pantalla se ve un poco distinta
No hay componentes compartidos, así que cada función inventa sus botones, tablas y formularios.
Diseños que no se pueden construir tal como están
Maquetas que ignoran datos, estados y casos límite, reinterpretadas por ingenieros con prisa.
Funciones publicadas que nadie usa
Decisiones tomadas en reuniones, nunca probadas con las personas a quienes debían servir.
Tableros llenos de números y vacíos de respuestas
Datos en pantalla sin una pregunta que deban responder.
Un producto que se ve más viejo que la empresa
Una interfaz que resta credibilidad a un servicio que por lo demás es sólido.
Resultados
Qué debe cambiar el diseño de producto.
- 01
Tareas con menos pasos
Flujos diseñados en torno al trabajo, con el camino habitual corto y el excepcional todavía posible.
- 02
Consistencia por defecto
Una biblioteca de componentes que hace del patrón correcto el más fácil de usar.
- 03
Menos sorpresas en el desarrollo
Estados, errores, pantallas vacías y permisos especificados antes de escribir código.
- 04
Decisiones respaldadas por evidencia
Hallazgos de usabilidad y analítica detrás de cada cambio, en lugar de preferencias.
Alcance
¿Qué podemos diseñar?
La mayoría de los proyectos combina investigación, un conjunto de flujos principales y los componentes que esos flujos necesitan.
Productos SaaS
Incorporación, cuentas, roles, configuración y el flujo principal por el que pagan sus clientes.
Herramientas internas
Sistemas administrativos donde la velocidad y la precisión importan más que la decoración.
Tableros e informes
Vistas construidas en torno a las decisiones que toman las personas, no a los datos que existen.
Portales de clientes
Estado, documentos, solicitudes e historial presentados para que los clientes dejen de escribir para preguntar.
Interfaces de apps móviles
Flujos para uso con una mano y con interrupciones, consistentes con el producto web.
Sistemas de diseño
Componentes, tokens, patrones y documentación compartidos por diseño e ingeniería.
Rediseño de un producto existente
Mejora gradual de un producto en uso sin tener que capacitar de nuevo a todos los usuarios a la vez.
Prototipos de validación
Flujos navegables para probar una idea con usuarios o inversionistas antes de construirla.
Enfoque
Diseño entregado como sistema, no como imágenes.
Un conjunto de pantallas pulidas muestra cómo podría verse el producto. No le dice a los ingenieros qué pasa cuando faltan datos, un usuario no tiene permiso o una solicitud falla. Esas respuestas son parte del diseño.
Maquetas estáticas
- Solo pantallas del camino ideal
- Estilo visual decidido pantalla por pantalla
- Entregadas como imágenes
- Sin pruebas con usuarios
- Casos límite resueltos en el código
- Termina en el traspaso
Diseño de producto de ZitDevs
- Investigación con usuarios reales
- Flujos con estados y errores
- Componentes y tokens reutilizables
- Prototipos probados
- Especificaciones para construir
- Acompañamiento durante el desarrollo
Encaje
Para quién es este servicio.
Buen encaje cuando
- El producto tiene varios tipos de usuario, permisos o reglas complejas.
- Los usuarios se quejan, necesitan capacitación o crean atajos fuera del producto.
- Un producto nuevo necesita validar sus flujos principales antes de desarrollarse.
- Varios equipos construyen funciones y la interfaz ya no parece un solo producto.
- Alguien puede facilitar acceso a las personas que usan el producto.
Probablemente aún no cuando
- La necesidad es una identidad de marca o piezas de marketing y no un producto.
- Nadie puede dar al equipo de diseño acceso a usuarios o expertos del negocio.
- El producto se construirá sin que ingeniería revise el diseño.
Proceso
Cómo se diseña un producto.
Cada etapa termina con algo que usted puede revisar, probar o entregar a un ingeniero.
Investigación
Entrevistas, observación del trabajo real, analítica y revisión del producto actual y de la competencia.
Definición
Usuarios, roles, tareas y los flujos que más importan, por escrito y acordados.
Arquitectura de información
Navegación, estructura y relaciones entre datos antes de cualquier diseño visual.
Prototipos
Flujos navegables de fidelidad creciente, revisados con los responsables.
Pruebas de usabilidad
Sesiones con usuarios reales sobre el prototipo, con hallazgos ordenados por impacto.
Sistema de diseño y especificación
Pantallas finales, componentes, estados y tokens preparados para desarrollo.
Acompañamiento en desarrollo
Revisión de lo construido, respuestas a ingeniería e iteración después de publicar.
Traspaso
Hecho para implementarse.
El diseño solo genera valor cuando se publica. El paquete de traspaso está pensado para los ingenieros que lo usarán, sea el equipo de desarrollo de ZitDevs, su equipo interno u otro proveedor.
Especificado para desarrollo
Comportamiento, validaciones, estados y reglas adaptables documentados junto al diseño visual.
Tokens compartidos con el código
Colores, tipografía y espaciado definidos una vez y utilizables directamente por los ingenieros.
- Flujos
- Todos los estados
- Componentes
- Reutilizables
- Tokens
- Compartidos
- Especificaciones
- Por pantalla
Modelos de contratación
Cómo se contrata el trabajo.
Proyecto de diseño
Investigación, flujos principales y sistema de diseño para un alcance definido.
- Alcance y entregables por escrito
- Prototipo probado incluido
- Ideal para un producto nuevo o un rediseño mayor
Diseño y desarrollo
Diseño y construcción a cargo del mismo equipo, bajo un solo acuerdo.
- Sin traspaso entre proveedores
- Los diseñadores acompañan el desarrollo
- Ideal cuando ZitDevs desarrolla el producto
Diseñador integrado
Capacidad de diseño continua junto a su equipo de producto.
- Capacidad mensual acordada
- Investigación e iteración continuas
- Ideal para un producto en evolución
Por qué ZitDevs
Qué hace que el diseño sea utilizable.
Diseñadores que trabajan con ingenieros
Diseño y desarrollo están en la misma empresa, así la viabilidad se revisa mientras se toman las decisiones.
Probado, no supuesto
Los flujos principales se prueban con usuarios reales antes del desarrollo y los hallazgos se comparten por escrito.
Interfaces bilingües
Productos diseñados y redactados en inglés y español, con diseños que funcionan en ambos.
Accesible por defecto
Contraste, foco, uso con teclado y tipografía legible son requisitos, no extras.
Preguntas frecuentes
Preguntas sobre diseño de producto.
Las respuestas están escritas para este servicio. Cuando una cifra depende de su situación, lo decimos en lugar de publicar un promedio.
¿Cuánto cuesta el diseño de producto?
El costo depende de la cantidad de tipos de usuario y flujos principales, cuánta investigación se necesita, si incluye un sistema de diseño y si el producto ya existe. Entregamos una estimación escrita después de una conversación inicial, con el alcance y los entregables explícitos.
¿Cuánto tarda un proyecto de diseño?
Depende del alcance del primer conjunto de flujos. Ordenamos el trabajo para diseñar y probar primero los flujos de mayor valor, de modo que el desarrollo pueda empezar con ellos mientras continúa el resto.
¿Solo diseñan o también construyen?
Ambas cosas. El diseño puede entregarse por sí solo o como parte de una relación de diseño y desarrollo en la que la misma empresa construye el producto. El diseño por sí solo se especifica para que cualquier equipo de ingeniería pueda implementarlo.
¿Pueden rediseñar un producto existente sin afectar a los usuarios?
Sí. Normalmente recomendamos un enfoque gradual: mejorar primero los flujos de mayor impacto, introducir componentes compartidos poco a poco y medir el efecto de cada cambio.
¿Hacen investigación con usuarios?
Sí. La investigación puede incluir entrevistas, observación del trabajo real, revisión de analítica y pruebas de usabilidad. La profundidad se acuerda por proyecto según qué decisiones necesitan evidencia.
¿Qué herramientas de diseño usan?
Habitualmente Figma para diseño, prototipos y bibliotecas de componentes. Los archivos y las bibliotecas se entregan como parte de los entregables.
¿Pueden crear un sistema de diseño para nuestro producto?
Sí. Incluye componentes, tokens, patrones y documentación de uso, diseñados según cómo su equipo de ingeniería construye la interfaz.
¿Quién es dueño de los archivos de diseño?
La propiedad de los entregables se define en el contrato de cada relación, antes de comenzar.
Cuéntenos qué flujo está frenando a su equipo.
Describa el producto, quién lo usa y dónde tiene dificultades. Volveremos con un alcance de diseño, la investigación que necesita y un plan para construirlo.
El formulario llega preseleccionado para diseño de producto, con preguntas acordes al proyecto.