¿Cuáles son sus procesos de pensamiento al diseñar la interfaz de usuario de una aplicación web de consumo?

Tiendo a seguir una hoja de ruta estándar que aprendí al diseñar sistemas embebidos. No es la única forma, pero me gusta porque hace un esfuerzo por limitar las sorpresas y los problemas, y se centra en el envío y la iteración. También funciona bien para el desarrollo grupal, porque es fácil dividir las tareas y limitar el bloqueo. Dice así:

1. Arquitectura: comience con el diseño y las especificaciones de requisitos para el sistema. La especificación de diseño es lo que necesita hacer y cómo planea hacerlo. La especificación de requisitos introduce restricciones numéricas estrictas en las diversas partes de la especificación de diseño. (si tenía un botón de búsqueda, aquí es cuando decide cuántos resultados aparecerán y cómo maneja la paginación, cosas así). Los más útiles son los diagramas de estado y los diagramas funcionales. Realice casos de prueba, para que pueda probar la funcionalidad que crea funciona de la manera que desea. Una investigación adecuada lo ayudará a reinventar la rueda y acelerar su desarrollo.

2. Desarrollar: escribir código para cumplir con sus especificaciones.

3. Prueba y depuración: verifique todo con los casos de prueba que realizó.

4. Enviar: sáquelo y comience a usarlo. Siempre puedes mejorarlo. Sentarse y esperar que sea perfecto lo dejará frustrado. Siempre se enviará.

5. Comentarios: ¿la actividad del producto aumentó o disminuyó? ¿Se están registrando más personas? Concéntrese en analizar cada objetivo específico para el producto. Escucha a los clientes. Siga los análisis, los datos no mentirán.

6. Iterar y enviar: utilice sus comentarios. ¿Necesita volver a trabajar algunos procesos en el paso de arquitectura? Crear nuevos casos de prueba. Prueba. Enviar. Siga los comentarios. El proceso continua.

No tiene que hacerlo bien la primera vez. La mayoría de las veces, con las aplicaciones de consumo, aprenderá rápidamente si la forma en que lo hace es la forma en que debe ser. Por lo tanto, itere y envíe, pero eso no significa que deba aflojar el paso de la arquitectura. Debe tratar de obtener el producto lo más cerca posible de acuerdo con sus primeros análisis y objetivos.