More UX-specialised department rises every day within organizations

Cada vez surgen más departamentos específicos de experiencia de usuario dentro de las empresas

Yusef Hassan at PuroMarketing

Taking advantage of that right and proper stament, I’d like to add a personal thought.

After four years, I’ve seen new UX departments rising and closing, new UX specialists being hired and fired according to business strategy and budgets. Nothing new so far for software companies which are trying to adapt the resources to the demand.

However, I still see that there are big challenges this companies have to face in short and long term, as follows:

  • Unifying processes and adapting existing User-centred design methodologies to software development processes and viceversa
  • Coordinating ux-people across the company
  • Identifying the ux performance indicators
  • Involving different roles within ux practices

In that sense, the challenge is not only to create a UX department, but a UX culture where the usability has to be a responsability of everbody.

Nevertheless, the panorama is more than optimistic, since companies relies more and more in UX roles to drive change and improving their products and services.

 

Design Studio – más que una herramienta

La técnica de Design Studio ha sido introducida por primera vez en el contexto de desarrollo ágil como una herramienta de colaboración para ideación de soluciones mediante sketching. Con el paso del tiempo, he tenido la ocasión de poner esta técnica en práctica en múltiples ocasiones con equipos de diferente naturaleza: programadores y diseñadores, analistas y expertos de dominio, sólo diseñadores, etc.

Durante cada una de las sesiones, he ido experimentando cómo los participantes no sólo aportaban sus ideas, criticaban o recogían nuevo conocimiento sobre el problema, sino también, cómo se destapaban las ambigüedades, incertidumbres y las conjeturas erróneas acerca de qué es lo que necesitan los usuarios y de si las propuestas iban en algún momento encaminadas a resolverlas.

La Design Studio es, más que una herramienta de colaboración, una técnica necesaria en una metodología de Diseño Centrado en el Usuario. En este artículo me gustaría recoger algunas de las claves para llevarla a la práctica y sacarle partido. Si quieres saber más sobre cómo planificarla te recomiendo el artículo The Design of a Design Studio y el siguiente recurso.

Diseño dirigido por necesidades de usuario

Como es conocido, en la metodología de Diseño Centrado en el Usuario se parte de la base de que los usuarios que van a utilizar la solución saben mejor que nadie cuáles son sus necesidades.

Independientemente de la capacidad de cada uno de saber expresar verbalmente lo que necesitan o no, las entrevistas a usuarios bien ejecutadas son una fuente directa y rica de información que debe dirigir el resto del proceso de diseño. Obviamente, no es la única fuente, la observación de campo, la comparación de productos, el análisis estadístico de comportamiento previo, o el user testing también proporcionan mucho conocimiento sobre cómo se comportan nuestros usuarios.

Las entrevistas requieren de un ejercicio de análisis posterior donde buscar cómo se expresan los objetivos, las expectativas, las restricciones, el contexto, las preocupaciones, las ideas y los problemas a los que se enfrentan los usuarios. De todos esos aspectos, se busca identificar también patrones de comportamiento para armar lo que se conoce como modelo mental del usuario.

Esta es una información de partida útil para alimentar la sesión de diseño durante una Design Studio.

Personas y escenarios

Las personas y los escenarios suelen ser los grandes olvidados a pesar de que toda solución debe partir de un problema bien formulado como una historia real que ocurre en un contexto real con un usuario real. O digamos, al menos, realista.  Sin embargo, en el momento de idear soluciones y, sobre todo, de defenderlas, tendemos a olvidar para quién se estaba solucionando. La persona y el escenario deben también dirigir la historia que se cuenta, puesto que no estamos en una fase de diseño final, detallado, o de alta fidelidad, sino, todo lo contrario, estamos conceptualizando posibles soluciones y planteando nuevas hipótesis a explorar.

Crítica y valoración de propuestas

Existen múltiples formas de valorar las propuestas de los participantes, aunque lo que es una constante es que, después de una larga jornada de diseño y creatividad las “mentes pensantes” estén poco motivadas a recibir críticas. Puntuar según criterios puede parecer a priori una forma objetiva de valorar el conjunto de las ideas pero se corre el riesgo de descartar demasiado pronto ideas que son geniales por el mero hecho de no haber convencido a la audiencia. Por otra parte, expresar críticas sin el propósito de buscar debilidades para mejorarlas suele minar la actitud de los participantes.

La mejor opción en mi opinión es buscar la validación de las propuestas según los supuestos que se han analizado anteriormente ¿satisface o no los requerimientos que se habían asumido? Posteriormente se puede hacer un planteamiento de en qué punto está la propuesta, es decir, qué haría falta para llevarla a cabo más que asociarle una nota o una ‘prioridad’. Las prioridades son de hecho la forma más macabra de acabar con las grandes ideas después de una Design Studio. Lo ideal, en este caso, es ser capaz de identificar qué supuestos siguen siendo válidos, qué aspectos hay que volver a investigar con o sin usuarios, y cuál es el beneficio que de ejecutar esa idea podría obtenerse al respecto.

Como decía, la técnica de Design Studio es más que una simple herramienta de colaboración e ideación, resulta convertirse en una representación de una parte del proceso de Diseño Centrado en el Usuario y de la formas de cooperación y estrategias de producto que va a diseñarse. Más allá de las complejidades de entrevistar usuarios, sketchear y criticar, lo que se persigue con esta técnica es mostrar las fortalezas y flaquezas de las que se parte.

Con un poco de suerte, puede convertirse en una práctica que cambie la forma de desarrollar productos digitales, no por lo ágil, sino por su orientación a desarrollar soluciones que apasionen a sus usuarios.

UX in Scrum

I’m not an expert in Scrum methodology, but after working and collaborating for 3 years as part of a Scrum team, here are some ways we’ve a got to introduce User Experience practices into agile development:

  • Getting User Stories talk about real people and needs (Personas)
  • Getting Epics talk about user scenarios
  • Product backlog grooming on Design Studio’s sessions
  • One sprint ahead for High-fidelity designs (better option maybe would be a Design spike)
  • Usability expert consultancy during the sprint
  • Cognitive walkthrough during review sessions

Beyond Design Events

Last 30th of May took place “Beyond Tiles” an event in Madrid drived by Arturo Toledo. As it promised

WIndows 8 and Windows Phone are more than just tiles 

Find below some of the most interesting links which where referenced during the 1-day session.

Books

Icons

Mobile development

Inspiration

Personally, I’ve found it one of the best design event I’ve attended ever. First of all because it talked about design history not only about the last 4 weeks technology history, which provide a real rationale to the current design approach of Microsoft and beyond. Secondly, it didn’t mention one hundred times the word Bauhaus and I love colours, but he really provided lots of examples where Swiss design beats any trend with a solid style and aesthetic. 

Although I still don’t agree that airport signals is a good argument to be presented as a  Modern UI inspiration I entirely agree with the vision of simplicity and content presentation.

Finally, we also had the opportunity to talk with Arturo Toledio and Brady Voss who also presented a short but promising session. 

Agile UX Research Practice in Android

In the Android UX team, it is critical to get user feedback frequently and consistently so that we are able to iterate and develop the best-in-class designs for our users. We will discuss how the team applied “”Pulse Studies”“ (iterative research sessions) in order to put new ideas, designs, and concepts in front of users on a regular basis; it requires minimal advance planning, it can have an immediate product impact, and it can meet urgent needs. We will illustrate how we accomplished this collaborative process by presenting rich examples and case studies. We will also demonstrate usability study role playing in order to give you tips and tricks on how to adopt this process for anyone who is interested in getting user feedback in a quick and impactful way.

¿Cómo desarrollarías para hacer aplicaciones que a la gente le encante usar?

Conocer las prácticas fundamentales del Diseño Centrado en el Usuario (DCU), como desarrollador, diseñador, o manager, es el primer paso para conseguir invertir los esfuerzos del desarrollo en crear aplicaciones que de verdad supongan un valor para las personas que van a usarla.

Esas personas, los usuarios, transformarán nuestra visión convirtiéndose en aliados para reducir incertidumbre y como fuente de inspiración, más allá de la experiencia y la personalidad con la que nosotros afrontemos las decisiones.

El DCU no es una metodología exclusiva de los diseñadores, sino que supone una estrategia común para conseguir resultados que realmente responden a necesidades de usuario. Con ella, podremos acercarnos siempre a soluciones más usables que mantendrán una buena experiencia a lo largo del tiempo de vida del producto o servicio.

El libro User-Centred Design el autor Travis Lowdermilk ofrece una interesante guía para desarrolladores, desarrolladores como él, para la construcción de aplicaciones user-friendly.

Llama la atención tanto el enfoque como los ejemplos que expone, que hacen muy fácil entender conceptos básicos usando situaciones a las que muchos nos hemos enfrentado. Y lo hace fácil porque realmente no es complicado, otra cosa es que como el autor dice

Creativity requires us to be courageous and vulnerable. Although trying new things may be risky and embarrassing, it’s the key to discovering new insights.

No podemos negar que las expectativas de los usuarios son cada vez más altas, que tienen más referencias que nunca sobre el valor del diseño y que la industria clásica de desarrollo de software no puede continuar anclada en procesos y metodologías que ignoren las necesidades y requerimientos de los usuarios.

Existen otras referencias interesantes que podrían serte útiles tras echar un vistazo a este libro:

Performance vs Clinical Risk

The complexity of creating usable solutions in healthcare 

The productivity that a user can get with a tool depends, among other things, on the usability of the interface used to work. In the context of healthcare applications, the interface design solutions can supose in certain situations a number of hazards that result in clinical risk. A productive solution is incompatible with clinical risk free solution? In an effort to provide a broad view of the problems, in this article we offer solutions addressing the most common design patterns used to increase productivity in user interfaces.

For the analysis, we propose two specific usage modes: data entry (interaction with the system) and data output (representation of information and data management interactions) in a health system.

Data Entry (garbage-in)

Help to complete the information

  • Problem: Help may be decontextualized
  • Solution: The help that is offered to the user should not contextualize only normal activity but the content and the information required.

Autocomplete

  • Problem:The autocomplete action may end up in the selection of an unwanted value
  • Solution: Actions should allow the end user to overwrite the value and warn you that you are entering a value outside the catalog.

Validation and error feedback

  • Problem: The errors reported are partial
  • Solution: Inform the user about the possible existence of more errors and the need for revision

Defaults

  • Problem: Default values ​​may be based on faulty assumptions
  • Solution: Report existing defaults and even offer the possibility of removing.

Shortcuts

  • Problem: Loss of visual feedback on what you are doing.
  • Solution: Inform the user with a message of the action to be executed.

Commands (actions, undo, massive actions)

  • Problem: The command may cause a failure in the integrity of the data.
  • Solution: Run command to complete mock confirmation by the user and inform the local view of the result.

Data Output (garbage-out)

Indexes and data summaries

  • Problem: The data are not updated
  • Solution: Inform the user of the last update of the data and provide the ability to update it in context.

Search

  • Problem: The search is hidding results.
  • Solution: Reporting results of existence visible and hidden results either paging issues as matching with the search.

Notifications

  • Problem: Notifications are not prioritized.
  • Solution: Offer a prioritization system and allow customization of alert priority one by one or by type.

Alerts

  • Problem: It was considered an alert something that is not.
  • Solution: Associate clinical alerts to static domains consistently identifiable
  • Problem: An unintuituve icon has been associated to an alert
  • Solution: Tagged alerts with short terms  and / or group them under predefined domains

The healthcare scenario

We should note that in the health context, the tasks that a user must perform that require a computer system can account for up to 30% of their time and therefore there is a clear need to improve the efficiency and productivity in their daily use.

At the same time it is important to consider that during the working day there are many and frequent changes of tasks, activities and contexts, for instance, a doctor in the emergency room in a 10’ frame has been triaging two patients, be consulted by the nursing team 3 times on matters of different nature, it has been lifted from his seat 6 times for different tests of material, information, etc.

Therefore, although the task itself requires a high concentration effort, attention span is reduced by the high number of interruptions. In this context, the user controls what he does but is subjected to a high load of stress and distractions in almost any of its activities. A medical error could pose a risk to the health of their patients.

From the most simplified view of a computer system as a mere representation of the information model, the most basic interface is build up with forms to fill available data and views for display them. Even with this formula, the application would not be free of clinical risks. Any solution applicable for the simplest interface is not incompatible with richer and more usable interfaces. For this we consider that not only is not incompatible to have solutions which can enhance productivity and usability, but it is also necessary.

References

Checkbox tri-estado

El pasado 6 de Mayo, el equipo de BalsamiqNext incluyó, por fin, el estado ‘indeterminado’ para el control de Checkbox.

El uso de este estado es muy marginal, pero sigue siendo sin embargo necesario cuando queremos mostrar checkboxes anidados, en concreto cuando el elemento padre contiene alguno de sus elementos hijos en estado ‘seleccionado’ y al menos uno en estado ‘normal’.

Sin embargo, esta representación tri-estado es considerada en ocasiones demasiado confusa para los usuarios, probablemente porque un estado indeterminado es de por sí ambiguo y poco específico ¿cuántos y qué elementos están realmente seleccionados?

Otra problemática es que este estado a veces no es activado por interacción directa del usuario sobre el control, sino por el estado de los elementos hijos, con lo cual, la representación visual puede despistar.

Incluso cuando es el usuario quién lo acciona de forma directa, continúa siendo difícil entender qué significa un estado intermedio entre seleccionado y no seleccionado.

No obstante, su uso sigue viéndose en ciertas aplicaciones, por ejemplo cuando debemos hacer selección múltiple sobre muchos elementos que además vienen agrupados para su mayor legibilidad y cuando la selección/deselección del elemento padre se usa para seleccionar/deseleccionar todos los elementos hijos de una vez.

En cualquier caso, no se trata de evitarlo sin más sino de reducir su uso sólo para las ocasiones en las que tenga de verdad sentido y a partir de ahora además podrás sketchearlo con la futura release de Balsamiq Mockups.

 

Si quieres saber más sobre el buen uso del Checkbox una buena referencia es la guía de Microsoft y el Nielsen’s Alertbox dedicado a este control.