EL PROTOTIPADO EN PAPEL COMO HERRAMIENTA DE COMUNICACIÓN ENTRE DISEÑADORES Y PROGRAMADORES DE

SOFTWARE

Rebollar Rubio, R.; Lidón López, I.; Sierra Marcén, A.

Area: Proyectos de Ingeniería

Dpto.: Ingeniería de Diseño y Fabricación.

Centro Politécnico Superior de la Universidad de Zaragoza

C/ María de Luna 3, 50018 Zaragoza

Tfn.: + 34 976 761910 Fax: + 34 976 761861 E-mail: rebollar@unizar.es

___________________________________________________________________________

RESUMEN

Habitualmente se ha utilizado el prototipado en papel para realizar valoraciones de usabilidad del interfaz de los programas de software en las primeras fases del proceso de diseño. En esta ponencia se presenta un nuevo uso del prototipado en papel dentro del proceso de desarrollo de este tipo de productos.

En numerosas ocasiones, los programadores del software no participan en el diseño del mismo, limitándose a cumplir las especificaciones realizadas por los diseñadores del programa informático.

Esto, unido a las propias limitaciones que tienen las especificaciones, hace que existan numerosos problemas de comunicación entre ambos, dando como resultado productos que no se ajustan a los que los diseñadores esperaban de ellos, o alargando innecesariamente el proceso de desarrollo debido a los continuos rediseños.

En esta ponencia se presenta una experiencia realizada en una empresa del sector, en la que se ha implantado el prototipado en papel dentro de su proceso de desarrollo de producto como herramienta que permite una mejor comunicación entre los diseñadores del software y los programadores del mismo, sirviendo de complemento a las especificaciones de producto.

Palabras clave: Prototipado en papel, comunicación, software

ABSTRACT

The paper prototypes has been used to evaluate the usability of the software interface in the first stages of the design process. In this communication, a new use of the paper prototyping within the development process of this type of products appears.

Very often, the programmers do not participate in the design of the software, limiting themselves to fulfil the specifications made by the designers of the software programs.

1122

This, together with the own limitations that have the specifications, causes that appears numerous problems of communication between both, giving like result products that do not adjust to which the designers hoped of them, or unnecessarily extending the process of development due to the continuous redesigns.

In this communication a experience made in a company of the sector is presented, in which the paper prototypes within its process of product development has been implanted like tool that allows a better communication between the designers and the programmers of the software, serving as complement of the product specifications.

Key Words: Paper prototyping, communication, software

___________________________________________________________________________

0 INTRODUCCION

El prototipado es una herramienta ampliamente utilizada en cualquier proceso de diseño y

desarrollo de producto, gracias a la cual se puede testear el comportamiento del producto

antes de su diseño definitivo [1]. Existen diferentes tipos de prototipos dependiendo de los

objetivos que se pretendan conseguir:

• Prototipo Funcional. El objetivo es comprobar las prestaciones técnicas del producto. Se

utiliza principalmente en las últimas fases del proceso de diseño.

• Prototipo Estético. Es objetivo es visualizar cual será la apariencia final del producto. Se

puede utilizar en cualquier fase del proceso de diseño.

• Prototipado de Interfaz. El objetivo es comprobar como será la interacción del usuario

con el producto. Se utiliza principalmente en las primeras fases del proceso de diseño.

La fabricación de un prototipo siempre supone incurrir en una serie de gastos importantes, y

los cambios posteriores en el diseño suelen implicar la necesidad de fabricar uno nuevo. Para

solucionar este problema están cobrando últimamente una gran importancia, dentro de los

prototipos de interfaz, los prototipos de baja fidelidad, realizados con materiales económicos

y fácilmente construibles y modificables [2]. Se llaman de baja fidelidad, ya que no pretenden

tener todas las funcionalidades, ni siquiera en muchos casos la apariencia final del producto,

sino permitir de forma rápida y sencilla obtener realimentación de los usuarios finales sobre

algunos aspectos puntuales del diseño.

1123

Fig. 1 – Prototipos de baja fidelidad de un mando a distancia

Dentro de los anteriores podemos destacar los “prototipos de papel”, realizados en este material, en dos dimensiones y utilizados principalmente para simular interfaces de programas informáticos de diversa índole.

Fig. 2 – Prototipo en papel de un programa informático

Habitualmente se ha utilizado el prototipado en papel para realizar valoraciones de usabilidad del interfaz de los programas informáticos en las primeras fases del proceso de diseño, donde se ha mostrado siempre como una herramienta muy útil para el diseñador, ya que las modificaciones en el diseño del producto que se pueden realizar en estas fases son fáciles y baratas de solucionar[3].

Sin embargo, algunos autores [4]creen que el prototipado en papel puede también desempeñar un importante papel como herramienta que facilite la comunicación entre el diseñador y el programador.

1124

Los diseñadores y los programadores suelen pertenecer a dos mundos totalmente distintos. Tanto la formación, como los intereses y hasta el propio lenguaje suelen ser muy diferentes, por lo que aparecen diferentes barreras que dificultan la comunicación entre ambos. Es algo similar a lo que ocurre en el campo del diseño de producto tradicional, con la incomunicación que se produce entre la gente de marketing y la de diseño [5].

Esta barrera de incomunicación siempre resulta un grave problema, ya que se produce en el momento más delicado del proceso de diseño cuando se tiene que producir el salto de las necesidades del usuario a las funcionalidades del producto.

En numerosas ocasiones, los programadores del software no participan en el diseño del mismo, limitándose a cumplir las especificaciones realizadas por los diseñadores del programa informático. Esto, unido a las propias limitaciones que tienen las especificaciones, que por muy completas que sean nunca pueden comprender todos y cada uno de los aspectos a considerar en el programa, da como resultado productos que no se ajustan a los que los diseñadores esperaban de ellos, o alargando innecesariamente el proceso de desarrollo debido a los continuos rediseños.

En esta ponencia se presenta una experiencia realizada en una empresa del sector del diseño de software, en la que se ha implantado el prototipado en papel dentro de su proceso de desarrollo de producto como herramienta que permite una mejor comunicación entre los diseñadores del software y los programadores del mismo, sirviendo de complemento a las especificaciones de producto.

1 LA EXPERIENCIA

Con el fin de comprobar la bondad de los prototipos en papel como herramienta de comunicación se pretendió realizar una experiencia piloto en una empresa zaragozana, a la que llamaremos SEGURASA y dedicada entre otras cosas al diseño de sistemas de control de accesos.

SEGURASA es una empresa joven (creada en 1995) que cuenta con una plantilla de 15 trabajadores: 2 comerciales, 2 de oficina técnica, 6 programadores, 3 técnicos de hardware, 1 gerente y 1 administrativo.

1.1 El problema

SEGURASA se puso en contacto a finales del año 2004 con el Area de Proyectos del Centro Politécnico Superior de la Universidad de Zaragoza con el fin de encontrar una solución a los problemas de incomunicación existentes en su empresa entre los miembros de oficina técnica y los programadores informáticos.

Ya existía una relación anterior de colaboración entre la empresa y el Area de Proyectos y además la empresa conocía las experiencias que estaba realizando el Area en relación con el uso de prototipos de papel para el diseño y evaluación de usabilidad del interfaz del software.

El proceso de diseño habitual de una aplicación de software en la empresa SEGURASA se puede resumir en los siguientes pasos básicos:

1125

1. Los comerciales de la empresa, en contacto con las demandas y problemas de los clientes y con un buen conocimiento del mercado en general, detectan necesidades de ideas de nuevos productos.

2. Estas ideas de los comerciales, junto con las ideas propias de la empresa son analizadas en oficina técnica y gerencia, con el fin de estratégicamente decidir que nuevos productos se deben desarrollar.

3. Oficina técnica prepara una propuesta de especificaciones técnicas de las funcionalidades y características básicas que debe tener el producto.

4. Esta propuesta es pasada a los programadores que son los encargados de refinarla.

5. Una vez dado el OK por todos, los programadores empiezan a desarrollar la aplicación basándose en la especificación final.

6. Durante el proceso de programación, los componentes de oficina técnica y los programadores tienen una serie de reuniones con el fin de comprobar como va el avance de la aplicación.

7. Finalmente los informáticos son los encargados de realizar las pruebas de funcionamiento de la aplicación.

8. El producto terminado pasa de nuevo a los comerciales que se encargan de la difusión del mismo a clientes y de su presentación en diferentes eventos del sector.

Los problemas de incomunicación en la empresa se producían en los pasos 3, 4, 5 y 6.

La formación y lenguaje de oficina técnica y programadores es muy distinta, la gente de oficina técnica suele expresarse en términos de usuario y tareas a realizar, mientras que los informáticos se expresan en funciones y lenguaje técnico de programación.

Esto ha traído como consecuencia que en ocasiones se ha mantenido un error de comunicación durante meses simplemente por el hecho de la confusión en el significado de un determinado término técnico. Así, en una ocasión, oficina técnica pretendía que en una aplicación apareciera una simple tabla con una serie de datos tabulados, mientras que los programadores entendían que lo querían era un listado, exponiendo los grandes problemas que exigiría su programación.

Otra de las causas de los continua incomunicación, dando como resultado continuos rediseños inacabables, era el hecho de que no se desarrollaba inicialmente el interfaz de la aplicación y posteriormente se programa el interior de la misma. Sino que los programadores empezaban por aquellos módulos que más les interesaban desde el punto de vista informático y posteriormente cuando todos los módulos estaban desarrollados se montaba la aplicación completa y se desarrollaba el interfaz final.

Esto traía como consecuencia que las reuniones con oficina técnica no fueran especialmente productivas durante la programación de los módulos, debido a que tenían un fuerte contenido técnico que escapaba, como ya hemos referido anteriormente, a las capacidades e intereses de los miembros de oficina técnica. Solamente en las reuniones finales, cuando la aplicación estaba prácticamente finalizada y era obvio cual era la forma de funcionamiento al tener el interfaz prácticamente acabado y poder tener una visión general y completa de la aplicación, a cuando surgían las desavenencias ya que el interfaz y la forma de funcionamiento si correspondían a los intereses de oficina técnica, y en numerosas ocasiones chocaban con los de los programadores.

El problema que aparecía, es que cualquier cambio que se quisiera hacer ahora en los módulos suponía un trabajo adicional que retrasaba el lanzamiento de la aplicación al mercado y

1126

además suponía un cierto sentimiento de frustración en los programadores, que veían como parte de su trabajo debía ser rehecho.

2 METODOLOGIA UTILIZADA

Con el fin de intentar paliar en lo posible estos problemas presentados anteriormente se pensó en introducir una serie de pequeñas modificaciones en su proceso de desarrollo de producto mediante la incorporación de la técnica de prototipado en papel.

La metodología utilizada fue la siguiente:

En primer lugar se eligió en cooperación con la empresa, el proyecto de una nueva aplicación para que pudiera servir de experiencia piloto, y permitiera a la empresa comparar con facilidad los beneficios e inconvenientes de la incorporación de pequeñas modificaciones al proceso de desarrollo del producto.

El proyecto piloto se estructuró en tres fases principales:

1. Dedicada a entender perfectamente el proceso de desarrollo de la empresa, para lo cual se tuvieron contactos con gente de gerencia, oficina técnica y programadores.

2. Consistente en la realización de la experiencia piloto propiamente dicha mediante el desarrollo de una aplicación de principio a fin con el fin de que quedaran patentes las diferencias en la forma de trabajar.

3. Con el fin de obtener las conclusiones pertinentes de la realización de esta experiencia piloto.

La principal modificación que se introdujo fue la de diseñar primero el interfaz de la aplicación, mediante técnicas de prototipado en papel de dos dimensiones.

En esta actuación piloto fueron los integrantes del equipo de investigación del Area de Proyectos de la Universidad de Zaragoza los que se encargaron de ir diseñando y construyendo los prototipos.

Los prototipos se realizaban a partir del proyecto de especificación creado por oficina técnica y en una reunión semanal eran puestos en común entre oficina técnica, programadores y los constructores del prototipo. Durante la semana los programadores continuaban trabajando sobre las partes del interfaz que ya habían sido consensuadas entre todos.

Posteriormente, y cuando el prototipo final esté acabado se van a realizar pruebas con usuarios finales con el fin de buscar problemas de usabilidad en el interfaz desarrollado.

Después de la realización de esta experiencia piloto, que a fecha del envío de esta ponencia no está todavía finalizada completamente, se pretende que el rol de constructor de los prototipos de papel y la realización de pruebas con usuarios recaiga en la gente de oficina técnica.

3 RESULTADOS OBTENIDOS

1127

La experiencia no está actualmente concluida en su totalidad, pero ya se pueden extraer una serie de conclusiones sobre los resultados que se están obteniendo.

El hecho de hablar primero del interfaz de la aplicación, hace que la gente de oficina técnica y los programadores piensen en la forma de funcionar de la aplicación y obvien los problemas y lenguajes técnicos. De esta manera la primera barrera de incomunicación es derribada.

El utilizar un prototipo tangible hace que las personas hablen sobre cosas concretas y no tanto sobre expresiones abstractas. Cuando se habla sobre algo que está dibujado, aunque sea con poco grado de detalle, la barrera de llamar de forma diferente a las cosas también queda derribada.

Por otra parte ha resultado ser un elemento que permite que todos se sientan parte integrante del proceso de diseño, con lo cual la implicación con el producto es mayor.

En lo que respecta al tiempo de desarrollo, todavía no se pueden extraer conclusiones ya que no se ha terminado de desarrollar completamente la aplicación, pero parece ser que van a disminuir los tiempos dedicados a rediseño.

4 CONCLUSIONES El prototipado en papel en dos dimensiones tiene más posibilidades que las de servir para evaluar con usuarios reales los problemas de usabilidad de una aplicación en las primeras fases del proceso de diseño.

En esta ponencia se ha presentado una experiencia piloto, en la que dicha herramienta ha sido utilizada de forma satisfactoria como elemento facilitador de la comunicación entre la gente de oficina técnica encargada de redactar las especificaciones del producto y los programadores encargadas de programarlo.

Se ha demostrado como el diseño completo del interfaz del programa antes de programar una línea de código facilita que se puedan realizar fácil y rápidamente cambios en la aplicación, y que además la gente de oficina técnica no tenga que discutir con los programadores temas técnicos que se escapan en muchas ocasiones de sus capacidades y conocimientos.

Se ha comprobado como hablar de cosas concretas y tangibles hace que las barreras de la comunicación y el leguaje caigan, facilitando el entendimiento entre todos.

En resumen se puede concluir, que el prototipado en papel tiene muchas posibilidades de convertirse en un elemento complementario a la especificación técnica que facilite el traspaso de las necesidades de los usuarios a las funcionalidades de los productos.

5 REFERENCIAS

[1] Nielsen, J. “Usability Engineering”, Academic Press, 1993.

[2] Virzi, R.; Sokolov, J.; Karis, D., “Usability Problem Identification Using Both Low and High Fidelity Prototypes”, CHI´96 Proceedings, 1996.

1128

[3] Rebollar R., “Prototipado en papel en tres dimensiones. Una herramienta de participación del usuario en el proceso de diseño”, V Congreso Internacional de Ingeniería de Proyectos. Lérida 2000.

[4] Snyder C., “Paper Prototyping”, Morgan Kaufmann Publishers, 2003.

[5] Cagan J., Vogel C.M., Weingart L.R., “Understanding Perceptual Gaps in Integrated Product development Teams”, Proceedings of DECT´01, Pennsylvania 2001.

1129