Rinosaurio.net

Reflexiones y apuntes de un estudiante autodidacta de diseño de interacción

Publicado en julio 2, 2016 en la categoría Diseño, Diseño de Interacción y con las etiquetas ,

Últimamente tengo una enfermiza obsesión por consultar guías de diseño de sistemas operativos para TV. En ellos encuentro otras necesidades que no están tan presentes en las interacciones para desktop o móvil. Y eso precisamente es lo que despierta ese interés en mi.

Una de las cosas que convierten el televisor en un dispositivo distinto es la distancia que se mantiene con respecto al mismo. La necesidad de un mando a distancia para su control remoto también marca una interesante diferencia.

Las nuevas interfaces han traído nuevos controles. Más adaptados a las necesidades del momento. Algunos ejemplos de esto podrían estar en Android TV o Apple tvOS.

Se necesitaba una interacción más ligera. Más suave. Los mandos tradicionales no casan con las nuevas necesidades. La inclusión de touch pads y búsquedas por voz hacen de esto algo más sencillo.

Bravia Remote

Mando a distancia Sony Bravia con Android TV

Analizando algunas investigaciones de Google Research se conocen datos interesantes. Algunas de ellas nos llevan a pensar que el televisor se debería de mantener casi como ha estado hasta hace poco.

Pero es inevitable el cambio. La necesidad. Ya ha ocurrido otras veces. Los teclados de los teléfonos se sustituyeron por pantallas. Las ruedas de los ratones por superficies multitáctiles. Era de esperar que los pulsadores que tantos años nos han acompañado fuesen sustituidos por paneles táctiles.

Hay gente que habla de gestos. Incluso algunos fabricantes han apostado por ellos. Pero el mando parece querer seguir con nosotros. Por lo menos mientras exista una interfaz como la que conocemos ahora.

Los diseñadores de interacción tenemos un amplio campo en el que trabajar aquí. Tanto a nivel de diseño de interfaz, como de control de la misma, pero en general de la experiencia.

Se sabe que los televisores son dispositivos compartidos. No obstante, es difícil que un televisor sepa quien está delante suya en un determinado momento. Aunque parece que esto se quiere cambiar. Una solución podría ser un lector de huellas dactilares en el propio mando. Parece que algunas compañías ya están pensado en ello. Y no es mala idea.

La relación del usuario con programas en vivo es importante. Ya existen formas de analizar la participación de televidentes con respecto a determinados shows. Pero ¿qué hay de facilitar su implicación con los mismos? Las segundas pantallas son algo muy utilizado actualmente. De nuevo aportan nuevos retos. Nuevas interacciones.

Somos afortunados de tener todo esto delante. Aunque a veces solo pensemos en web, o en aplicaciones para móvil, hay mucho más.

Algunas lecturas y enlaces relacionados:

Guías de diseño de algunas sistemas operativos para TV:

tvOS
Tizen
WebOs
Android TV
Firefox TV
Opera TV
Ubuntu TV

Informe de Nielsen Norman Group referente a la dificultad en el acceso a contenidos en TV.

 

4 Comments

Publicado en marzo 6, 2016 en la categoría Diseño de Interacción, Herramientas, Prototipos, Reflexión y con las

firstkodak

Soy fan de los programas de prototipado. Me encanta poder imaginar cosas que no existen, y buscar soluciones e interacciones probando a unir unas cosas con otras.

Pero me he dado cuenta de que el auténtico prototipo es el que vive en su entorno. El que se prueba en la tecnología en la que será utilizado. Y “se pelea” con distintos sistemas operativos, pantallas y resoluciones.

A veces diseñar una interacción puede resultar sencillo en un programa de este tipo. El problema es que la cosa no se queda solo ahí. Lo sencillo sería darle ese prototipo al desarrollador y que lo convirtiese en real y funcional.

Pero ahí surgen los problemas. Incompatibilidades. Cosas que por causas externas no funcionan. Cosas que surgen en el proceso de desarrollo que a veces obligan a alterar ese prototipo. A cambiarlo.

Y esto nos lleva a pensar en algo: ¿No sería mejor crear ese prototipo directamente? Es decir, ¿montarlo junto al desarrollador con la tecnología que será implementado, y ver lo que surge, y hacia donde te lleva? ¿Analizar los posibles problemas según los vas encontrando?

En mi opinión este es el camino. Creo que existen más posibilidades de descubrir posibles problemas. Probar en distintos dispositivos, con distintos materiales, distintos contextos.

Indiscutiblemente es necesario diseñar. Pensar en ello como un paso previo. Siempre. Pero la funcionalidad lo es todo. Y el material, en este caso el dispositivo, junto al software hoy en día varía enormemente y a veces los errores se detectan tarde, cuando todo está ya montado. Y cuando hablamos de software, lo que termina de probar los prototipos son los datos reales.

Que nadie me malinterprete. Creo que los programas de prototipado tipo Axure, Pixate, Principle, Flinto, y un sinfín de ellos son más que necesarios para avanzar, descubrir, probar, mostrar funcionamientos, acercar a las personas a una idea. Pero un prototipo, un prototipo es algo más allá. Es la esencia del producto, en su habitat, con todos sus posibles problemas, virtudes y carencias.

11 Comments

Publicado en febrero 26, 2016 en la categoría Diseño de Interacción, Herramientas, Reflexión y con las etiquetas ,

Medir emociones ayuda.

Usar técnicas como la actividad electrodérmica, la electroencefalografía, o el EyeTracking puede conducir a determinados investigadores a obtener resultados decisivos para el desarrollo de productos.

Me interesan muchísimo este tipo de técnicas, ya que pienso que a veces es necesario ir más allá. Existen muchos modos de observar al usuario, y todos son beneficiosos. Pero a veces me he preguntado si este tipo de técnicas también son utilizadas para mejorar la experiencia de personas con problemas de salud.

Buscando un poco sobre esto encontré algunas cosas.

EyeWriter. Una herramienta de bajo coste, que permite que personas que no pueden moverse, puedan dibujar o escribir simplemente moviendo sus ojos. Este video me dejó alucinado. Creo que es algo que todo el mundo debería de ver. Y un ejemplo de cómo la tecnología puede ayudarnos en casos difíciles. Algo antiguo pero siempre impactante:

Cardiocam es un proyecto diseñado para monitorizar parámetros fisiológicos remotamente. Es capaz de monitorizar ritmo cardíaco o frecuencia respiratoria remotamente. Todo a través de una webcam. Aún estoy alucinando con que esto sea posible.

La combinación de tinta conductiva y hardware de código abierto crean un instrumento musical de expresión que funciona con aire y contacto. Human Instruments son los responsables de crear instrumentos musicales para que personas con discapacidad puedan producir música.

Mindwalker. Un sistema para ayudar a personas con parálisis a moverse de nuevo usando su mente a través de la electroencefalografía y electromiografía.

En definitiva. Existen multitud de opciones ahí fuera. Sólo hay que saber interpretarlas. Y darles el uso apropiado según la situación lo requiera.

Y tú, ¿qué opinas?

Publicado en diciembre 13, 2015 en la categoría Diseño de Interacción, Herramientas, Prototipos y con las etiquetas ,

Hace un tiempo descubrí Pixate. Era una nueva herramienta de prototipado, enfocada a dispositivos móviles. La aplicación pintaba bastante bien, pero yo andaba inmerso en el uso de Origami, y también tonteando con RelativeWave Form, así que no terminé de animarme a probarla.

Hace poco necesitábamos probar una serie de desarrollos de menú móvil en el trabajo. Origami está muy bien para desarrollar interacciones, pero a veces si la cosa es extensa puede crearte auténticos quebraderos de cabeza.

Curiosamente estuve buscando alguna aplicación para esta tarea. Y me encontré de nuevo con Pixate, con la sorpresa adicional de que había sido comprada por Google. Y encima era gratis. Así que no tardé en descargarla y dedicarle un par de días.

Os cuento mis impresiones:

De primeras me encontré con una interfaz bastante simplificada y bien organizada. El lateral izquierdo permite añadir assets y capas con las que trabajar. Además de incorporar acciones y animaciones.

Screen Shot 2015-12-13 at 22.18.18

El funcionamiento es sencillo. Aplicas animaciones a las interacciones. Que a su vez son aplicadas a las capas o a los assets. Para simplificar; si quisiéramos que por ejemplo, al pulsar un botón se ejecutase una acción, digamos, un cambio de pantalla, primero tendríamos que asignar la interacción al botón que se pulsará para ejecutar la misma.

pixate 2

En este caso arrastraríamos Tap, hacia el botón. Y de esta forma crearíamos un interacción. Pero ahora necesitamos añadir la acción que desempeña la misma. Para eso tenemos que saber qué queremos hacer. Hay varias animaciones disponibles y lo bueno es que son combinables.

PIXATE animations

La parte derecha también tiene cosas interesantes. En ella están los parámetros de nuestra animación. Y dónde podemos combinar esas opciones. Incluso existe la posibilidad de crear condiciones para que se apliquen.

Pixate Parametros

Las posibilidades son increíbles. Pero lo mejor es su respuesta en móvil. se conecta a la perfección a través de una App que puedes descargar en tu dispositivo. También dispone de un simulador, (iOSSimulator) de Xcode. Pero al fin y al cabo lo que más se necesita en este tipo de casos es poder usar y probar los prototipos en el dispositivo. Cualquier cambio de aprecia a la perfección y no tarda nada en cargarse de nuevo. Olvidaba decir que permite grabar la interacción y compartirla por mensaje o correo.

Hay un montón de opciones, como por ejemplo acciones, (scripts) programables por el usuario, y cosas que seguramente se me estarán pasando. Lo mejor probarlo y descubrir por uno mismo.

En definitiva. No me quería extender. No suelo hacerlo, pero he de decir que Pixate para mí, se va a convertir en una herramienta muy versátil y utilizada para prototipado móvil y diseño de interacciones.

Espero que si la usáis, la disfrutéis tanto como yo.

7 Comments

Publicado en diciembre 10, 2015 en la categoría Apuntes, Diseño, Diseño de Interacción, Reflexión y con las etiquetas , ,

Cuando hablamos de producto digital podemos referirnos a multitud de cosas. Una app, una web corporativa, un software especifico para desempeñar alguna función, un portal de contenido, un panel de control, etc…

Dentro de todos estos productos, es fácil darse cuenta de que existen dos diferencias muy grandes; Los que son dinámicos y los que no lo son. Es decir, diseñar algo en lo que el usuario introduzca contenido, es muy distinto a diseñar un producto estático, en el que el resultado final cumple con creces con el diseño y el contenido inicial.

En mi corta experiencia he tenido la ocasión de poder diseñar algunas pantallas que consumen datos dinámicos. Algo completamente imprevisible. Da igual que pienses que tienes un límite de caracteres, que cuentes con un valor medio de los mismos dictado por la analítica, que tengas en cuenta multitud de ejemplos. La persona que los rellena, tarde o temprano hará algo para que tu diseño no luzca como esperabas.

Por eso a veces, cuando veo un diseño de un dashboard a la última, de esos que se ven por ejemplo en Dribbble, pienso en lo lejos que están de ser un diseño funcional y válido. Porque todos esos párrafos tan perfectamente alineados, con unas palabras justificadas en un lugar tan preciso, no aguantarían un contenido real. Un contenido en distintos lenguajes. Un contenido incremental. Un contenido vivo.

A veces cuando veo un diseño con Lorem Ipsum, creo que se aleja por completo de lo que entiendo por diseño de interacción. Y se acerca mucho al diseño visual. (Ojo, algo que también admiro y aprecio), pero que considero cosas distintas. Los datos reales son feos. Es así. Cuando tu piensas que un párrafo en tu bonito diseño tendrá tres líneas, seguro que en la realidad tendrá una. O cinco. No hay termino medio.

Existe un post muy interesante que leí hace tiempo. Complementa bastante lo que yo escribo en estas líneas. En mi caso solo pretendía escupir la esencia. Dejando al lector pensar en lo que ello conlleva.

Más sustancia, pronto.

Y tú, ¿qué opinas?

Publicado en noviembre 11, 2015 en la categoría Diseño, Reflexión y con las etiquetas , , ,

Después de leer este artículo escrito por Code and Theory, en el que hablan de su manera de entender el diseño adaptativo, llegué a la conclusión de que aún estamos rozando las posibilidades en este campo, y que lo que conocemos como “Responsive Web Design” va mucho más allá del diseño para distintas resoluciones de pantalla.

Es curioso, pero en su artículo, ponen en juego cosas como el contexto, la hora y el usuario, además del contenido, y el tipo de dispositivo. Cosa que me parece más que interesante, teniendo en cuenta que son factores que pueden afectar muchísimo la experiencia.

Eso me llevó a buscar más información sobre el tema. Y encontré este post donde también se hace alusión a la posibilidad de entregar contenido al usuario, y que él mismo pueda administrarlo y visualizarlo según sus intereses y necesidades.

Existen maneras de afrontar el diseño adaptativo, y una de ellas la tiene Specless. Una empresa que ha encontrado la forma de convertir un sencillo anuncio a las dimensiones de cualquier pantalla que se precie, y entregarlo automáticamente listo para su publicación. Este video tiene la prueba:

Y hablando de maneras de afrontarlo, los sensores tendrán mucho que decir en esto. Un ejemplo, tamaño de texto variable según la distancia de tus ojos a la pantalla.

Me parece increíble hasta podremos llegar con esto. El tiempo dirá, pero quizás es hora de ir pensando no solo en la variedad de dispositivos, sino en la variedad de situaciones, de necesidades, y de contextos, y cómo el diseño multidispositivo será realmente adaptable al uso de cada persona, según sus preferencias o estado en un momento determinado.

Más pronto.

Y tú, ¿qué opinas?

Publicado en septiembre 2, 2015 en la categoría Diseño, Diseño de Interacción, Prototipos y con las etiquetas , ,

Soy un gran fan de los buscadores. Me encanta encontrar las cosas sin tener que buscar demasiado. De hecho, utilizo Spotlight para abrir la mayoría de las aplicaciones y archivos que uso tanto en mi ordenador como en mi teléfono móvil.

Pienso que a veces perdemos demasiado tiempo buscando entre aplicaciones y carpetas, y que el uso del buscador es imprescindible.

Dando vueltas a esto, me preguntaba como mejoraría un buscador si estuviera más orientado a acciones propias de un sistema operativo. Es decir, que la búsqueda devolviese resultados tal y como lo hace actualmente, pero que también devolviese acciones. De tal manera que al buscar por ejemplo un nombre tuvieras todas las acciones disponibles relativas a ese nombre (llamar, mail, mensaje, buscar en internet, etc…) o al buscar una aplicación también tuvieras las acciones relativas a la misma…

Sé que es un poco locura. Pero detallaré los pasos que utilizo actualmente en realizar una acción tan común como enviar un mail a una persona desde mi teléfono móvil:

1. Abro aplicación de correo.
2. Hago click en escribir nuevo mensaje.
3. Comienzo a escribir la dirección de la persona.
4. Si la persona está en contactos, la selecciono.
5. Comienzo a escribir asunto y cuerpo del mensaje.

También existe la opción de buscar y enviar desde el contacto:

1. Abro Spotlight.
2. Introduzco el nombre de la persona.
3. Accedo al contacto.
4. Busco la opción de enviar mensaje.
5. Comienzo a escribir asunto y cuerpo del mensaje.

Si tuviera un buscador accesible basado en un resultado por acciones, los pasos serían los siguientes:

1. Escribo el nombre.
2. Hago click en enviar mensaje a esa persona.
3. Comienzo a escribir asunto y cuerpo del mensaje.

Hice unos dibujos rápidos, pensando en como funcionaría esto:

Buscador por acciones

Prácticamente el Sistema Operativo podría estar basado en un sencillo buscador. O por lo menos tendría una presencia muy destacada.

 

Y también hice un prototipo con Sketch y Origami:

El prototipo llevado a cabo. La búsqueda devuelve acciones.

El prototipo llevado a cabo. La búsqueda devuelve acciones.

 

Supongo que es cuestión de darle una vuelta, pero me parece un concepto interesante. Yo por lo menos creo que le encontraría bastante utilidad. ¿Y tú?

2 Comments

Publicado en agosto 19, 2015 en la categoría Diseño y con las etiquetas , ,

Find-your-phone-with-Android-Wear

Una de las cosas que más me llamaron la atención cuando leí los principios de diseño de Android Wear, fue la distinción que hacen con respecto al dispositivo:

“Designing apps for wearable devices powered by Android Wear is substantially different than designing for phones or tablets: different strengths and weaknesses, different use cases, different ergonomics.”

Me encantó. Porque me parece cierto. La interacción con un reloj nunca podrá ser igual a la interacción con un dispositivo como un teléfono móvil. De hecho, el enfoque de Google es el más parecido al uso de un reloj tal y como lo conocemos hasta ahora; Miras la hora, y apenas un segundo es suficiente para llevar a cabo la acción.

El uso del reloj con lo que ellos denominan “Cards in the stream” cumple precisamente con eso. Usas tú reloj para consultar algo, que debería de estar asociado, bien a una acción, o bien a una notificación. Poco más. Pero muy útil.

Lo curioso, y lo que me parece una experiencia diferente, es que aún teniendo tú teléfono en el bolsillo, el wearable debería de conservar la funcionalidad del reloj, pero en un contexto más de hoy en día. Tal y como dice Google:

“Android Wear devices provide just the right information at just the right time, allowing users to be more connected to both the virtual world and the real world. Great Android Wear experiences are:”

El usuario normalmente pulsa un icono para abrir una aplicación. En el caso de Android Wear, las aplicaciones con conscientes del contexto del usuario; tiempo, localización, actividad física, etc… La aplicación usa esta información para insertar estas “cards in the stream” cuando la situación lo requiera.

Un reloj de toda la vida está diseñado para consultar la hora en un segundo. Mientras menos tiempo emplees en realizar o consultar, mejor. Así debería de ser. Y eso se aproxima cada vez más a la concepción de tecnología transparente de la que hemos hablado aquí más veces.

Android Wear es como un asistente personal. Te conoce y sabe tus preferencias. Las aplicaciones te deberían de interrumpir solo cuando sea estrictamente necesario. Gestual, simple y rápido.

En definitiva. Hay mucho donde escarbar aquí. Es un paso más a la concepción del Wearable, que quizás antes no llegaba a ver. Hoy visto desde este modo, creo fervientemente en sus futuros usos de un modo inteligente y transparente.

Tal y como hemos venido usando nuestros relojes hasta ahora. Pero con una vuelta de tuerca entre lo virtual y lo real.

Y tú, ¿qué opinas?

Publicado en julio 13, 2015 en la categoría Apuntes, Reflexión y con las

Antes de tener mi actual trabajo pasé un par de años como Especialista en un Apple Store. Las circunstancias me llevaron a trabajar allí, y bueno, tengo que reconocer que no era lo mío. No obstante si me preguntan si me sirvió de algo para mi actual labor como diseñador de interacción, digo que por supuesto.

En esos dos años y medio que pasé allí tuve la oportunidad de conocer todo tipo de usuarios. Inexpertos, avanzados, recién iniciados, pequeños y adelantados, enfadados y nerviosos, contentos, interesados, despreocupados, enganchados, escépticos… en definitiva, todo un rango de edades y estados, datos demográficos e intereses dispares. Algo así como estudiar Analytics, pero en el día a día y aplicado al comportamiento humano con respecto a la tecnología.

Lo que vengo a decir con esto es que a veces, tenemos lo que buscamos delante de nuestros ojos. Usuarios. Personas que usan dispositivos día a día y nos enseñan esa relación entre ellos y los dispositivos, productos o interfaces que nosotros diseñamos.

No hace falta irse muy lejos para ver cómo las personas usan sus dispositivos móviles, o cómo un camarero introduce datos en una pantalla táctil de un restaurante, o cómo los médicos utilizan dispositivos en hospitales, cómo usamos los cajeros, o las máquinas de billetes de metro, los parquímetros, las cajas del supermercado, y un largo etc.

Todo esto está a nuestro alcance día a día. Millones de usuarios de diferentes tipos, edades, e intereses delante de nuestros ojos.

Solo hay que fijarse. Y quedarse con lo bueno.

Y tú, ¿qué opinas?

Publicado en julio 5, 2015 en la categoría Diseño de Interacción y con las etiquetas ,

Hace poco me llamó la atención la forma que tiene Slack de mostrar al usuario lo que está ocurriendo en todo momento.

Desde informar con un favicon distinto al usual acerca de un problema de conexión, hasta mostrarte acciones que están ocurriendo en segundo plano, o su inteligente sistema de notificaciones.

slack messaging action

Eso me hizo pensar que cualquier producto digital que lo requiera tiene que cumplir con estas tres premisas:

· Notificar en la medida que el usuario lo requiera.
· Mostrar acciones que ocurren en primer y segundo plano.
· Informar de procesos relevantes.

En definitiva las tres mantienen al usuario informado, pero no de la misma manera, ni en el mismo contexto.

Atrás quedan los tiempos en los que las notificaciones no servían de mucho.

Ahora, partiendo de unas buenas practicas, pueden ahorrar tiempo y mejorar la experiencia.

Interactive Notifications

La experiencia es completamente distinta cuando las acciones se pueden llevar a cabo sin abandonar tu estado actual.

Las notificaciones interactivas son un claro ejemplo de esto. Permiten llevar a cabo una acción sin abandonar lo que estabas haciendo.

Por otro lado tenemos las acciones. Un botón pulsado, una persona escribiendo en un chat, una pestaña del navegador reproduciendo un audio, un mensaje enviado…

ios Messagin system

Una persona escribe durante una conversación. Una forma de ayudar al usuario a mantener la misma.

Todas éstas acciones están ocurriendo. Algunas forman parte del comportamiento del usuario, otras le afectan en alguna medida. Todas comparten la función de informar.

Un ejemplo claro de acciones que ocurren en asegundo plano es el que ofrece el Dock de Mac OS X, que te mantiene informado de cuando una aplicación está abierta, o cuando requiere alguna atención por tu parte.

El Dock de Mac OS X informa de las aplicaciones abiertas. También hace moverse de arriba hacia abajo la que requiere atención por parte del usuario.

El Dock de Mac OS X informa de las aplicaciones abiertas. También hace moverse de arriba hacia abajo la que requiere atención por parte del usuario.

Los procesos nos informan de lo que está ocurriendo en segundo plano. Algo que requiere un tiempo de espera. Procesos que ocurren en segundo plano pero que también nos afectan. Una búsqueda de disponibilidad en un hotel, una compra de entradas online, una carga de un determinado contenido dinámico.

Proceso de búsqueda de un vuelo. Aplicable a cualquier carga o búsqueda de tipo dinámico.

Proceso de búsqueda de un vuelo. Aplicable a cualquier carga o búsqueda de tipo dinámico.

Todo esto son maneras de comunicar. Dependiendo del tipo de producto que estés haciendo las usarás en mayor o menor medida. Pero una cosa está bien clara, sería un error no tenerlas en cuenta.

Y tú, ¿qué opinas?

Página siguiente »