08/03/2018 Categoría/s: Citas,Diseño de interacción. 0 Comentarios

Información y Big Data. Experiencia del cliente y diseño de servicios. Sociedad y machismo.

Customer centrity

El concepto de customer centrity, acuñado por el publicista Lester Wunderman en 1967, se fundamenta en el enfoque al cliente como parte esencial de la estrategia de una empresa.
Por muy poco sentido común que tengamos en muchas ocasiones, no nos debería de sorprender demasiado lo siguiente:

  • Según el Informe Customer 2020 de la consultora americana Walker, en el año 2020 la experiencia del cliente superará al precio y al producto como diferenciador clave de la marca.
  • Según el informe IBM de experiencia de compra digital, más del 75% de dos mil consumidores encuestados que encontraron un problema en el servicio al cliente o en una experiencia de compra en un sitio web de una marca, dejaron el sitio o visitaron a un competidor.
  • Según Dimensional Research, el 95% de las empresas no logran superar las expectativas de sus clientes.
  • Según la consultora McKenzie, compensar una experiencia de compra negativa lleva 12 experiencias positivas.
  • Según la encuesta Parature State del Servicio al Cliente Multicanal 2014, el 65% de los consumidores encuestados dijeron que han cortado lazos con una marca debido a una sola mala experiencia de servicio al cliente.
  • Según el Estudio Bain&Company el 80% de los CEO consideran que sus productos ofrecen una experiencia de cliente superior y solo el 8% de los clientes están de acuerdo.
  • Según diferentes estudios, el 95% de los clientes insatisfechos cuenta al resto su mala experiencia.

IOU: Customer centric

Por eso entiendo, y aplaudo esa vuelta de tuerca al concepto de customer centrity que hereda no poco de la experiencia de usuario. Sí, hablo del diseño de servicios.

Y mientras haya empresas que pierden clientes (¿quién no tiene su lista negra?) por engañarlos y maltratarlos, e intenten transmitir una imagen alejanda de la realidad que tienen sus clientes con la publicidad (¿ése anuncio es de una compañía electrica, de una de telefonía móvil, de un coche, de una ONG o de un perfume? Cuanto hipócrita buen rollo, diantres, y qué poco se parece a lo que yo percibo).

El día que descubran que dar buen servicio es innovador, va a ser la bomba.

Carmen Lanza

¿De qué sirve inventir en Big Data, cuando no se es capaz de obtener los datos relevantes, de transformarlos en información y más tarde en conocimiento transformador?

Inciso: un buen momento como otro cualquiera para mencionar la ética y honestidad.

Desigualdad

Hablemos de dinero. De retribuciones por trabajar.

En EEUU la relación entre el sueldo de un CEO (consejero delegado) y un trabajador era de 20 a 1 en 1965. Treinta años después, la ratio se había acercado a 90:1 con un crecimiento sostenido. A partir de entonces, la curva se lanzó hacia el cielo y en 2010 alcanzó el nivel de 200:1. La diferencia entre lo que cobra la cúpula y el trabajador medio ha aumentado hasta niveles inconcebibles en décadas anteriores.

¿Cuándo empezó la economía a premiar a los directivos fracasados? — Iñigo Sáenz de Ugarte (2012)

Cuando en entornos cercanos se quejan de lo gana un diputado (que sí, puede ser mucho comparado con otras retribuciones y en ocasiones es más de lo que se merecen), me suelo callar para no indignar más. Pero la situación es sumamente indignante.

Machismo y huelga

Y aunque el dinero no es el único factor que influye en el rendimiento y satisfacción de un trabajador, es importante. Y el respeto y la igualdad entre trabajadores también:

  • La Organización Internacional del Trabajo considera que "no se esperan cambios en los próximos años" en el avance hacia un mercado de trabajo más justo e inclusivo
  • Un informe de la entidad con las perspectivas para 2018 recoge que las mujeres tienen menos probabilidades de entrar al mercado laboral y, cuando lo hacen, tienen más opciones de estar desempleadas u ocupadas de manera precaria
  • Sobre la brecha de género respecto el salario a nivel mundial, la OIT afirma que "se observa que las mujeres ganan, en promedio, un 20% menos que los hombres"

La OIT advierte de que las medidas actuales para reducir la desigualdad entre hombres y mujeres son insuficientes

Hoy 8 de marzo, día de la mujer, hay convocada un huelga feminista. La primera. Personalmente, creo que sobran motivos: Ocho razones para la huelga feminista del 8 de marzo. Es una causa justa, como otras que menciono aquí, y como otras que quedan fuera del atípico batiburrillo de temas de este artículo.

Otra cita con la que me siento muy identificado:

Yo no quiero seguir siendo machista y por eso intento corregirlo y combatirlo, como haría con cualquier otra enfermedad crónica que hubiese heredado. He aprendido que si nunca he tenido miedo a ser violado es porque soy un hombre. Que si nunca me preguntaron en una entrevista de trabajo si pensaba tener hijos es porque soy un hombre. Que si no me perjudicó en mi carrera ser padre es porque soy un hombre. Que nadie ha pensado jamás que mis ascensos se debían a con quién me acostaba. Soy un hombre, un hombre que se pensaba que el machismo eran los otros.

También he aprendido, y a veces me ha costado, que las mujeres que denuncian el machismo ni son mi enemigo ni van contra mí. Que cuando denuncian que tienen miedo a ser violadas no están señalándome con el dedo ni acusándome de violador. Que cuando piden  romper el techo de cristal solo exigen lo que es justo. Que cuando critican que incluso los hombres que pensábamos que no éramos machistas tenemos que hablar menos y escuchar más, también tienen razón. Que el feminismo también es una tarea para los hombres. Que podemos ser feministas sin ser mujeres igual que debemos combatir el racismo aquellos que no estamos discriminados.

Hay mil motivos para esta huelga. Me quedo solo con uno. Que ellas lo han decidido.

Yo también soy machista — Ignacio Escolar

Kaizen: Mejora continua

¿Qué tiene en común todo lo expuesto anteriormente? Voy a terminar hablando de aprendizaje y Kaizen muy brevemente.
¿Aprendizaje? Sí, porque en parte entiendo que la vida es un proceso de aprendizaje. En todos los aspectos.
¿Kaizen? En el artículo vinculado en la wikipedia se habla, y creo que bien, de todos los matices que tiene el concepto.
Porque creo que es una obligación moral de todos a aprender y mejorar. Por nosotros. Por los que nos rodean. Por los que se ven afectados directa o indirectamente por nosotros.
Tenía que escribirlo, y aquí está. Era una tarea, las otras me acompañarán toda la vida.

28/02/2018 Categoría/s: Desarrollo web,Diseño,Diseño de interacción. 0 Comentarios

Diseño web: de la teoría a la práctica

Uno puede leer Universal Principles of Design, y aprender más o menos sobre diseño. Pero de la teoría a la práctica, a veces falta "algo más" que ayude a afrontar con confianza un proyecto.

Aquí van algunos recursos que nos muestran algo de teoría y práctica aplicada en el diseño web. Comencemos:

  • Laws of UX: probablemente conozcas la Ley de Fitt, la Ley de Hicks, la Regla de Occam,… en esta página se recopilar 13 leyes y aparte de una breve descripción, incluye algunos recursos adicionales.
  • En Las leyes de UX con casos prácticos, vemos algunos buenos ejemplos de cómo aplicar esas leyes.

Por otro lado, un par de enlaces para terminar:

  • 7 Practical Tips for Cheating at Design, tenemos algunos buenos consejos para mejora el diseño de páginas o aplicaciones.
  • Y en Redesigning Laravel.io, vemos como los mismos autores, explican el rediseño de un foro, basándose en muchos de los consejos del enlace anterior, y argumentando las decisiones.

21/09/2017 Categoría/s: Citas,Diseño de interacción. 0 Comentarios

Gamificación (o ludificación), motivaciones y experiencia de usuario

Tal vez lo más apropiado sería empezar por una definición de ludificación (término preferido por la RAE) ó gamificación (el término más empleado):

La gamificación es el uso de elementos de diseño de juegos en contextos no lúdicos.

Sebastian Deterding

Los propósitos de la gamificación son dos:

  • Creación de hábitos
  • Motivación de acciones concretas.

Y es una buena herramienta para problemas de origen motivacional.

Se puede mencionar de pasada la clasificación de jugadores según Bartle (Taxonomia de Bartle), según un estudio sobre Multi Users Dungeons; el hexaedro de tipos de usuarios de Marczewski (A player type framework for gamification design), un listado de mecanismos y elementos de la gamificación(52 gamification mechanics and elements) con un interesante test para saber qué tipo de jugador eres (Gamification UK User Test) y por último también se puede hablar de la clasificación de Yu-kai Chou (User and Player Types in Gamified Systems),... y es que al final, cada tipo de jugador tiene sus motivaciones, y existen mecánicas más adecuadas a un tipo de jugador que a otros. Existen unos cuantos marcos (o frameworks), como por ejemplo el de Yu-kai Chou (Octalysis – complete Gamification framework), y más que podrás encontrar si investigas un poco.

Antes de la cita final, apunto una reflexión (ajena): El objetivo de la experiencia de usuario es hacerle la vida más fácil, mientras que el del juego es la de complicársela un poco. Y sin embargo la gamificación puede ser una herramienta a tener en cuenta dentro de la experiencia de usuario ;)

En el fondo de esta cuestión [la gamificación] también están los objetivos de diseño.
Los objetivos de diseño en la gamificación se basan en pensar lo que motiva a la gente.
Qué motiva a la gente a realizar cierta acción.
Hablamos de cómo cambiar el comportamiento de la gente, cómo animas positivamente el comportamiento de la gente.

Dr. Lennard NackeLa ciencia tras la investigación en usuarios de juegos y gamificación

Bueno, lo dejo, que de tanto hablar de juegos me están dando unas ganas de jugar a Evolution. Juegazo ;)

03/08/2017 Categoría/s: Citas,ECMAScript. 0 Comentarios

El objeto this en ECMAScript

Uno de los grandes misterios de ECMAScript desvelado :)

We said earlier that this is not an author-time binding but a runtime binding. It is contextual based on the conditions of the function's invocation. this binding has nothing to do with where a function is declared, but has instead everything to do with the manner in which the function is called.

When a function is invoked, an activation record, otherwise known as an execution context, is created. This record contains information about where the function was called from (the call-stack), how the function was invoked, what parameters were passed, etc. One of the properties of this record is the this reference which will be used for the duration of that function's execution.

You Don't Know JS: this & Object Prototypes — Leslie Zhang

Y qué decir de los libros de la serie You don't know JS: muy recomendables.

02/08/2017 Categoría/s: Citas,Desarrollo web,ECMAScript. 0 Comentarios

DOM vs. todo lo demás

Como ya he comentado alguna vez, no estoy precisamente a la última en las nuevas tendencias de desarrollo web (¿?). Cuando empecé en esto, Netscape 4 era mayoritario, y empezaba a manifestarse una guerra de navegadores frente a Internet Explorer.
Obviamente todo ha cambiado mucho: ordenadores, navegadores, pantallas, soporte de estándares, velocidad de conexión, las librerías de javascript, los frameworks web, los móviles, y ese mundo inabarcable en el que se está convirtiendo todo lo relacionado con el desarrollo web: npm anuncia 475.000 building blocks ahora mismo.
Lo raro es no tener fatiga de desarrollo web y javascript. Lo normal es sufrir ansiedad porque es imposible estar al día.

Terminado el inciso pseudohistórico y de salud mental, y antes de la cita del 2015 que quería incluir, me gustaría dejar apuntadas algunas reflexiones no muy elaboradas, pero que merecen tenerse en cuenta:

  1. Cada bloque de código y fichero que se incluye en una página web, implica un aumento del tiempo de carga: ya sea una imagen, o una hoja de estilos. Cada kilobyte cuenta.
  2. Cada nodo que se añade al DOM, es un elemento más a tener en cuenta para el motor de renderizado del navegador.
  3. Cuando usamos una librería que trabaja con el DOM o una abstracción del mismo, implica que se incrementa el número de eventos que están a la espera aunque no se utilice. Afecta al rendimiento (tiempo de carga, uso de memoria,…). Yo desde hace años tengo la imagen mental de un frasco lleno de avispas nerviosas :)
  4. Cada nueva librería, plugin,... añade complejidad y posibles problemas de compatibilidad.
  5. La dependencia en el desarrollo de wadus-script junto un equipo de desarrollo con más o menos conocimiento específico, puede tener un alto coste si hay que reemplazarlo.

Claro, que también se puede ver desde el siguiente punto de vista:

  1. Hay código y ficheros de una página web, que valen su peso en oro.
  2. Algunos elementos extra de HTML, identificadores o clases pueden ser muy útiles (aunque todavía no lo sepamos).
  3. Hay librerías que simplifican mucho el tiempo y la eficiencia en el desarrollo.
  4. Al igual que en el punto anterior, hay librerías que pueden simplificar el desarrollo e incluso solucionar problemas de compatibiliad (como html5shiv o es5-shim).
  5. El uso del wadus-script de turno por un equipo competente, puede tener resultados brillantes.

Por lo tanto, depende es una palabra clave ante estas cuestiones. Al final el factor determinante debería ser el proyecto a desarrollar y el rendimiento (en tiempo de carga, tiempo hasta que se puede interactuar, tiempo de desarrollo, calidad de código y facilidad de mantenimiento,...).

La teoría, en ocasiones es sencilla :)

Y ahora, la cita en cuestión.

The DOM Is Just Fine

It puzzles me that developers seem to create themselves a problem and then they point the finger around to search and blame the cause: no, the DOM is not your problem, the fact you brought an over-engineered abstraction on top of a deadly simple task, like a table that needs some quick update, is the real problem you don't want to see.
It scares me that developers behind frameworks seem to be often incapable of getting some fresh air and think out of the cell they put themselves in: learning and using only that framework, ignoring everything else ... sometimes forgetting even common sense, probably shadowed by the framework approach.
Let's do ourselves a favor, let's stop being religious about any sort of framework and learn what the native world has to offer, what other frameworks have to offer too, and what's the best solution for that specific problem, which is never every problem we have!
Every framework was born to solve a very specific problem ... have you asked yourself if that is really the same problem you have and the one you need to solve?
Moreover, there will always be a faster, ad-hoc, way to do this or that and your framework cannot cover all the cases ... it's actually the opposite: the more cases it will cover, the slower it will be. So let's please stop moaning about the DOM and start doing things in a different way ... shall we?
We'll be those with most benefits, after all, so please think about it.

The DOM Is NOT Slow, Your Abstraction Is Andrea Giammarchi

Categorías