Por qué no utilizar mockups digitales en el desarrollo de software?

Hace unos meses cursé un postgrado de diseño web en la Universidad Oscar Lucero de Holguín. Excelentes profesores, pero, aún con esa miopía mental congénita que no les deja ver que hay muchos softwares de código abierto que facilmente le pueden hacer competencia a sus homólogos propietarios.

Antes de empezar a «divagar», les confieso que soy más dado al código que al diseño de interfaces de usuario.

En este postgrado, lo primero que nos enseñan, como buenos diseñadores, es a hacer mockups(bosquejos) en papel o softwares para ello. Un mockup es utilizado en el desarrollo de software para mostrarle a tus usuarios como quedará el software sin necesidad de construirlo. Un mockup puede variar de varios trazos en una hoja de papel hasta complejas imágenes donde ya se utiliza la paleta de colores escogida, dimensiones, metáforas visuales, etc.

Por suerte o desgracia, cuando tocaba la parte de hacer el mockup complejo(o sea, la imagen) el profesor(nombre omitido de forma intencional) nos sugirió el Photoshop. El que escribe recibió la sugerencia con la ceja alzada y expresión de Johnny Depp en Sweeney Todd. Pero bueno, dicho profesor mencionó con cierto tono de «nosequé» al GIMP, así que al final me decidí por el GIMP, y allá fue eso…

Cuando estaba haciendo mi mockup en GIMP, me recordé de cierto artículo que leí en una ocasión sobre la ineficacia de los mockups digitales, dicho artículo decía algo como esto:

  1. No puedes interactuar con un mockup en una imagen. No es menos cierto que en papel tampoco, pero el papel no está hecho para ello. Si le llevas un mockup digital a tu cliente, el esperará que funcione(es tu cliente, no un ingeniero en sistemas). Tu cliente querrá dar click en los menús o introducir texto en los widgets habilitados para ello. Mi opinión, nunca le lleves a tu cliente algo que no funcione.
  2. Los softwares para hacer mockups, al tener un sinfín de herramientas, te disocian del objetivo central y te hacen centrarte en los detalles(los colores, la distancia entre líneas, pequeños detalles que en este momento del desarrollo son completamente inútiles). Debemos comenzar por la idea central y dejar los detalles para etapas posteriores.
  3. Las fuentes. Como hacemos para cambiar las fuentes de una imagen? Pues nada, tragar en seco y decir como «se verá» en el futuro. Con un mockup en papel, pues nos saltamos esta parte y salimos airosos del trance.
  4. Producción vs Productividad. Al hacer un mockup en papel nos aseguramos de ser productivos. Un mockup digital es un producto para observarlo, no para usarlo.
  5. Los mockups digitales son una total pérdida de tiempo. Explico: te sientas y pasas 2-3 días haciendo un mockup digital en GIMP, por ejemplo, y luego que? Al final tus diseñadores tendrán que pasar 2-3 días programando las interfaces. En cambio, te pasas 2-3 minutos haciendo un mockup en papel… álgebra de bodega.
  6. Un mockup digital nos corta el desarrollo colaborativo. A mí me es placentero ver como mis amistades «garabateen» en mis diseños.
  7. Un mockup digital requiere de un sinfín de herramientas: herramienta de texto, de imagen, paleta de colores… Que requiere un mockup en papel? Pues nada, papel y lápiz.

No necesariamente los mockups digitales son malos, solo si se quiere ser pragmático y aprovechar el tiempo, pues el papel o una simple pizarra nos resuelve el problema.

Idea original: www.37signals.com

¿Te resultó interesante? Compártelo ...

Ozkar

Publicado por Ozkar

http://codeshard.github.io/ » Forma parte de GUTL desde el 6 diciembre, 2011. Soy uno ahí, no seas como yo...

Este artículo tiene 22 comentarios

  1. Muy bueno tu articulo tienes mucha razon en ello, cuanto tiempo te llevaria hacer un «mockup» en gimp o photoshop, si lo puedes hacer en papel y con un lapiz nada mas.
    Muy buen articulo de veras.

  2. Articulitos revoltosos desacreditando las prácticas serias y empresariales… ¿Y luego qué? Vas a decir que el Rational Rose y los UML son basura? Esto me recuerda Code Ninja. En Taro Adun!

    • Estaba pensando en hacer algo que desacreditara a Rational, pero creo que me ganaría más de un enemigo. Y de UML, pues no tengo aún nada en contra, jeje.
      Lok’thar Ogar!

  3. Hola tenemos bastante experiencia haciendo Mockups y aunque no hemos encontrado herramientas libres (de hecho trabajamos en una hace más de un año, sin resultados aún, hecha en Qt) si tenemos a mano unas cuantas que son nativas para GNU/Linux y donde los mockups digitales funcionan, ayudando a que el usuario se sienta bien dando clicks y creyendo que ya casi está hecha. Deja ver si publico algo al respecto.

    Felicitaciones por introducir el tema, algo, en mi criterio, indispensable para hacer buenos software. Porque he visto proyectos fracasar por no discutir con el cliente (sin un vistazo, cómo?), también he visto retirarse al líder o al visionario ¿y quién lo sigue?. Ahh!!! Todo con un simple Mockup.

    • Abel que hay como te va, ozkar me enseño lo que están haciendo con la bd del shakespeare, han puesto la versión actualizada en algún ftp?

      Sld.

    • Gracias abelito. De los softwares para mockups esta evolous-pencil, no se para los deb-based, pero en el repo de Fedora que amablemente me copiara dhunter viene una versión. Está hecho utilizando xulrunner, así que es bastante pesadito.

      • OT:Ozcar hablando de Fedora, no se si Maikel te ha comentado que tenemos en mente carte por alla en cualquier momento para buscar los repos de Fedora que aqui en Stgo es imposible encontrarlos, por supuesto que te avisaremos con tiempo, ?Ya lo tienes completo? Saludos desde Santiago

        • @bosito, creo que te habia dicho que posiblemente los repos de Fedora se descarguen completo en estos dias en el Nodo Provincial. O ya estoy senil o me parece que fue la última cosa que te comenté. No sé, tengo miles de cosas en estos dias en la cabeza y se me enreda el cerebro, pero sacando unas cuantas, en cuanto a distancia, según mis cálculos nos sale mas barato y rápido caminar unas cuadras hasta el Palacio de Comp. de Stgo. que ir a Holguín (repito, eso es según mis cálculos). A Holguín voy si @Ozkar me invita a comer, jejejeje. Saludos

  4. Muy buen artículo Ozkar, al final me ha echo ver que lo simple siempre es mejor …… sobre lo que dice dhunter ¿porque no traen mas articulos de CodeNinja hacia acá? En Taro Adun! 😉

    • Bueno este artículo tiene la doctrina de codeninja pero es original de ozkar no es copiado, lamentablemente no se si tenga algún backup del blog.

    • CodeNinja no ha muerto, al final quedamos varios geeks regados por la Isla, con el Zen de Python grabado en fuego en nuestro cerebro. Vendrán más artículos. Estoy cocinando uno que se llamará «El lado oscuro de los NoSQL: Luke I am your Father».

        • Con las tecnicas adecuadas para picar un ¿cake? ¿o era un tatianoff?, como me rei con el videito ese en CodeNinja

          • Si esos fuimos xigurat filmando, el whipper animando y yo el de la katana realizando el corte. 😉

            No era un tatianoff, estaba bastante malo, luego de eso nadie quizo comerlo entero y hubo que dejarlo silenciosamente en la acera. todo un ninja move…

            PD: un tatianoff es un cake de chocolate que vendían en la uci.

  5. pues para mockup todabia no he encontrado una herramienta mas apropiada que un lapiz y un papel, excelente articulo…….

    • Tengo un video de pycon santa clara donde el diseñador líder de django explica las ventajas de hacer sketching a mano, dice que si un sketch tarda más de 2 minutos tiene demasiado detalle, da buenas ideas.

Los comentarios están cerrados.