El diseño móvil como parte de la experiencia: la importancia del contexto.

El diseño móvil como parte de la experiencia: la importancia del contexto.

Google Design como recurso de aprendizaje

Si hay un recurso web que considero imprescindible tanto si deseas desarrollar algo para móviles como si sólo quieres aprender algo útil sobre diseño o programación es el portal de la plataforma Android.

Ya en el pasado enlacé alguna de sus buenas prácticas dirigidas a desarrolladores, pero no hay duda de que en este portal hay muchos más recursos útiles. Y es que, en general, las guías de estilo de las diferentes plataformas nos enseñan mucho más que directivas, sino los principios fundamentales de diseño en los que se basan los nuevos paradigmas de interacción y experiencia de usuario desde la capa visual hasta la construcción de la arquitectura.

En este caso Android, en sus secciones de Design, Development y Distribute, estructura unos contenidos valiosísimos para apreciar los detalles y los conceptos básicos con los que trabajar cuando te enfrentas a un desarrollo móvil (o casi de cualquier tipo si sabes abstraerte bien).

Si aún no has navegado por su web donde fundamentan las bases del lenguaje visual Material Design, te recomiendo que empieces por ahí ya que éste puede aplicarse a cualquier plataforma y detalla con infinidad de ejemplos múltiples principios de diseño.

Igualmente importante es la sección de estilo y patrones, la sección de training de desarrollo y los contenidos esenciales sobre la distribución de apps.

A veces me parece necesario no acumular demasiada cantidad de recursos, webs, libros, etc. para poder focalizarte en una sola cosa, sencilla, directa y bien estructurada sobre todo cuando el objetivo es aprender. La documentación de Android en este caso es un ‘gustazo’ no como la de iOS que en mi opinión sólo usa la verborrea para destacar de forma inconsistente y desestructurada algunos de sus iluminados principios de diseño. Pero quién soy yo para criticar al gran Ive o a su equipo…

Creo que mi apuesta queda bastante clara, más aún viendo cómo de bien le sientan los años a Android y lo bien que está madurando. Prueba de ello es la reciente salida de Android Studio 1.0, que pasó de la beta recientemente y se presenta como un entorno de desarrollo completo el cual espero trastear en profundidad en breve.

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.

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.

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.