-
8 comentarios »
Hace ya un tiempo dijimos que una de las razones por las que empezamos tantas cosas y acabamos “tan pocas” y que debíamos solucionar, es porque no contamos con un diseñador que nos ayude a cristalizarlas. Lamentablemente seguimos sin contar con uno, pero para solucionar eso y reducir pequeñas frustraciones, hemos decidido no tirar una línea de código en un proyecto o idea mientras no tengamos el diseño del mismo.
Un prototipo visual completo (estático o dinámico) no sólo ayuda al cliente a entender claramente lo que está comprando y a mejorar la conversación con él, sino que también es mucho mejor para nosotros como equipo de desarrollo que una especificación funcional de 80 paginas (ademas todos sabemos ya que una especificación funcional no tiene nada de funcional).
El resultado de experiencias pasadas gestionadas de esta manera, como la Rails Rumble o el desarrollo de Trourist comparado con el resultado de otras ideas y proyectos nos ha llevado a ser más radicales en esta idea y dejar de excusarnos a nosotros mismos. De hecho no somos los únicos que vemos la prioridad que el Front End/UI tiene en el desarrollo de software.
Dedicando el tiempo y esfuerzo necesario a pensar el sistema o la aplicación en esta fase se consiguen múltiples ventajas:
- Reducir las indefiniciones y los malentendidos entre todos los miembros del equipo (AI, diseñadores, desarrolladores y el propio cliente).
- Un estado de desarrollo más real y palpable, dejando a la vista que queda por hacer.
- Un entorno de desarrollo más motivador, viendo el resultado final de tus avances.
- Esfuerzo más focalizados, con una meta clara y palpable (No more over-engineering!).
- Requiere la implicación del cliente que tiene que ir más allá de validar un documento que probablemente no ha leído y comprendido por completo.
Todo esto hace que finalmente avancemos más rápido, con más seguridad y viendo lo que estamos construyendo.
El prototipado y la interface de usuario no es obviamente la única fuerza directriz, puesto que finalmente todas esos elementos e interacciones se deben convertir en funcionalidades que a su vez ayudan de nuevo a enfocar y dirigir los esfuerzos… pero quizás si es la más importante. Al fin y al cabo es la parte en la que más personas intervienen… ¡y la que finalmente utilizará el cliente!
¿Quiere esto decir que es la forma ideal de trabajar?… ¿En cualquier tipo de proyecto?… ¿Para cualquier empresa?… Quizás no, pero sus ventajas hacen interesante que al menos lo probéis -posiblemente en un pequeño proyecto interno de bajo riesgo- y veáis si realmente es factible en vuestro contexto. En nuestro caso esta funcionando realmente bien y lo hemos adoptado como práctica estándar… ¿que opináis vosotros?.
8 comentarios para “Diseña primero, codifica después.”
Deja un comentario
LO ÚLTIMO DE LINKED
- We need a great designer
- Hablar por hablar, ese deporte
- Retos para el 2010 en Linking Paths
- Sobre los premios Buber, las críticas y la acción.
- Manifiesto: En defensa de los derechos fundamentales en Internet
- Consumidos por la reinvención
- ¿Quién es tu cliente?
- El factor psicológico
- Lanzamiento: Stage
- ¡Hola Competencia! Te estábamos esperando.
RSS de los últimos artículos
- JM. en Hablar por hablar, ese deporteLoose talk, the sport
(2 comentarios) - zp en Hablar por hablar, ese deporteLoose talk, the sport
(2 comentarios) - alberto en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - Raúl Murciano en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - Javier Aldana en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios) - alberto en Retos para el 2010 en Linking PathsChallenges for 2010
(8 comentarios)
RSS de los últimos comentarios
Linked, el blog de Linking Paths
-
Sobre LinkedLinked es el blog de Linking Paths, la empresa aventurera e innovadora formada por Aitor Garcia, Alberto Molpeceres y Roberto Salicio. En él hablamos de nuestros productos, ideas, y de compañías que nos sirven como guía y ejemplo. Si quieres conocernos un poco mejor puedes revisar lo que hemos escrito en los archivos.Español:English:
-
Proyectos, ideas, etc.
No puedo estar más de acuerdo. De hecho ya lo comentaban los de 37 signals. http://gettingreal.37signals.com/ch09_Interface_First.php
En el Cadius de Donosti, comentaba Aitor cómo utilizabais behaviour driven development y que el intentar crear las pruebas antes del código, creaba pruebas muy frágiles.
Lo que a mí está funcionando ahora mismo es crear primero las interfaces (interfaces reales, navegables, con toda la interacción posible y diseñadas para que el cliente de la mayor cantidad de feedback), mediante esas interfaces ir descubriendo cómo será el Model, y luego crear pruebas…
Un saludo!
En mi grupo de trabajo es una práctica habitual partir de un documento de wireframes a la hora de enfocar un desarrollo: Los wireframes definen las pantallas de la interfaz de usuario y sus elementos, la navegación entre las mismas y la interacción con el usuario, pero no el aspecto final.
Estos wireframes hacen las veces de documento de requisitos de usuario: El cliente no sabe lo que quiere hasta que lo ve en pantallitas.
Los resultados son buenos, tanto que en muchos proyectos no se empieza con el desarrollo hasta que el cliente ha aprobado el documento de wireframes, y por experiencia suele dedicarle más tiempo a revisarlo y a centrarlo que a un documento de análisis detallado o funcional.
Saludos,
Félix.
Yo he intentado, cuando me han dejado, aplicar esa idea desde hace mucho tiempo y para mí es parte del análisis, ya que en caso contrario y como bien dices, los clientes/usuarios te dicen en muchos casos “sí, sí” sin haberse leido o entendido lo que realmente dice un documento funcional o les puedas decir de palabra.
En algunos proyectos que he vivido la diferencia es brutal, de que un compañero mío les muestre el modelo DER (con unas 10 tablas relaciones etc.) y les pregunte si “está ahí toda la información que necesitan”, no veas la cara de pasmo que se les quedó, a mostrarles un modelo HTML estático con los campos que podran ver y que te digan “pero me falta la edad y el movil, necesito un enlace para poder hacer…”.
La pega más común que me he encontrado es que viendo la maqueta, clientes e incluso jefes piensen que ya esta todo hecho y luego se exasperen por que no termines “al día siguiente”, ¿Si total solo es guardarlo en BDD no? :)
Ánimo con ello.
Efectivamente, estoy de acuerdo con vosotros. Creo que para los reyes me pediré un diseñador :P.
Yo no puedo estar más de acuerdo, y por experiencia. El proyecto que ahora me ocupa se inició con un documento “funcional” en el que detallé todo lo que hasta ese momento sabía de lo que tenía que hacer la aplicación, y lo mejor es que fue con la ayuda del cliente. Un documento de 80 páginas que fue aprobado al día siguiente de haberlo terminado. Y claro, los cambios durante el desarrollo han sido el pan de cada día, con todo el retraso que eso conlleva. Sin embargo, desde que trabajamos con wireframes con los que intentamos recrear la usabilidad y la interacción con el usuario final, las cosas van más rodadas y las modificaciones sobre el desarrollo mucho menores.
Totalmente de acuerdo.. me mearé encima el día que me pidan un desarrollo y como documento de requisitos me presenten las maquetas en bonito y claro xhtml/css.
Er… Yo también estoy de acuerdo. :D
Completamente de acuerdo.
Es que en realidad la mayor parte de las personas tienen un pensamiento bastante concreto, por lo cual hablar de algo en “abstracto” no les dice mucho. Así, que mostrar algo lo más parecido a como se verá al final ayuda mucho.
Ahora mismo estamos haciendo el prototypo visual completo de un proyecto, con el que tuvimos varias dificultades para entender los requisitos reales. Así que al final, llegamos a esta misma solución, que creo que va a ser muy buena forma de salir del embrollo :-D.