Hace poco un conocido (geek) me preguntaba que tal me iba con Linking Paths: “¿Habéis empezado a programar ya algo?”. La respuesta le dejó un tanto parado: “No”. En Linking Paths pensamos que el primer paso para construir una aplicación de la manera más rápida y acertada posible es construir el interface. Simplemente es una apuesta más segura y productiva. En este punto (y en bastantes más) coincidimos con la gente de 37signals y su principio de “Interface first”. Pero…¿qué ventajas tiene este enfoque?
Es difícil para la gente que nos hemos formado de manera técnica (léase desarrollando), percibir o incluso admitir lo vital del diseño de un interfaz. En muchas ocasiones nos encontramos con un acercamiento totalmente contrario: la creación de gran parte de la infraestructura durante semanas o incluso meses, y una ultima semana de sprint poniendo piel sobre todos estos huesos, culminando meses de trabajo en una experiencia de usuario lamentable… creedme, he sentido ese dolor.
Sin embargo abrazar el paradigma de diseñar primero y programar después, nos da la posibilidad de tocar la aplicación antes de que tiremos siquiera la primera linea de código, cuando los cambios aun no generan pequeñas revoluciones francesas en nuestros repositorios de subversion. Estos diseños en HTML nos van a servir ademas como guía de implementación de las funcionalidades. Una vez tenemos una aplicación que podemos tocar es realmente motivador ir codificándola poco a poco. Transformar un desplegable de cartón piedra en una lista viva de clientes, sustituir un formulario hueco en una introducción de datos real… es algo así como dar vida a un ser inanimado.
Por ultimo, devolverle al interfaz el respeto que se merece, nos sitúa más en consonancia con las verdaderas necesidades y deseos de los usuarios. Lo que ellos están comprando es lo que ven, lo que pueden tocar, independientemente de lenguajes, servidores, bases de datos, etc… Si analizamos una de las figuras favoritas de Kathy Sierra (…como se echa de menos este blog…) podemos ver como prácticamente todo lo que quiere y necesita un usuario se lo da el interfaz:
Copyright © Kathy Sierra, original image >>
Por todo ello, esta semana hemos comenzado a construir el interfaz de las principales funcionalidades de Tabula, de las que os iremos presentando pequeñas preview en las próximas semanas. Creemos que Tabula puede ser una gran aplicación que traiga un visión renovada al mundo de la gestión del feedback y que empezar con el interfaz nos ayuda a centrarnos en que queremos que la aplicación transmita. De hecho estamos seguros -porque lo hemos vivido- de que no hacerlo así perjudica la usabilidad y aumenta las posibilidades de que los usuarios no se enganchen a nuestra aplicación.
Y vosotros… ¿qué importancia le dais al interfaz en vuestras aplicaciones?.
Cuando se trata de un producto que estamos “inventando” si me parece adecuado empezar con la interfaz de usuario, al fin y al cabo estamos proponiendo el funcionamiento y la imagen. Pero cuando vamos a implementar algo “grande”, de acuerdo a los requerimientos de un cliente, primero hay que dimensionarlo para ver en que nos vamos a meter, ahí no creo que los prototipos sean útiles; pueden quedar muchas cosas por fuera, cuando el negocio es grande hay muchos procesos por ahí escondidos, reglas que nos van a limitar la presentación, etc, etc.
En fin que es una buena pero “peligrosa” propuesta, se me antoja que una interfaz de usuario hace ver las cosas más fáciles de lo que son.
No esperaba que la carta de la “gran” aplicación se emplease tan rápido, pero es lógico que así sea… puesto que un camino más abierto como este suele levantar suspicacias. Quizás empezar por el interfaz sea algo que no se adapte a todas la metodologias de trabajo, todos los grupos de desarrollo o incluso a todos los contextos. No queriamos establecer una ley universal… pero … a las “grandes” aplicaciones… ¿por qué?. ¿Acaso los usuarios de la Administración Publica son o actúan de manera distinta a los demás?. ¿Quizás los empleados de una empresa de 1000 personas se transforman al entrar por la puerta y ya no usan las aplicaciones como cuando están en su “pequeña” casa, con sus “pequeñas” aplicaciones?.
Los usuarios no utilizan esos procesos que están tan escondidos, ni les importa su existencia, ni la de una base de datos, ni quieren que el uso de la aplicación este supeditado a ciertas reglas. Ese es nuestro trabajo, no el suyo. Por lo tanto centrandonos en estos aspectos estamos haciendo un mejor software para nosotros, lo cual es obviamente un mal destino para las vías de nuestra aplicación. No estoy quitando importancia a estas partes, pero si dejandolas donde deben quedarse: detrás del interfaz, algo más sencillo de conseguir empezando primero por él.
Sinceramente… a este respecto, el tamaño no importa. Que quien esta al otro lado de la pantalla sea un ser humano… si.
Que voy a decir, pero en esto estoy con Aitor al 100%. Realmente no comparto el asunto de que para aplicaciones grandes una aproximación basada en prototipos no sea la adecuada, entre otras cosas porque es más sencillo trabajar sobre una pantalla que sobre un documento de 300 páginas para obtener y validar la información que se obtiene. Esto no quiere decir que no se tenga que realizar otra documentación o investigación de requisitos y su dimensionamiento, simplemente me sigue pareciendo la más adecuada. Porque lo normal es que lo que piensa el cliente que es “un pedido” (por poner algo) no sea exactamente lo mismo para nosotros, porque acabamos pensando de una forma excesivamente técnica, y cuando al final nos damos cuenta del error, o el cliente acaba pidiéndonos que combinemos en una pantalla diferente información, nos encontremos con tener que hacer “virguerías” (ej: joins que dan miedo) para poder darle solución. Si lo que se quiere es satisfacer plenamente al cliente, creo que es el camino.
Otra cosa es que si todos los clientes valen para trabajar de esta forma, o incluso si todas las empresas de informática pueden hacerlo, pero eso es otro cantar.
Hola,
yo quería aportar un poquito más a parte de esta teoría. Un buen diseño (gráfico además de funcional) hace que el cliente, usuario, quien quiera que lo vaya a utilizar se sienta más cómodo aunque el funcionamiento no sea del todo correcto. Con esto no quiero decir que no se deba cuidar la programación, creo que es lo más importante al fin y al cabo, si no que un interfaz bonito y, como se dice, amigable (”del castellano agradable”) vende mucho más. Al fin al es con lo que se tiene que pelear el usuario.
Por cierto, aún no os había felicitado por el relanzamiento. Felicidades! Y qué envidia, no por solo vivir de lo que os gusta si no por hacerlo tal y como os gusta.
:)
Gracias por la felicitacion VictorR.
Como deciamos en el articulo “El interfaz es tu producto” nos guste o no. De la misma manera que si nuestros clientes son maquinas (que puede darse el caso perfectamente) “El API es tu producto”. Sea quien sea nuestro cliente - seres humanos o maquinas - poseen un modelo mental al que debemos ajustar nuestro modelo programatico. En algunos casos las empresas hacen que los usuarios traguen carros y carretas en cuanto a como funcionan las aplicaciones, ante lo cual normalmente los usuarios suelen responder con atajos y trucos de todo tipo. Por ello, de nuevo, cuando antes admitamos que para los usuarios lo primero y ultimo que ven de nuestra aplicacion es el interfaz, mejor.
Y eso, como dices VictorR, suele conllevar dos magnificos resultados:
Al:
Puede que ya lo conozcas, pero si no es así te lo recomiendo, muy ameno, refrescante y lúcido:
http://www.mordecki.com/libro/descargarlibro/descargarlibro.shtml
Estoy de acuerdo, aunque yo uso Model Driven Architecture con andromda donde la interfaz es creada por el generador y no relativamente antes de empezar, yo creo que dedicarse a la interfaz es pensar primero en el cliente(el negocio, nuestro dinero), y este paradigma esta en contra que el programador se centre mas en las soluciones técnicas que en las funcionales.
Ok, creo que las ventajas de comenzar por la interfaz son indiscutibles, no estoy en absoluto desacuerdo con ellas.
El asunto que no me gusta es sentarse con el cliente y transformar cada palabra en un cuadro de texto, un botón, un listado, etc. La impresión que me estoy llevando de estos comentarios es que hay demasiada premura por la pantalla y, esto se trata más bien del sueño de nosotros los programadores de tener rápidamente prototipos sobre los cuales “programar” y empezar a pensar en función del código ¿O no?.
Pero lo dicho, tampoco me gusta mucho eso de diseñar durante 6 meses y al final crear unas pantallas que van a dejar desconcertado al cliente por que tenía algo muy diferente en su cabeza. Más bien como todo en la vida, hay poco de lo uno y un poco de lo otro, la interfaz es importante, pero no necesariamente lo más, incluso a veces nos da una visión sesgada de el negocio por que todo empieza a verse en función de como ingresar información y como la vamos a ver luego de retorno. Y no, además de una buena, cómoda y ergonómica interfaz, el cliente lo que necesita es tomar decisiones adecuadas con la información que le entrega su software (bueno, otra cosa serían los sistemas de tiempo real) y empezar a modelar un negocio por la interfaz es desconocer los objetivos que este tiene.
En fin que a veces el cliente es diferente del usuario final.
PD: Perdón por llegar tarde.
Sinceramente…no. No al menos en el caso de Linking Paths. Se trata más bien del sueño de hacer que los usuarios tengan herramientas que mejoren su vida en el mayor grado que humanamente podamos. Son ellos, no nosotros.
Lo siento pero no esto no lo entiendo. Diseño != Interfaz. Buen interfaz == Buena información. Buena información == Decisiones con criterio. En mi opinion un buen interfaz contiene una buena selección de la información relevante. No entiendo como podria ser de otra manera.
Vuestros comentarios, incluso aquellos con los que podemos no estar de acuerdo — quizas sobre todo aquellos con los que no estamos de acuerdo — son parte fundamental de este blog. Gracias por emitirlos.
Jejeje, creo que no nos vamos a poner de acuerdo pero ahí voy.
El punto mío es que antes de hacer cualquier cosa o tomar cualquier decisión hay que realizar actividades que nos brinden una comprensión del negocio y solo después de eso, de comprenderlo bien, se deben empezar a realizar prototipos.
No considero adecuado empezar a comprender el negocio creando pantallazos, aunque me gustan las cosas concretos, esto ya es un poco exagerado, es perderse en los detalles antes de tener un concepto global.
Claro, el caso de LinkingPaths con Tábula es diferente, es algo que ya conocen y sobre lo que se puede empezar a trabajar sobre prototipos, pero solo por que el proceso de comprensión del negocio ya se hizo, sino, de todas formas todos en la vida hemos llenado montones de encuestas y sabemos de que se trata. Eso lo digo sin conocer mucho del producto.
Para coincidir en algo, si que puedo decir que estoy muy de acuerdo con empezar rápidamente a hacer prototipos, revisarlos con el cliente, corregirlos, revisarlos de nuevo, etc. Trabajar sobre algo concreto agiliza el desarrollo y es más útil que “programar en Word”, que es lo que se hace en las metodologías pesadas como RUP.
Un saludo y gracias por las respuestas.