Un completo curso de diseño gráfico, ilustración, diseño web y tipografía.

Proceso, Metodología, Ciclo de vida, uf!

por Meryl K. Evans

Proceso, Metodología, Ciclo de vida: no importa cómo llames el proceso de gestionar tu proyecto de diseño desde comienzo a fin, te puede salvar el pellejo. Te encuentras con un cliente que quiere que le diseñes un sitio web. Ningún problema, eso es lo que tú haces. ¿Has experimentado lo siguiente?

  • Cambios en el objetivo
  • Cambios en el presupuesto
  • Retrasos en el lanzamiento
  • Cuestiones de mantenimiento

Puede que ya sea hora de seguir un proceso que remarca las fases de tu proyecto de diseño web. No tiene que ser complejo. Incluso una persona sola puede hacerlo.

No hay dos procesos iguales

No hay dos metodologías de diseño de web o de software idénticas. He trabajado en un estudio producción en la mayor parte de mi carrera y cada compañía tiene similitudes y diferencias en lo que es su ciclo de vida. En general, las fases son similares y cumplen con el mismo objetivo: un producto que satisface los requisitos del cliente.

Si no lo tienes claro, empecemos con tu próximo proyecto y documentemos lo que haces a medida que trabajas en él. Los más afortunados que trabajan con múltiples colaboradores apreciarán tener documentación en especial cuando un empleado se marcha o es despedido. El nuevo trabajador (o el desafortunado empleado que debe doblar su tarea al asumir la del que ya no está) depende de la documentación para seguir allí donde el empleado desaparecido lo dejó.

El ciclo de vida se divide en fases porque cada una tiene actividades específicas y resultados que se pueden presentar como consecuencia de esas actividades. Antes de continuar a la fase siguiente, asegúrate de que todas las actividades y productos están completos. Si no lo haces, cuenta con encontrarte con más problemas de lo habitual.

Requisitos

Antes de trabajar en prototipos, querrás entender bien los requisitos del cliente o el objetivo del proyecto. Al principio del proyecto, reúne información, completa una investigación básica, analiza el presupuesto, esboza el calendario, revisa las necesidades de mantenimiento, establece el propósito del sitio, y documenta quien es la audiencia diana (¡sabes que no es el cliente el que se tendrá que enfrentar al sitio web!).

En la mayoría de casos, esta es la parte del perfil del proyecto. Este es un ejemplo muy básico, y puedes modificarlo a medida que vayas ganando experiencia. Identifica un sólo punto de contacto con el cliente para evitar molestias de todas partes. Vale la pena alacrar y documentar los papeles y responsabilidades de los que participan en el proyecto.

A medida que progrese el proyecto, un cliente típico o colega intentará añadir más cosas, especialmente al descubrir todas esas cosas bonitas y animadas de la web. Considera la necesidad de explicar al cliente que cualquier cambio durante el proyecto implica un documento de solicitud de cambios. El documento expresa el nuevo requisito, las modificaciones en el calendario y el presupuesto aprobado para los cambios. Demasiado frecuentemente, los diseñadores se encuentran a sí mismos dando su aprobación a añadir estas cositas puesto que está trabajando en ello de todos modos. Estos fastidiosos añadidos aumentan y acaban por convertirse en noches sin dormir.

Puntos que es mejor incluir en los requisitos:

  • Mensaje
  • Audiencia
  • Acción
  • Contenido
  • Capacidades tecnlológicas
  • Mantenimiento / soporte
  • Administración
  • Promoción del sitio / motores de búsqueda
  • Calendario/li>
  • Sistema de nomenclatura
  • Puntos a considerar en las comunicaciones

Cuando todos las firmas y aprobaciones están en su lugar, sigue adelante y pasa al Diseño.

Diseño

Este no es lo mismo que desarrollo, cuando empiezas a escribir código. Durante esta fase, desarrolla la arquitectura del sitio utilizando un mapa, prototipos o storyboards y / o diagramas de flujo.

Este es el lugar para documentar cómo funcionarán las características del sitio. Además, esboza los procedimientos o pasos que los usuarios necesitarán para completar una tarea. por ejemplo, una compañía que exija una tienda en línea necesitará procedimientos para encontrar, seleccionar y adquirir los productos. Si otra compañía gestiona la fase de comprar en la tienda, deberás tratar con una interfaz. ¿Qué harás? Documenta cómo funcionará la interfaz.

Si el proyecto tiene sonido, videos o contenido multimedia, es la hora de definir el contenido y conseguir la aprobación. De nuevo, debes obtener la aprobación de todos los aspectos del diseño antes de proceder a su desarrollo. Es mucho más fácil hacer cambios aquí que en la fase de desarrollo.

Desarrollo

A estas alturas ya deberías saber qué quiere el cliente, incluyendo el aspecto y las connotaciones del sitio, la navegación y la funcionalidad. Es la hora de crear las piezas del rompecabezas y montarlo.

Mientras trabajes en los componentes, ponlos a prueba. Es mejor arreglar un problema cuando todavía forma parte de la pieza más pequeña. Además, desarrolla la base de datos y todo el trabajo invisible. Cuando el rompecabezas está montado y el diseño beta está listo para revisar, pasa a la fase de pruebas.

Tests

Hay quien argumenta que las pruebas no deberían ser una fase porque sucede a través de diversas fases. Si bien es cierto, es necesario hacer un test del producto final para asegurarse de que funciona correctamente como una unidad, y que todo está integrado con éxito. Recuerda que hiciste pruebas individuales durante la fase de desarrollo. Algunos talleres hacen tests de componentes, módulos, sistemas y aceptación. Hay un artículo en A List Apart, Testing 1-2-3 con los detalles específicos del mundo de las pruebas.

No sólod debes asegurarte de que el sitio se ve bien, sino de que su funcionamiento y velocidad son correctos. Intenta obtener la opinión del cliente y de los usuarios finales, ya que ellos serán los que utilicen el sitio. Intenta añadir una prueba de usuario a los requisitos expresados al comienzo del proyecto y explica su objetivo al cliente. Aún mejor, dile al cliente que los usuarios no están tan bien informados como el cliente sobre los productos y servicios, así que necesitas gente menos experimentada para probarlo. Es perfectamente legal hacer un poco la pelota.

Implementación / Producción / Mantenimiento

Finalmente atacas todos los imprevistos, validas el código del sitio, y verificas la accesibilidad. Es la hora de publicar el sitio. Al principio del proyecto, piensa cuánto mantenimiento y soporte ofrecerás, si no vas a ser el responsable de esta parte a largo plazo.

Crea una guía de estilo y enseña al cliente a mantener el sitio usando la guía. Como de costumbre, haz una copia de seguridad por si acaso, no se que alguien lo fastidie, cosa que casi siempre pasa.

Cuando surgen nuevos requisitos o cambios, repite el nuevo ciclo. Si ocurren problemas que podrían haberse evitado o previsto, documéntalos en tus requisitos o en las plantillas de diseño para acordarte de tratarlas con el cliente la próxima vez.

Molestias finales

Cuando un cliente quiere establecer un sitio, sus expectativas son siempre altas gracias a la alta calidad y el buen desarrollo de los sitios que hay en la web. Es tu misión educarle en los costes que implica tener un buen sitio que además funcione bien y sea práctico. Los grandes negocios tienen el dinero y los recursos para implementar todos los trucos y son esos sitios los que el cliente medio descubre y empieza a soñar con tener uno igual.

Antes de acabar cada fase, asegúrate de que has completado todos los pasos. Puede venirte bien tener a mano una lista de comprobación antes de salir de la fase. Si olvidas algo la primera vez, añádelo para recordarlo la próxima vez. La belleza de la documentación y los procesos es la capacidad para adaptar, añadir y modificar a medida que trabajas en el ciclo de desarrollo.

En cualquier caso, ¡comunícate! En mi experiencia, la falta de comunicación es la causa de al menos el 75% de los problemas de desarrollo. Evita dar por supuestas las cosas a menos que estén documentadas. Por mucho que nos gustaría hacerlo, no podemos leer la mente de los demás como hacen en Star Trek.

Meryl K. Evans es un diseñador de web freelance, escritor, y editor.

[ Este artículo ha sido traducido con permiso de A List Apart y su autor.]