Capacidades del software
El software de diseño de aplicaciones resulta útil cuando una idea para una pantalla necesita más que un boceto visual. Empieza por decidir si necesitas trazar una tarea, definir patrones de interfaz reutilizables o preparar decisiones para un equipo de producto; después, elige un flujo de trabajo en el navegador que te permita comprobar el trabajo realizado.
La diferencia es una cuestión de alcance: ¿estás explorando una dirección o tomando decisiones de interfaz que deben funcionar en varias pantallas? La comparación siguiente te ayuda a elegir.
Un proceso de diseño de aplicaciones centrado en el software merece la pena cuando te ayuda a tomar decisiones relacionadas entre sí, no solo a dibujar una pantalla más pulida.
Escribe el objetivo del usuario y, después, sigue el recorrido por las pantallas desde el inicio hasta completar la tarea. Una pantalla de bienvenida puede resultar convincente por sí sola, pero el problema de diseño de aplicaciones se hace evidente cuando la siguiente acción, un error y una ruta de regreso también deben tener sentido.
Documenta la navegación, las etiquetas, las decisiones de espaciado y los estados de respuesta cada vez que se repitan. Así, un conjunto de pantallas atractivas se convierte en una especificación de interfaz coherente que un compañero puede revisar.
Evalúa una tarea realista en cada pantalla: ¿puede alguien encontrar la acción principal, entender qué ha cambiado y recuperarse de un error? Registra las preguntas pendientes en lugar de presentar un borrador visual como si fuera un producto probado.
Usa esta tabla como lista de verificación inicial. Compara dos formas de abordar el trabajo, no listas de funciones verificadas de un producto concreto.
| Punto de partida general en el navegador | Proceso de diseño de aplicaciones centrado en el software | |
|---|---|---|
| Primera aportación | Una idea preliminar de pantalla o una referencia visual | Un objetivo del usuario y la tarea que debe poder realizar |
| Alcance inicial | Una pantalla para explorar una dirección | Una secuencia breve que incluya lo que ocurre después |
| Navegación | Sugerida por la composición | Definida y comprobada según el recorrido del usuario |
| Elementos repetidos | Se tienen en cuenta a medida que evoluciona el borrador | Se documentan para mantener la coherencia entre pantallas |
| Estados | Suelen comenzar con la vista predeterminada | Incluyen preguntas sobre los estados vacío, de error y de finalización |
| Pregunta de revisión | ¿La dirección comunica la idea? | ¿Puede alguien completar la tarea prevista? |
| Siguiente paso | Elegir una dirección prometedora para desarrollarla | Determinar qué requiere pruebas o detalles de implementación |
Un proceso de diseño centrado en el navegador puede ayudar a organizar las decisiones, pero un borrador de pantalla no es una prueba de usabilidad, una aplicación funcional ni una garantía de que una herramienta concreta ofrezca todas las funciones que necesitas.
Necesitas mostrar la primera tarea en el móvil antes de hablar de la implementación.
Una plantilla puede ayudarte a examinar la estructura de las pantallas, pero sustituye el contenido de ejemplo por el objetivo real del usuario y comprueba el recorrido completo.
Tienes una dirección visual, pero aún no se ha acordado la navegación ni el comportamiento ante errores.
Define los estados que faltan antes de pulir los detalles; un flujo de trabajo con una herramienta de creación puede ayudarte a explorar opciones, pero no puede definir por sí solo las reglas del producto.
El equipo necesita distinguir entre una propuesta visual y una especificación de implementación.
Revisad juntos los flujos, las etiquetas y las preguntas pendientes sobre el comportamiento; después, documentad por separado las restricciones técnicas.
Estás puliendo los componentes mientras la tarea general sigue sin definirse.
Separa el estilo de la interfaz de la navegación y la lógica de tareas de la aplicación para no confundirlos.
Abre el punto de entrada en el navegador con un objetivo de usuario en mente. Esboza la primera pantalla, lo que viene después y las preguntas que un compañero necesitaría resolver antes de considerar el borrador como un plan. Comprueba las funciones disponibles en el producto al que accedes, en lugar de dar por hecho que existe una descarga para escritorio o una opción de exportación concreta.
Busca una forma de examinar más de una pantalla, mantener la coherencia de las decisiones de interfaz que se repiten y revisar qué ocurre cuando una tarea se completa o falla. Comprueba en el sitio web de la herramienta cualquier función específica de colaboración, creación de prototipos o exportación antes de depender de ella.
No necesariamente. Un punto de partida centrado en el navegador puede ayudarte a empezar a planificar pantallas y flujos sin dar por hecho que existe una aplicación de escritorio; consulta los requisitos actuales del sitio de destino para conocer su proceso de trabajo.
Una maqueta muestra una pantalla en un momento concreto. Un proceso de diseño de aplicaciones centrado en el software también plantea cómo llega alguien a esa pantalla, qué acción viene después y qué patrones o estados deben mantenerse coherentes.
Un borrador te da algo concreto que revisar, pero no demuestra que las personas puedan completar una tarea. Pide a alguien que no conozca el diseño que siga un escenario realista y después revisa los pasos que le resulten confusos.
Escribe una frase que describa lo que el usuario quiere hacer y esboza la primera acción que realizaría. Añade la siguiente pantalla solo cuando puedas explicar por qué es necesaria; así mantendrás el alcance inicial bajo control.