Eventos y conferencias

Parece que la primavera trae consigo un periodo intenso de alergias y de concentración de eventos, meetups y conferencias profesionales. Desde hace cinco semanas tres de ellas han ocupado gran parte de mi tiempo, me gustaría compartir lo que he aprendido como organizadora, asistente y colaboradora.

Women Techmakers

El Women Techmakers tuvo lugar en Málaga el 1 de abril, en el Rayo Verde. Esta iniciativa de Google organizada por los grupos de desarrollo locales GDG se celebra todos los años con motivo del día de la mujer. Ésta es la segunda edición en la que Yes We Tech participa en la organización.

Lo mejor

  • 50/50 de participación y gran apoyo de la comunidad
  • Conocer nuevas mujeres que hacen tecnología en Málaga
  • Ponencias de excelencia que merecen aún más visibilidad, más tiempo y recursos
  • Colaboración entre comunidades tecnológicas locales

Lo peor

  • El formato irregular de las charlas hace difícil mantener el ritmo
  • El Rayo Verde no sirve para hacer un evento tan largo (ya que no permite el almuerzo dentro de sus instalaciones)
  • Algunas personas aún menosprecian el valor del evento y de tener una audiencia y ponentes profesionales

UX Spain

UX Spain es el encuentro de profesionales de la Experiencia de Usuario más importante de España. En esta edición reunión a unos 500 participantes y se quedaron en la lista de espera casi tantos como los que pudimos asistir. El UX Spain de 2017 se celebró el 12 y 13 de Mayo en Gijón.

Lo mejor

  • El encuentro, la gente, las ponencias… todo de 10 como siempre
  • Descubrir a alguien que no sabías ni que existía haciendo cosas alucinantes
  • La premisa de la organización de que debe haber paridad entre los ponentes
  • Saber con qué se están peleando el resto del país en temas de UX, dejando a un lado el hype

Lo peor

  • Las ciudad de Gijón tiene una malísima combinación de viaje
  • El centro de Gijón no estaba demasiado cerca del Palacio de Congresos
  • El derroche de testosterona de algún ponente demasiado encantado de conocerse

J On The Beach

J On The Beach es el evento tecnológico por excelencia en Málaga y se centra en temas de Big Data, IoT, DevOps, JVM, programación funcional y visualización de datos. Tuvo lugar en La Térmica el pasado 17-19 de Mayo. Yes We Tech formó parte del comité organizativo y celebramos un meetup durante las conferencias.

Lo mejor

  • Estar cerca de la gente que cuida su carrera profesional, que cree en Málaga como ciudad de innovación, que aporta y quiere aprender
  • Los ponentes y las ponencias de un nivel estratosférico
  • Una de las mejores organizaciones que he visto nunca desde la perspectiva de la experiencia del asistente: impecable
  • Es un encuentro internacional celebrado en una ciudad sin complejos
  • Conocer nuevamente a mujeres de otros países con ganas de dar caña a una red Yes We Tech global
  • El proyecto a modo hackathon que presentamos para Yes We Tech y el apoyo de nuestro core :_)

Lo peor

  • Los fallos técnicos que desmerecen a los ponentes al retrasar o desfavorecer sus charlas, fueron pocos pero los hubo
  • Los comentarios o salidas de tono de algún tío que aún no se da cuenta que a nadie le interesa sus complejos machirulos
  • La falta de coordinación para poder descansar y disfrutar del evento desde la organización, acabamos todos exhaustos física y mentalmente.
  • Las realidades de algunas empresas malagueñas que aún tratan a sus empleados y empleadas de forma desconfiada

Conclusiones

En las últimas semanas he dedicado mucho tiempo personal en formar parte de la comunidad profesional, siempre es enriquecedor por quién llegas a conocer, por cómo puedes ayudar a otros y otras a relacionarse, a aprender y a hacer networking. Sin embargo, hace falta una pausa para reflexionar y volver a lo básico, a las raíces, y sobre todo para no agotarse.

En temas de igualdad hay luces y sombras y mucho que hacer. En esta especie de burbuja de los eventos donde tus oportunidades laborales y profesionales parecen depender tan claramente de a quién conozcas y por dónde te dejes caer es más importante que nunca que las mujeres estemos aquí. También me hace reflexionar si no estaremos contribuyendo a una desigual forma de acceder a puestos de trabajo.

Por otra parte, como co-organizadora creo que si el equipo no comparte 100% unos valores básicos sobre la identidad y el saber-hacer del evento, se corre riesgo de implosión. Me gustaría que el próximo evento que co-organice empiece precisamente por poner en común estas ideas.

Por ahora volveré a nuestros modestos meetups a los que estáis todas y todos invitados y en los que espero poder reforzar el core de Yes We Tech para que la comunidad se sienta más cerca que nunca.

Las preguntas correctas

A la Real Academia de Ingeniería,

Como mujer, ingeniera y feminista debo reconocer el enorme valor e importancia que considero tiene su recientemente impulsado proyecto ‘Mujer e Ingeniería’ que promocionan a través de este vídeo.

Para mí es emocionante ver este tipo de proyectos ya que suponen admitir la situación de anormalidad que sufrimos en nuestra profesión.

Y es justo tras verlo con detenimiento donde me encuentro con un sabor agridulce por todo lo que esperaría que se hubiera dicho y, sin embargo, se omite o, peor aún, por cómo se presenta el problema. 

Espero que los siguientes comentarios sean entendidos por su carácter constructivo, pues entiendo lo difícil que es impulsar cualquier actividad feminista y lo inoportuno que ‘una de las nuestras’ muestre una actitud demasiado crítica.

Si bien mis opiniones son solamente mías, no representan a ningún colectivo y las lanzo con toda la esperanza de que sean bien recibidas.

Este proyecto nace para que más chicas estudien ingeniería

Es complicado hablar de números aunque en el síntoma todos coincidimos. A pesar de lo que dice la UNESCO, a mí me interesan algunos datos de los que nunca se habla:

  • ¿Cuántas ingenieras han abandonado su carrera?
  • ¿Cuántas estudiantes han dejado de ir a clase?

Seguramente piensen que haciendo así estas preguntas doy por hecho de que son muchas ¿verdad? Pues de esto va el vídeo-presentación, de hacer las preguntas correctas y evitar las respuestas simples y baratas para que nadie dé nada por sentado.


“¿Es cierto que a las chicas no les gustan las matemáticas ni la ingeniería?”

Me gustaría pensar que las chicas (o más bien las niñas) saben si quiera lo que es la ingeniería, es más, si lo sabe algún niño en general. En cualquier caso lo que me duele de ésta como primera pregunta es suponer que la primera razón por la que somos pocas es “porque a las chicas no nos gusta”. Sí, lo sé, se trata precisamente de romper con ese mito, mito que sólo se cuestiona la parte de la población que no entiende que ‘las chicas’ no dejamos de elegir la rama tecnológica porque no nos gusten o no se nos den bien las mates, sino porque no sabemos lo que es una ingeniería, porque no tenemos referentes y no entendemos su potencial.

Ante la obviedad de que a las chicas sí les gustan las matemáticas y sí podría gustarles de igual forma la ingeniería si se explicara o se practicara en las escuelas (que por cierto poco se practica aún), las respuestas son igualmente condescendientes: ¡pues claro que se nos dan bien! Es más, los comentarios dan pie a otra tesis peligrosa: chicas, si queremos podemos, pero ¿cuándo hemos dejado de querer? ¿cuándo he dejado de dedicarme a algo porque requiriera esfuerzo? ¿es que las chicas abandonamos? ¿nos desanimamos? ¿o más bien nos desaniman? 

A continuación, el remate viene en forma de “les gusta y además son muy buenas en lo suyo” ¡menos mal! porque si no lo fuéramos tampoco tendríamos derecho a dedicarnos a ello. Incluso la mediocridad está reservada a los hombres.

“Son tan difíciles las carreras de ingeniería?”

Por si no han notado ya mi tono de indignación, la siguiente pregunta retrata otro de los mitos más usados por las mentes simples que creen que las mujeres sólo podríamos querer estudiar cosas sencillas, porque, claro, no hay mujeres médicas, filólogas o fisioterapeutas ¿cierto?

Acá las respuestas más descorazonadoras, todas ellas por supuesto dirigidas a las mujeres para animarnos a esforzarnos ante la dificultad. 

Me pregunto si la carrera es difícil o es difícil la profesión. Me pregunto también si los obstáculos sólo nos los ponemos nosotras o son invisibles, y preguntándome esto último me doy cuenta de que según este vídeo sí, las barreras, chicas, son cosa nuestra.

“¿Los hombres lo tienen más fácil para trabajar como ingenieros?”

Aquí por fin escuchamos a la primera mujer que se atreve a medio insinuar que quizá, puede, tal vez, el hecho de que la ingeniería es un mundo de hombres (”presencia masculina”) donde no somos extraordinarias por estar fuera del “estándar” sino que somos las que estamos fuera de lugar (”nos salíamos de la media”), las que no pertenecemos a este mundo.

Al hilo de esta respuesta, la siguiente entrevistada habla por fin de las “barreras inconscientes” y me lleno de esperanza porque se refiera sobre cómo puede ser que influyan en que quienes podrían contratar, financiar, confíar, apoyar o colaborar con iniciativas lideradas por mujeres dejándose llevar por su prejuicios. Pero no, el mensaje que por supuesto respeto porque es su opinión es que la forma de luchar contra las barreras inconscientes, chica, es hacerte visible. Porque somos invisibles. La barrera es una imaginación tuya que aunque sea inconsciente mía y me deje influir por mis creencias sexistas tú debes solucionar haciéndote visible.

Es muy triste que en menos de tres minutos de vídeo de un proyecto tan necesario como este liderado nada más y nada menos que por la Real Academia de la Ingeniería hayamos abarcado ya tantos tópicos y mensajes confusos para concluir justificando por qué “son necesarios proyectos como Mujer e Ingeniería”.

“¿Qué les dirías a las chicas para que se hagan ingenieras?”

Yo lo primero que no les diría, o no les llamaría, es ‘chicas’ toda su vida. Serás una niña con inquietudes y luego serás una mujer ingeniera. Serás lo que quieras pero no dejes que nadie te robe la curiosidad ni el interés. 

Segundo les explicaría lo que es la Ingeniería, lo que es la tecnología. Les hablaría no sólo del aspecto profesional sino del social, del político, del creativo. Suscribiría el comentario de Ana Alonso cien por cien.

Lo que no haría sería negarles la realidad porque sí: sí, hay barreras y no, no te las pones tú, hay barreras culturales y ésas nos las ponen los demás, no las hemos elegido. Hay machismo, lo siento si no querías escucharlo pero lo hay, de ese tipo de machismo normalizado, de ese del que se sufre por el simple hecho de ser minoría.

Sin embargo tú, que ya sabes lo que es esforzarte ante materias difíciles como las mates, que ya sabes que si quieres puedes, debes usar parte de tu energía para superarlas y, sobre todo, para no dejar que te impidan seguir con tu camino.

“Merece la pena”

Por supuesto que merece la pena. Siento si no hemos dejado claro en la presentación de este vídeo que iba dirigido a convencerte qué de bueno tiene ser Ingeniera. Siento si hemos dedicado cuatro minutos a justificar el proyecto suavizando al máximo nuestras reivindicaciones, pero ya nos has visto. Somos mujeres y hacemos tecnología, porque se puede. Cierto, porque se puede y porque nos empeñamos a pesar de todo.


Vuelvo a insistir, este proyecto es el proyecto de todas: conseguir explicar y convencer a las niñas de hoy por qué la ingeniería es la formación ideal para poder participar en el maravilloso mundo de la creación y desarrollo de tecnología. No es el único pero es el más aconsejable para una preparación profesional. 

Por alguna razón, para la que habrá que hacer la pregunta correcta, el número de mujeres que estudian ingeniería ha descendido notablemente y esto nos preocupa. 

Tú, que aún eres una niña, ésto no lo vives como un problema. Yo, que tengo más de treinta años, que tuve mucha suerte cuando tuve tu edad, siento que las mujeres más jóvenes están perdiendo una oportunidad única en la historia. Por eso quiero convencerte. Porque ya sé que puedes ser lo que quieras por difícil que sea, pero sería realmente emocionante verte como Ingeniera. Como agente del cambio y progreso tecnológico.

Building your own tools with existing software

I’m sure you’re sick to death to hear whether designers should learn to code or not.

To me, coding skills have let me create my own designer toolkit by reusing and extending current software tools. Have you ever imagine how cool would be to become your own user while developing a solution?

At the moment there are thousands of open-source apps available for anyone to improve them. Some of them do just basic things like To-Do lists apps and others are a bit more sophisticated like Chats.

I’m not even talking about libraries and that crazy need of knowing the whole universe of packages and extensions of a programming framework. I’m talking about already built-in solutions with a purpose, with an API, and with an easy-to-consume documentation.

This is an experiment that I love to make from time to time: just pick an existing tool, see the code, imagine a different purpose with the current interaction model, a different way of using the visual grammar and customise it to see how the UI paradigm will work for a different goal.

If you include yourself as the target user, as a designer no one better than you what you want and need so, you can go ahead and create something fantastic to make your life easier, funnier or more productive.

Designer, you have the power of imagination, the good habits of a well-stablished UX process, and a strong creativity and ability to conceptualise things that most people can hardly envision, you just need to know the keys to play with the code and cross the red line.

It is to me the funniest way to learn.

Soon I’ll share my latest experiment: buidling my own UX testing framework 😉

Optimismo sin reservas

No he triunfado. No importa. Recuerdo que cuando estudiaba, cuando entrenaba, cuando me preparaba para afrontar retos, lo que me hacía sentir capaz no era el miedo a no dar la talla, ni el ser consciente de las dificultades del proceso, sino el desafío del esfuerzo.

Soy una convencida de que las mejores cosas que te da la vida requieren esfuerzo. Por eso, cuando pienso en qué cosas desalientan a la gente para superarse a si mismos, para atreverse con una u otra carrera profesional o proyecto, para arriesgar el corazón en una batida no está el miedo al fracaso, sino la pasión misma por vivirlo.

No, quienes actuáis con condescendencia no tenéis razón, solamente erráis en lo más básico: nadie espera alimentar su motivación con las frustraciones de otro.

Dejad de dar consejos y empezad a aceptar que por los demás lo más sensato es construir colectivamente. O quedaos solos. 

Adiós a la competencia del incompetente, así como a la irresponsabilidad del responsable. A partir de ahora me limito a no dar consejos, a hacer lo que tiene sentido, a ofrecer un rato de conversación sobre cómo podemos dejar de preocuparnos por triunfar y empezar a sentirnos orgullosos.

Pasen y vean, empezamos desde abajo.

From UX to Product Design

You may have read the article published by Eric Eriksson explaining the meaning of Product Design from the perspective of other ux-related roles such as Interaction & UX Desginers, Animation Designers, User Researches, Data Analysts, Prototypers (I love this one) and Business Strategists.

He states that

Product Design is the whole process

I remember that when we started talking about UX, UX was also the whole process considering that a UX designer was meant to drive and be reponsible of it. What a huge ambition right?

Our mistake (and our reality) was thinking that the UX individual was alone in this process.

Now that we have assumed that there are a lot of specialiaties, including the UX Specialists, we need to go back to think who was the person that ensured that the whole process is driving the good solution. So for that leading or visionary role we need to talk about Product Designers.

For sure UX is not alone in the dark, but an important gear to create and deliver digital products. This means that Product Design intersects with Business & Marketing, with Quality Assurance & Sales, and still keep their feet in the ground during the implementation of the product to facilitate delivery.

While I write this I remember one of the most highlighted ideas during the last UX Spain conference, where senior UX experts reached the conclusion that in order to do an ejoyable, useful and usable product for users, UX Designers had to become Product Owners (PO).

Product Owner is a popoluar term in agile methodologies and is the person who’s meant to speak the customer voice as well as validate that the delivery is aligned with the requirements.

Problems that I see with the terminology of Product Owner is that, firstly, not in all scenarios Users are the same as Customers and even if they are, not all our customers behaves in the same way. So considering that one person is capable of represent Users requirements without practicing any User Research technique is hard to believe. Secondly, the ‘validation’ state can be done only if your requirements, definition of done and acceptance criteria are clearly stated before the development starts, and in order to do that you’d still need exploratory design, co-creation or any other analytical artefact that puts users needs and expectations in the center.

So yes, I share the conclusion of considering that UX has to become a PO, but then we need to re-define what Product Owner really means.

And here comes the third of my thoughts regarding the transition of User Experience experts toward Product-something: Strategy is all.

Process are good, keep people working efficiently through all the stages. Ownership if shared is even better, since everybody feels that everyone is an equal part of the end result and we all success or fail together.

But what really kills the old-fashion way of delivering software is Strategy. And the premise of many (if not all) UX speacilists is the assumption that a product designed to meet user goals and create a positive experience with it has to be part of any strategy to make it adopted, and so be sold.

Yes, we can sell with our sales guys, we can look smart because our technology is smart and let our customers think that they’re doing an smart purchase, but the long-term goal of creating and enduring relation between our users and our products has to be based on the path of the User Experience. There’s no better promise of quality that a good quality product delivered on time. Deliverying functionalities without considering how users will interact with them (macro interaction) is as risky as ignoring that the small details and developed components are not the high priority focus of the delivery (micro interactions).

At least this is what I think while I aspire to become a good Product Designer some day.

Sgd. A UX specialist apprentice.

If this make any sense it’s in my head, if you (dis)agree, you can blame on the comments of this post.

Always solving the same problem: data model vs mental model


Information design is one of the most interesting fields to me that relates with the User Experience. How users perceive and understand the information based on what we show them and how they interact with it, it is like trying to create a language that goes beyond the interface and the standards. It is challenging and, sometimes, uncertain.

However the other day I had a déja vu while one of my mates was sharing a research made on an data analysis use case. Suddenly I felt I’ve been solving the same problem of information design over the last three years.

We talked about how raw data becomes information, and how there should be another data that represents the meaning of that information, and how past events may affect to current indicators or not. We talked about the visualization of multiple charts were the only way to understand some concepts, and how users should decide the events and configuration to provide real meaning beyond the data values.

I’m not going to enter into specifics on that use case, but the problem that reminds me the same kind of question was the one that I worked for years: the Electronic Patient Record (EPR).

In an EPR there are some information which indicates current health status: vital signs. This can tell you if you’re alive, getting better or getting worse. It is also a clue to start investigating what made you feel bad.

That’s one level of information based on data collected directly from a person. Of course you can collect more data like a blood test or a urine test or similar.

Another level of information is just the history of every visit to your doctor. All of them with symptoms, diagnosis, and treatments. Those events could be related between them by episodes (let’s say a flu, a pregnancy, a surgery…) and, in a different level, related by the diagnosis of an illness (let’s say cancer, diabetes, etc.).

The problem you have is that you need to navigate information from different layers based on different levels of the data abstraction. And you want to find correlations, make differential analysis and causations at any level, because you don’t really know what’s the cause of the problem.

What I thought it was similar is that when we model the problem, we have to provide meaning to the data abstraction and that requires an understanding of the user mental model (In my case how doctors research on data).

Another leg of this problem is how users can interact with the data to find how it is related. We cannot solve everything with a static picture of the data.

Last, but not least, we needed to represent very clearly what is the data in a relevant present (24hours, 7 days,…) and what belongs to the history, and how history is explored and contrasted with present data.

 

Somehow I felt the problem was always the same, and the only thing that makes it different is the kind of person who typically interacts and uses the data. So the solution should start to understand his/her mental model and define the model of the data meaning based on them, instead of the defining the data model of the system that is meant to represent it.

Prueba de diseño en Cinefilica

Así de chulo me está quedando el nuevo diseño de Cinefílica, pero tengo mis dudas sobre si publicarlo. El layout responsivo funciona pero me está dando muchos quebraderos de cabeza para encajar ciertas cosas.

Quitarme de un plumazo la navegación es un decisión muy radical. Si bien podría confiar en la página de inicio como distribuidor de contenido y potenciar el buscador (y sus resultados) para darle al usuario todo lo que necesita explorar, me quito la posibilidad de extender en algún momento el sitio web a algo más que el catálogo.

Otra cosa que hago desaparecer es el pie, creo que debería incluirlo aunque muchísimo más discreto que lo que hay ahora. Eso sí, los géneros debería hacerlos más visibles en la página de inicio, a fin de cuentas, están recibiendo visitas.

No sé si acabaré publicando estos cambios, en cualquier caso aquí los comparto.

Semana #1 – Intro a la Ciencia de Datos

La Ciencia de Datos comienza, casi como cualquier ciencia, motivada por un deseo de curiosidad. En este caso preguntas que hacerle a los datos. 

Es posible que los datos no contengan la respuesta, pero el deseo de preguntar junto con el entendimiento de la naturaleza de los mismos nos puede ayudar a obtener respuestas y descubrimientos.

Los tipos de análisis de datos que se pueden hacer podrían clasificarse como

  • Descriptivo
  • Exploratorio
  • Inferencial
  • Predictivo
  • Casual
  • Mecanístico

Algo básico para cualquier persona que comience en este área es entender que hay que evitar caer en los siguientes errores

  1. Correlación no implica causalidad
  2. Sobreajuste: interpretar un análisis exploratorio como predictivo
  3. Análisis descriptivo que no se puede inferir
  4. Interpretar un análisis exploratorio como inferencial

Por otra parte hemos aprendido a preparar nuestro entorno de trabajo con R usando R-Studio y dejar nuestras cuentas de Github listas para empezar a trabajar.

Este primer curso está planificado en cuatro semanas pero la verdad es que ha resultado bastante fácil avanzar ya que queda todo en el ámbito introductorio. A la espera de que me evalúen el primer ejercicio me he apuntado al segundo curso de la especialización: R Programming (seguro que éste sí requiere de más tiempo).

Lecturas recomendas para el comienzo del curso

Curso especializado de Data Science en Coursera

Hoy comienzo el primero de los cursos dentro del Programa Especializado de Data Science que ofrece la Universidad Jhons Hopkins a través de la plataforma de formación Coursera.

Es un programa para principiantes que puede dar buena base sobre los conceptos, disciplinas y tecnologías que se usan cuando se quiere hacer de los datos información.

Considero fundamental entender y dominar las habilidades relacionadas con la manipulación de datos para poder modelar sistemas de información y, posteriormente, diseñar componentes visuales que representen conceptos inteligibles, interpretables e interactivos.

Así que voy a intentar con este programa ordenar todas las ideas con las que en el último año vengo trabajando como parte del equipo de Valo.

Usando Axure para definir interacciones con contenido dinámico

No soy la persona más fan del mundo de Axure, me parece complicado y anticuado. Axure es una herramienta de prototipado, una de las más populares y una de las potentes. Pero sigue estando muy orientada a interfaces web sin embargo

  • No resuelve bien el diseño de web responsivo
  • Las animaciones son programáticas (no hay timeline de animaciones)
  • Las animaciones y los estados de los paneles dinámicos no se llevan bien
  • Hay demasiadas malas prácticas que pueden llevarte a hacer insostenible el mantenimiento de un proyecto

En cualquier caso reconozco que es una de las más completas y se pueden cubrir la mayor parte de los prototipos que se quieren hacer sin necesidad de saber programar y sin necesidad de abrir otras herramientas de diseño.

Además dotar de vida a un prototipo estático es una gran oportunidad para empezar a sentir cómo va a ser el uso real del producto. La pregunta es sobre quién queremos que caiga el esfuerzo de la creación de dicho prototipo ¿sobre el diseñador o el desarrollador? Es más ¿es un prototipo que se use sólo para decidir o también para testear?

El debate sobre qué nivel de fidelidad y de interacción debe tener un prototipo la dejo para otro momento, ahora me quiero centrar en descubrir alguna de las cosas interesantes que se pueden hacer con Axure que, si bien no resultan obvias a primera vista, no son tan complejas después de todo (eso sí, de aquí a programar hay un paso pequeñito).

Gestión de contenido dinámico

Algo que da muchísimo valor a un prototipo es el uso de datos y contenido real. En muchos casos, si el diseño de la información es bueno, cualquier otro elemento de la interfaz pasa desapercibido.

La forma de usar datos dinámicos con Axure es mediante el componente repeater.

Un repeater no es más que un contenedor de elementos que se pueden repetir con valores diferentes y con misma apariencia. Es decir, es como una tabla pero sin tener datos fijos.

A un repeater se le pueden añadir filas, eliminar y modificar como quieras. Además se le pueden añadir y eliminar filtros y un criterio de ordenación e incluso paginarlos.

Lo interesante de los repeater es que se pueden usar para definir el modelo de datos de la aplicación donde se pueden gestionar elementos de navegación dinámicos (como un sistema de pestañas), listas de elementos gestionados por el usuario (por ejemplo una lista de películas favoritas) o simplemente un historial de acciones (que pueden usarse para deshacer a un estado previo).

Variables globales

Otra gran utilidad de Axure son las variables globales. De nuevo un elemento muy práctico para quienes necesitan orquestar la lógica del prototipo de forma que todo esté coordinado.

Las variables globales se pueden instanciar en cualquier momento disparado por cualquier evento de cualquier componente y ayudan a mantener el estado de la interfaz.

Pero ¿por qué necesitaríamos estados? Seguramente en el mundo web donde casi 90% de lo que se hace es navegación lineal vuestros prototipos a base de hiperenlaces sean suficientes. Sin embargo, cuando quieres prototipar una interfaz de usuario donde el usuario puede interactuar con muchos componentes a través de ratón o teclado, existan ciertos elementos cuyo comportamiento va a depender de la combinación de dichas interacciones, es decir, del estado en el que esté la interfaz en cada momento. Para conocer dicho estado, usar variables globales resulta tremendamente práctico.