Pencil

Herramienta de prototipado de código abierto multiplataforma

Si la austeridad también ha llegado a su ciudad, como el camión del tapicero, quizá guste de conocer esta interesante herramienta de prototipado de baja fidelidad totalmente gratuita y disponible para Linux, Windows y Mac.

Pencil no es nada nuevo ni bohemio ni cool, de hecho la última release es de Septiembre de 2013 y no da la impresión de que el proyecto siga vivo, pero no podemos negar que como herramienta es bastante útil si quieres empezar a trastear con el diseño de pantallas desde ya, además es gratis, es libre y el resto depende de tu imaginación (como siempre). 

Pencil Project nació en 2008 y se distribuye bajo términos de licencia GPL version 2, y es una herramienta muy sencilla que permite hacer cosas tan básicas como:

  • Dibujar diagramas
  • Sketchear GUIs basadas en componentes predefinidos
  • Relacionar documentos de un proyecto mediante enlaces de contenido
  • Exportar los documentos como imágenes o un documento HTML (aunque éste sea bastante precario)
  • Definir tus propia librería de componentes (muy útil para equipos de diseño)

Sobre éste último punto he publicado un pequeño artículor en el que explico cómo hacerlo.  Aquí os dejo el enlace por si os pica la curiosidad: Cómo crear una librería de recursos con Pencil.

Cómo crear una librería de recursos con Pencil

Si ya conocéis Pencil y os preguntáis cómo podríais definir vuestra propia librería de componentes para crear GUI en este tutorial hacemos un repaso de los pasos a seguir.

Hay dos formas de conseguir nuestra propia librería

  1. Haciéndolo bien
  2. Haciéndolo rápido

Como para hacerlo bien ya existe una buena documentación en la web de la herramienta vamos a explicar cómo puede hacerse de forma rápida (y no tan flexible) para que resulte práctico crear conceptos visuales y compartirlos con diferentes equipos.

image

Una forma fácil de empezar

Usando la librería ‘Common shapes’ podemos empezar a dibujar elementos básicos basados en formas geométricas.

  1. Una vez que tengamos todos los elementos, los seleccionamos juntos y agrupamos (CTRL+G). Ahora se comportarán como una única forma.
  2. Sobre el nuevo componente clicamos en botón derecho “Add to my collections…”.
  3. Como este es el primer componente tendremos que crear una nueva colección a la cual añadirlo. 
  4. Si ahora comprobáis en la pestaña ‘My Stuff’ veréis que ya está creada vuestra nueva colección. 

Una característica que encuentro bastante útil es la ‘Sizing policy’ que tiene cada elemento (accesible via menú contextual). Esta política permite definir el comportamiento del elemento cuando está agrupado en un componente al que se le modifica el tamaño. Gracias a esto podrás decidir si quieres que cambie o no de tamaño o se mantenga alineado a un lado o a otro.

¿Y si quiero hacerlo bien?

Qué necesitas tener

  • Un editor de texto (para ver/editar XML)
  • Un editor de SVG (las formas están definidas como vectores)
  • Un editor de bitmpas (por si necesitas meter algún icono o imagen)

Qué necesitas saber

Una estructura típica para crear una colección tiene este aspecto

... [dir] CollectionName
      |
      |___[dir] icons       #optional
      |     |
      |     |___shape1.png
      |
      |___ Definition.xml     

y en el documento Definition.xml deberás definirlo de esta forma

<Shapes xmlns="http://www.evolus.vn/Namespace/Pencil"
        xmlns:p="http://www.evolus.vn/Namespace/Pencil"
        xmlns:svg="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"

        id="your_collection_id"
        displayName="Display name of your collection"
        description="More description about this collection"
        author="Names of the authors"
        url="Optional URL to its web page">
        
        <!-- Your shapes go here -->
        
</Shapes>

Iremos añadiendo los diferentes componentes usando las etiquetas <Shape></Shape> y dentro de ellos podremos definir Propiedades (color, dimensión, etc.), Comportamientos y Acciones además de su Aspecto (mediante el SVG).

Para ver lo que estamos haciendo, puedes cargar tu colección desde Tools » Developer Tools » Load Developer Stencil Directory… seleccionando el archivo Definition.xml (usa F5 una vez cargado para refrescar).

Cuando termines, mételo todo en un archivo ZIP asegurándote que el Definition.xml está en la carpeta raíz.

No te olvides que si quieres depurar errores puedes abrir la consola de errores desde Tools » Developer Tools » Show Error Console

A partir de aquí te recomiendo que consultes el Tutorial en el que viene explicado cada detalle sobre cómo montar la colección con directivas XML.

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

Interaction Design with Indigo Studio and GifCam

Interaction Design with Indigo Studio and GifCam.

Indigo first release was free forever, although it’s not available for download any longer. I’m one of the few who still have a Lite license and can take advantage of this powerful prototyping tool built in Silverlight.

Indigo has helped me to demonstrate design, simulate behaviour and communicate specifications with the development team and also with end users.

GifCam is just a cool resource that helps me to share microinteractions implemented with a prototyping tool.

And this ‘Hello World’ example is nothing but one of the design interactions in motion I’ve been working this morning 🙂

Interfaces de usuario en el ámbito sanitario

Diseñada para la salud

Este viernes 23 de Mayo participé en el evento de UXSpain para hablar de Interfaces Usuario en el ámbito sanitario. Me ha hecho una enorme ilusión asistir a este evento un año más y en esta ocasión como ponente para introducir un tema como el de la Experiencia de Usuario en la Industria Tecnológica Sanitaria a la que llevo dedicándome casi 5 años.

Nervios a parte, intenté comunicar con algunos ejemplos cómo las interfaces de usuario en este sector pueden llegar a representan y determinar el modelo de antención sanitaria (servicios y productos incluidos).

La Sanidad es un ámbito de caracter humanitario que, sin duda, puede y debe verse beneficiado de las disciplinas del diseño, no sólo como especilidades sino como parte de sus estrategias transformadoras. Esta es la idea que me animó a compartir mi experiencia y que espero que resultara interesante a todo/as los asistentes.

Gracias a todos por vuestros amables comentarios en en Twitter y sobre todo a los que pude verles las caras e intercambiamos impresiones. No me gustaría que se perdiera el caracter de encuentro de este evento ya que es sin duda lo que más aporta a nivel personal para construir esta comunidad tan importante a nivel profesional.

Quiero agradecer también a mi compañero de vida Antonio Benítez su apoyo y ayuda, que se ha currado la mitad de las slides y sabe tanto o más que yo lo difícil que es la toma de decisiones de diseño y procesos en este sector.

¡Muchísimas gracias a todos, nos vemos en el próximo uxspain! Por supuesto, enhorabuena a la organización.

Selectores de género

littlebigdetails:

Instructables – Offers a variety of gender options when signing up for an account

/via Vonn

Interesante detalle. En el ámbito clínico este tipo de datos es punto de controversia. Por un lado hay usuarios para los que este dato al no ser clínicamente relevante desprecian su utilidad, por otra parte ciertos estándares obligan a especificarlo de acuerdo a un respeto a la identidad de género del paciente, para otros, el dato es clínicamente relevante cuando se ajusta a la realidad fisiológica del paciente.

La solución: diferenciar entre Sexo (Biológico) y Género (Identidad), puesto que tenemos que seguir educando a la ciencia y a la conciencia de que las diferencias existen porque son relevantes y que deben ser las personas (los usuarios en este caso) los que interpreten los datos y decidan qué significan para ellos.

Relacionado con la interpretación o cómputo de datos clínicos y la forma en que se muestran encontramos también la ocurrencia de riesgos clínicos.

User Feedback

image

¿Cuándo fue la última vez que hablaste con un usuario? ¿Has improvisado alguna vez una reunión para enseñarles algún concepto en el que estabas trabajado?

No siempre se tiene la oportunidad de planificar una sesión de testing formal ya sea por la falta de tiempo, de recursos, o la inaccesibilidad de los usuarios. Sin embargo, hay veces en los que ‘secuestrar’ usuarios durante un tiempo limitado resulta la única gran oportunidad de recibir de primera mano algo de ‘feedback’.

Recibir ‘feedback’ espontáneo de un concepto en  marcha o sin terminar debe hacerse teniendo en cuenta algunos detalles importantes para que éste nos aporte algo útil. Allá van unos cuantos factores que yo siempre trato de tener en cuenta.

Qué significa ‘Feedback’

‘Feedback’ en inglés significa simplemente ‘comentario’ u ‘opinión’, si es negativo es una crítica, si es positivo es un incentivo, un reconocimiento. En otros contextos puede traducirse como retroalimentación, aunque eso es un tipo de ‘feedback’ que no nos interesa, ya que de un usuario necesitamos sus ideas y su experiencia, y no saber simplemente que está ahí.

Recibir ‘feedback’ debe servirte para seguir adelante con alguna idea o echar marcha atrás. Pero siempre quien debe decidir es quien diseña y no quien opina.

Conoce a tu usuario y demuéstralo

Si estás pidiendo opinión es importante saber a quién se la pides y por qué ¿Necesitas que te ayude a cerrar un circuito? ¿A completar con contenidos que no aparecen? ¿Quieres que valide una de tus hipótesis?

En cualquiera de esas situaciones debes mostrarle cuáles son los supuestos de los que partes y éstos a su vez deberán estar basados en algo que tenga que ver con él o ella.

Si has llegado hasta esa idea es porque se supone que buscabas satisfacer las necesidades de un usuario muy parecido a él o ella.

Concreta

Ve al grano con tus preguntas, no des varias opciones, espera a que se explique y nunca le interrumpas para hacerle ver que no entendió tu pregunta. De la forma en la que se exprese puede que halles una respuesta aún más útil.

Tampoco es el momento de hacer un despliegue de conocimientos técnicos así que pregunta cosas sencillas y espera su reacción.

Siempre positivo

No des opiniones negativas de tu diseño. Más que parecer un gesto de humildad ante una solución no muy buena lo único que consigues es influir en una percepción negativa de la misma. Es preferible un comentario como ‘parece inacabado’ (algo que ya sabes y que tiene solución) a incentivar a los usuarios a pensar que ni si quiera tú estás convencido/a de ir por una buena dirección. Si los usuarios dudan, tenderán a reforzar la visión negativa en lugar de ayudarte a concluir tu idea.

Hay otro detalle que puede que sea simple sugestión pero que a mí me ha ayudado mucho siempre. Generalmente, cuando pedimos ‘feedback’ tendemos a alertar y a justificarnos dando demasiadas explicaciones sobre lo que significa ‘wireframe’ o ‘inacabado’. Es preferible introducir las ideas con dos recursos básicos: el sentido del humor y animarles a imaginar.

No es lo mismo ‘pedirles tiempo para que te ayuden’, a ‘darles la oportunidad de ver algo impresionante’.

En conclusión…

Nunca pierdas la oportunidad de hablar con un usuario, cuéntale lo que haces pensando en las personas como él o ella, demuéstrale que la solución está basada en pequeñas decisiones y que ese pequeño momento es una excelente ocasión para ambos de avanzar en la definición de tus ideas.

Cross-experience Design – una aproximación

Cuando pensamos en diseñar para múltiples plataformas generalmente atendemos al sentido común que nos dice que el diseño debe adaptarse a la plataforma, a su tecnología y sus recomendaciones específicas de diseño. Sin embargo, si pusiéramos atención al factor humano y muy a pesar de los detractores del “No se diseñan experiencias”, me resulta inevitable pensar que existe un matiz diferente si enfocamos el diseño para la experiencia en una o múltiples plataformas.

Desde un significado literal, Cross-platform se refiere a la implementación de soluciones para múltiples plataformas. Luke Wroblewski incorpora también su término Multi-device design para referirse al diseño único que funcione para varios dispositivos. Ambos términos hablan dela forma de llevarse el concepto a la tecnología de forma que ‘puedas despreocuparte’ del dispositivo o plataforma desde la que se accede a la hora de desarrollarlo.

Ahora bien, cuando se piensa en diseñar para ofrecer experiencias de usuario concretas, el dispositivo o plataforma vuelve a estar en el punto de mira condicionando el comportamiento del usuario, de hecho forman parte de su contexto de uso, por lo que no podemos ignorarlo tan fácilmente una vez encontrada la solución técnica al diseño de un producto.

Existe un tercer término: Cross-chanel UX Design que se refiere a la interconectividad de los diferentes canales que se usan cada día y a la necesidad de consistencia entre ellos. Aunque esto tampoco es nuevo y nos devuelve a la época de los estándares y las divertidas discusiones sobre, por ejemplo, el icono para ‘Guardar’ (‘Guardar’ sigue formando parte de nuestro lenguaje ¿no es así?) y su uso en los diferentes Sistemas Operativos.

Sin embargo existe una situación que me gustaría bautizar como Cross-experience Design (perdonadme si el término ya existe y lo estoy ignorando) y, como todo término nuevo, refiere a algo que ya existe.

Cross-Experience Design sería el conjunto de prácticas para alcanzar soluciones de diseño que se adapten y transformen la experiencia de uso a lo largo del tiempo por las personas que utilizan la solución.

La forma en que estas prácticas toman forman son la Inteligencia Artificial y un diseño que llega a ser consciente del contexto del usuario, como el del Diseño Emocional y, por supuesto, el Diseño de Interacción.

Ideas sencillas en aparencia como lo que esconde Google Now es un buen ejemplos de esta consciencia inteligente.

Sin embargo el carácter temporal es un factor importante en UX, ya que un diseño cross-experience requeriría de incorporar ciertas características que evolucionaran conforme evoluciona la relación con el usuario. Por ejemplo, si diseñáramos un servicio X para un usuario con una necesidad A, una vez cubierta la necesidad A (ya sea circunstancial o temporal) ese usuario puede ‘transformarse’ en otro tipo de usuario con necesidades B, C y D. Como servicio puede que nos interese (o no) que suceda esa transformación de una determinada manera.

Todas las características que la solución ofrezca al usuario para que esta transformación tenga lugar de forma que se prolongue una experiencia enriquecedora a lo largo del tiempo son las que refiero como cross-experience design.

Puede que a estas alturas haya divagado demasiado, en cualquier caso, es posible que amenace con nuevas ideas para apoyar este concepto.