Toda disciplina tiene conceptos claves sobre los que se cimientan todas las herramientas, metodologías y el trabajo cotidiano. Las ciencias exactas tienen las Leyes de Newton, las ciencias naturales tienen a la ley de la selección natural, los sistemas informáticos tienen la teoría de sistemas… creo que se entiende la idea.
UX es un campo que tiene poca estandarización de qué conocimiento se necesita para “graduarse” en la disciplina, y eso está bien porque es lo que permite una combinación infinita de variables para aplicarse, sin embargo, nosotros también tenemos nuestros conceptos sobre los que se fundamentan todas las decisiones de diseño y establecen un marco objetivo de qué es buen diseño y que no. Estos principios han sido desarrollados, establecidos y comprobados por distintas personalidades en las últimas 4 o 5 décadas y han quedado plasmadas en libros y en metodologías, recursos de consulta y pláticas que se vuelven el “pan de cada día” de todo diseñador de experiencia.
Conocer y entender estos principios te permitirán “ponerle nombre” a algunas cosas que tal vez ya haces de manera intuitiva, permitiéndote utilizar el lenguaje correcto para intercambiar ideas con otros diseñadores, así como conocer el marco completo de por qué decimos las cosas que decimos. En este artículo te voy a poner solo lo más básico de cada tema y te lo voy a platicar como -yo- suelo explicarlo en clase, y eso es utilizando el lenguaje que puede ser no estrictamente académico. Para poder conocer a profundidad cada tema, te recomiendo mejor leer el libro de cada autor, que además te da puntos extra de ñoñéz.
Los principios son:
- Los componentes de la experiencia de usuario
- Affordances & Signifiers
- Heurísticas
- Arquitectura de Información
- Sesgos cognitivos
- UX en Procesos ágiles
¿Listo? Arrancamos:
1. Los componentes de la experiencia de usuario
de Jesse James Garrett — The elements of User Experience
Jesse James Garret es el autor de una estructura fundamental que descompone los elementos necesarios para construir cualquier experiencia.
Este diagrama es conocido como “las capas de Garrett” y muestran la jerarquía del entendimiento y entregables que deben desarrollarse en un proyecto de UX.
Garret divide los componentes de una experiencia en 5 capas, de abajo hacia a arriba, destacando como las capas superiores se construyen como resultado del entendimiento en las capas inferiores.
Capa 1: Necesidades del usuario y objetivos del sitio o sistema a construir
Capa 2: Qué hará el sistema y qué contenido albergará
Capa 3: Cómo se estructura ese contenido y cómo se interactúa con él
Capa 4: Cómo el usuario utiliza y accede al contenido
Capa 5: Cómo se muestra ese contenido.
Capa 1. Estrategia:
Para comenzar cualquier experiencia, siempre tenemos que comenzar con un claro entendimiento de las necesidades que este sistema debe resolver para el usuario, así como el objetivo de negocio que este sistema cumple.
Básicamente, Garret estipula que toda experiencia debe tener un propósito claro y concreto, definido antes de comenzar a trabajar cualquier tipo de entregable, derivado de un proceso de entendimiento tanto de la perspectiva del usuario como del negocio.
Capa 2. Alcance:
Una vez definidas las necesidades del usuario y los objetivos del negocio, se deben definir los requerimientos del sitio a desarrollar. Estos requerimientos se dividen en 2: funcionales y de contenido.
Los requerimientos funcionales son las tareas que el sistema debe cumplir para poder atender las necesidades del usuario y alcanzar los objetivos definidos por parte del negocio. Estos requerimientos generalmente se plasman como tareas y, en este nivel, se identifican más como expectativas y resultados esperados que como flujos, ya que esto se desarrollará en pasos subsecuentes.
Respecto a los requerimientos de contenido, esto implica identificar la cantidad de imágenes, gráficas, textos, secciones, enlaces y en general todo el contenido multimedia que se necesitará para cumplir con las necesidades del usuario y los objetivos del negocio.
El ejemplo de esto sería: Funcionalidad es definir que un usuario podrá pausar y adelantar canciones en un reproductor de música. Contenido es contar con los archivos fuente que serán reproducidos con dicho reproductor.
Capa 3. Estructura:
Derivado de los inventarios de funcionalidades y contenido, ahora se debe establecer los sistemas de navegación, jerarquía y búsqueda que facilitarán que el usuario interactúe con dicho contenido. Esta capa se divide en 2: Diseño de interacción y Arquitectura de información
Diseño de interacción hace referencia a cómo los usuarios van a interactuar con el contenido definido en el inventario de la etapa anterior. Aquí se define si habrá botones, scroll, sliders, contadores, se definen mensajes de error, pantallas de carga, etc. Todo a nivel funcional (porque lo estético va mas adelante).
Arquitectura de información hace referencia a la estructura que dicho contenido tendrá dentro del sistema, es decir dónde va cada contenido, cuál es su relación con otros contenidos y cómo el usuario llegará a el (secciones, sub secciones, buscadores). De arquitectura vamos a profundizar más adelante porque también tiene su respectivo choro.
Capa 4. Esqueleto:
Aquí es cuando ya se comienza a hacer el “wireframe” o los primeros bocetos de lo establecido en la estructura.
El objetivo de esta etapa es el de comenzar a visualizar los diferentes contenidos, ya interactuando unos con otros, y asegurarnos de que la estructura que se propone es funcional, clara y cumple con los objetivos del usuario y del negocio. En esta etapa se pueden desarrollar distintos entregables con un nivel progresivo de detalle, para ir validando ideas de lo general a lo particular.
En general, un buen wireframe nos debe decir:
- Qué información se puede ver en pantalla
- Cómo y dónde estarán los elementos interactivos
- Cómo se navega entre los distintos contenidos
- Que el contenido presentado sea claro y facilite cumplir las tareas
Capa 5. Contenido visual:
Lo último que se define en una experiencia son los componentes visuales, específicamente los colores, tipografías, pesos y otros elementos que tomen en cuenta principios de diseño visual.
En esta capa nos aseguramos que los componentes interactivos y estáticos se distingan, que el texto sea legible y que el sistema sea congruente a nivel experiencia.
Trabajando con las capas:
El aprendizaje de cada una de las capas debe permear y moldear el trabajo de las capas posteriores, así que las capas se trabajan de una manera secuencial, pero integrándose entre sí.
2. Affordances & Signifiers
de Don Norman — The Design of Everyday Things
En su libro “The Design Of Everyday Things” Don Norman expone el concepto de Affordance y Signifier.
Affordance es lo que un usuario cree que puede hacer con un sistema (“Afford to do”), según su expectativa, entendimiento previo y lo que la primera impresión del sistema le “dice” que puede hacer. Por ejemplo, si vemos algo que parece una puerta, asumimos que se puede abrir, aunque no sea claro cómo y para qué lado.
Disclaimer: El muy estimado Víctor Gonzáles (Victor M. Gonzalez) me ha hecho el comentario de que mi definición es equivocada, siendo la correcta: “Un affordance es lo que el ambiente le ofrece a individuo. En el contexto de UX o User Interface Design, es lo que el sistema interactivo ofrece al usuario”
Básicamente, el Affordance es una propiedad del objeto o del sistema, no del usuario, esto es 100% correcto pero para fines explicativos, creo que es más fácil pensarlo desde la perspectiva del individuo, porque así podemos correlacionarlo con nuestras experiencias pasadas y nuestras propias frustraciones cuando un sistema no nos ha comunicado “correctamente” lo que es posible hacer.
Un Signifier es algo que le informa al usuario qué puede hacer y cómo hacerlo.Esto puede ser utilizando convenciones de sistemas similares, con textos o incluso utilizando principios de ergonomía que le digan al usuario de manera implícita cómo interactuar con el sistema.
Honestamente, es difícil explicar la diferencia entre estos dos conceptos, porque un Signifier también genera un Affordance.
Por ejemplo, una puerta que tiene un letrero de “abrir” le está “diciendo” al usuario qué es lo que puede hacer con ella y según cómo esté diseñada la puerta, también podría estarle explicando el “cómo hacerlo”
Lo importante es quedarse con la idea de que los humanos, por naturaleza, vamos a intentar asumir qué podemos hacer con algo, según nuestra experiencia previa y lo que “parece” que podemos hacer. Es decir, ya hay una pre-disposición que establece nuestra expectativa de lograr algo, aunque nunca lo hayamos visto o hayamos interactuado con el sistema en cuestión.
Lo más imprortante de este concepto, es que nos da control sobre lo que es una “buena experiencia”, y eso es evitando una “mala experiencia”
Una mala experiencia sucede cuando nosotros pensamos que podemos hacer algo, pero el sistema no nos lo permite (falso affordance). Básicamente, cualquier cosa que no sea un falso affordance, puede crear una experiencia positiva o, de menos, neutral.
Hay muchos tipos de affordance, según si el sistema le comunica al usuario, de primera mano o de manera oculta, que puede lograr algo. El único realmente malo es Falso Affordance, por eso siempre es importante decirle al usuario, aunque sea de manera implícita, que puede hacer, para no crear expectativas que no se cumplen.
Además de las malas experiencias, los falsos affordances suelen usarse también para engañar a los usuarios y aplicar “patrones oscuros” que es básicamente un sistema que dice que hacer una cosa, pero realmente hace otra.
Por ejemplo, en este anuncio que pasaba en Stories de Instagram, le decía al usuario que tenía que mover un slider hacia arriba para hacer más rápido su teléfono, pero ese gesto instalaba una aplicación.
El affordance es “se que el slider se mueve hacia arriba, y el sistema me está diciendo que esto hace mas rapido mi teléfono”. Si el usuario nunca ha visto esto como un patrón malo, seguramente caería en el engaño.
3. Heurísticas
de Jakob Nielsen — Designing Web Usability
Don Norman es un investigador cognitivo, Jakob Nielsen es ingeniero y sus hallazgos son más orientados a crear sistemas usables, más que a tratar de explicar por qué algo es usable. Ambos son los que objetivamente podemos considerar como “padres” de la usabilidad moderna.
En los 90’s Nielsen estableció una serie de principios o recomendaciones que hacen que un sistema sea usable. Se llaman heurísticas porque son reglas que no siempre se aplican o no siempre se aplican igual.
Yo suelo explicarlo como “los derechos” de nuestros usuarios, que tenemos que tomar en cuenta para todas las experiencias en herramientas interactivas.
Heurísticas de entendimiento
Estas heurísticas afectan cómo el usuario “entiende” o percibe un sistema:
- El usuario tiene derecho a que tu sistema utilice un lenguaje y un patrón de navegación con el que ya esté familiarizado (de otros sistemas o del mundo offline)
- El usuario tiene derecho a tener una experiencia consistente, a nivel visual, de navegación, interacción y lenguaje.
- El usuario tiene derecho a ver únicamente lo estrictamente necesario para cumplir con su objetivo, sin contenido basura o innecesario.
Heurísticas de interacción
Estas heurísticas afectan cómo el usuario interactúa con un sistema:
- El usuario tiene derecho a poder usar un sistema como él quiera, navegando, saliendo y haciendo lo que quiera con la información. La percepción de libertad es un Affordance.
- El usuario tiene derecho a poder utilizar su aprendizaje previo para explorar tu sistema, en vez de obligarlo a aprender algo nuevo.
- El usuario tiene derecho a usar el sistema dónde quiera, en cualquier contexto, plataforma o dispositivo.
Heurísticas de retroalimentación
Estas heurísticas afectan cómo el usuario se informa de lo que pasa con el sistema:
- El usuario tiene derecho a saber qué está pasando con el sistema (si está conectado, disponible, apagado, etc.)
- El usuario tiene derecho a poder recuperarse en caso de cometer un error y el sistema debe ayudarlo a prevenirlos (campos mal llenados, recuperación de sesión)
- El usuario tiene derecho a poder solicitar ayuda o a consultar documentación que le explique cómo resolver un problema.
Ejemplos
Visibilidad del sistema:
El usuario sabe que se está subiendo su archivo, así como el progreso y dónde quedará.
Además, el usuario puede cancelar (libertad)
Libertad:
El usuario puede elegir si quedarse con un borrador de un post, o descartarlo.
Esto también implica prevención de error, en caso de que el abandono sea accidental.
Recuperación de error:
El usuario puede recuperar su usuario en caso de olvidarlo.
También implica visibilidad de estado, porque el usuario sabe cuál es el error.
4. Arquitectura de información
de Louis Rosenfeld — Information Architecture for the web and beyond
La Arquitectura de Información el la disciplina de acomodar el contenido, producto de un inventario de tareas y contenidos, cómo lo vimos en las capas de Garrett.
Sin embargo, el proceso de Arquitectura de información tiene su propio proceso y sus propias definiciones, que son las que vamos a explorar.
La arquitectura de información se compone de 4 sistemas:
- Sistemas de clasificación
- Sistemas de navegación
- Sistemas de etiquetado
- Sistemas de búsqueda
Yo siempre comparo la arquitectura de información con la arquitectura civil. Hacer un sitio o un sistema es como hacer una casa, a ver si les funciona mi ejemplo.
Cuando hacemos una casa, lo primero que tenemos que definir es el tamaño del terreno que tenemos y luego cómo vamos a distribuir ese terreno.
¿Va a ser una casa? ¿Para cuantas personas? ¿Va a tener garage?
El dueño de la casa te dice si tiene hijos o si está casado o si quiere un estudio. De ese requerimiento inicial puedes inferir cuántos baños o de qué tamaño proporcional debe ser el comedor.
En este paso, revisas tu inventario de contenidos y de funcionalidades y haces agrupaciones “generales” de cómo va a ser tu sistema. A lo mejor sabes que habrá un home, una sección para clientes nuevos y una para clientes actuales. Esos son tus grandes “cuartos”, cómo vas a segmentar tu terreno.
Ya que hiciste tus grandes secciones, para saber que ocupas todo el terreno y que no te vas a pasar, y que cubres las funcionalidades básicas, empiezas a diferenciar las secciones entre sí.
En una casa, la diferencia entre una recámara y un estudio, son los muebles que tienen dentro y el uso que le damos. De igual manera, la diferencia entre una página de producto y un home, es el contenido que tiene y lo que esperamos que el usuario haga con esa página.
En esta etapa definimos qué es lo que hace que una recámara sea una recámara, independientemente del tamaño que tenga. Por ejemplo, que tiene que tener una cama un closet.
De la misma manera, nos encargamos de que no haya cosas que no están relacionadas, como tener un WC en la cocina.
Hasta aquí hemos abarcado el sistema de categorización y el de jerarquía.
El sistema de etiquetado, de lo que va, es de nombrar las cosas de una manera que sea fácil de encontrar y que sea “auto-explicativo” de qué vas a encontrar de esa sección o de ese contenido.
El etiquetado va en función de la estructura. Primero agrupas el inventario de contenidos individuales y luego a eso le pones un nombre que los agrupa o que te dice claramente que son.
Si te digo “el cuarto con una cama y un clóset” no habría diferencia entre la recámara principal y la de los niños, pero si digo “la recámara principal” queda más claro que me refiero a la recámara más grande, aunque semánticamente tenga “la misma información”, puedes saber que no es para lo mismo.
Igual, aquí defines si le vas a poner “sala” o “estancia” o “livingroom”. Es decir, el etiquetado siempre va en función de cómo el usuario entiende el contenido, no como nosotros le queremos decir.
El sistema de navegación hace referencia a las maneras que tiene el usuario para navegar entre los distintos contenidos.
¿Hace sentido tener una puerta que conecta el baño con la cocina? ¿O crear un pasillo de la recámara a la sala? ¿Cuántas entradas debería tener la casa?
El sistema de navegación es lo que le permite al usuario saber a dónde se puede mover desde dónde está y le ayuda a saber cuál es la manera más eficiente de llegar al contenido que necesita.
Por último, el sistema de búsqueda es el sistema encargado de definir los metadatos o las palabras clave que utiliza el usuario para encontrar un contenido en particular.
Obviamente aquí ya no aplica el ejemplo de la casa porque no usamos un buscador para movernos entre cuartos o para saber en dónde está algo, pero si podría ser como las distintas maneras que distintos usuarios podrían referirse a una habitación en particular, ya sea por el nombre de la habitación, la función que tiene, el momento del día en el que se usa o lo que contiene.
Sistema de categorización y jerarquía
¿Cuántos componentes hay en el sistema? ¿Cuántos se pueden agrupar? ¿Cuántos grupos se pueden formar?
Sistema de etiquetado
¿Cuántos tipos de contenido hay? ¿Cómo los identifica el usuario?
¿Qué los hace únicos?
Sistema de navegación
¿Cómo llegar al contenido? ¿Qué es un contenido padre / hijo?
¿Cómo saltar a otro contenido? ¿Qué contenido se relaciona?
Sistema de búsqueda
¿Qué contenido indexar? ¿Qué filtros aplicar?
¿Qué términos utiliza para buscar el usuario?¿Cómo se presentan los resultados?
Al igual que con la arquitectura civil, un arquitecto puede plasmar su trabajo en una servilleta o en una maqueta de cartoncillo, así como realizar distintos tipos de planos (para el eléctrico, para el plomero, para el levantamiento de los muros, para el cliente, etc).
De la misma manera, estos sistemas de arquitectura se plasman en distintos tipos de documentos, según los requerimientos del proyecto y las personas involucradas en él.
5. Sesgos cognitivos
de Daniel Kahneman – Thinking Fast and Thinking Slow
Mi documento favorito de sesgos cognitivos es este
Los sesgos cognitivos son “atajos” que nuestra mente toma para poder procesar la información que percibimos todos los días.
El cerebro es el órgano que más calorías requiere para funcionar y por lo tanto pensar incurre un costo energético alto. Los sesgos nos ayudan a no pensar en todo, todo el tiempo, solamente en las cosas que nuestro cerebro considera “necesarias” o importantes.
Todos caemos en los distintos tipos de sesgos, y la manera en la que los vivimos es diferente, según nuestros contextos, aprendizajes y entornos culturales.
Los sesgos no son reglas. Son hipótesis u observaciones generales a comportamientos a nivel poblacional y jamás deben asumirse como una explicación objetiva ya que cada quien los experimenta de maneras diferentes y como consecuencia de diferentes estímulos.
Lo más importante de entender los sesgos es entender que nuestra percepción de la realidad es, por definición, la única manera que tenemos para saber qué es real. Si un sesgo nos evita ver algo, por definición, ese algo no existe para nosotros. Está fuera de nuestro control.
Alan Cooper (Otro de los viejitos de la disciplina que tienes que conocer por nombre, como Norman, Nielsen, Garrett, Moore y Rosenfeld) explica que, según los académicos, hay dos grandes tipos de “atajos” que toma el cerebro:
- Atajos para pensar rápido (Sistema 1)
- Atajos para pensar mejor (Sistema 2)
En el Sistema 1 están las cosas que se deciden por impulso o por “pensar rápido” y estas implican decisiones poco racionales, que hemos tenido poco tiempo de entender o asimilar y cosas que nos hacen reaccionar según el estado actual de nuestro contexto. Dependen más del instinto, de aprendizajes previos y de apariencias superficiales.
El Sistema 2 es el que nos lleva a pensar las cosas a mayor detalle, a entender consecuencias y a visualizar el impacto de nuestras decisiones. El sistema 2, por definición, ocupa más energía que el sistema 1, así que no es el “sistema default”. Generalmente requiere un esfuerzo adicional mover a alguien de pensar con el Sistema 1 al Sistema 2.
Atajos para asimilar mucha información
- Somos vulnerables a lo que nos repiten mucho.
- Creamos patrones (aunque no existan).
- Ponemos más atención a lo que confirme lo que ya sabíamos-
- Lo que es diferente a lo “normal” puede parecer más llamativo de lo que realmente es.
Atajos para decidir qué recordar
- Generalizamos.
- Reforzamos lo que ya sabemos (nos cuesta aprender cosas nuevas o que van en conflicto con cosas que ya sabíamos antes)
- Hacemos listas o pasos.
- Categorizamos recuerdos según nuestro propio mapa mental.
Atajos cuando no queremos pensar o hay que decidir rápido
- Evitamos flujos que requieren que tengamos que pensar o tomar decisiones (buscamos recomendaciones, top 10, preguntamos a otros)
- Valoramos indicaciones simples que nos digan el paso inmediato para lograr algo.
- Evitamos flujos que tengan un potencial de error o que no nos den seguridad o certeza del resultado.
- Seguimos con proyectos a los que les hemos invertido tiempo, aunque sean inútiles o sepamos que no sirven. (Más vale malo conocido que bueno por conocer).
- Somos susceptibles a las “corazonadas” o a las gratificaciones instantáneas, por encima de las ganancias a largo plazo (aunque sean mayores)
Atajos para “inventar” información que no tenemos
- Nos inventamos patrones que parecen explicar información que no tenemos (horóscopos, astrología)
- Proyectamos nuestras ideas en otras personas (esto a mi me gustaría, entonces le gustaría a todos)
- Estereotipos y generalizaciones
- Simplificamos probabilidades (2 amigos tuvieron una mala experiencia, no me importa la validez estadística de esa muestra, para mí ese servicio es malo)
- Solemos pensar que lo que ya sabemos vale más que lo que no sabemos (algo que conozco es mejor que algo que no conozco)
6. UX en procesos ágiles
de Jeff Gothelf — Sense and Respond
Los procesos ágiles suelen ser hostiles a las metodologías de investigación, porque mientras que ágil se encarga de entregar soluciones productivas rápido, algunas de nuestras herramientas de investigación pueden tomar más tiempo de lo que el Scrum quisiera para generar información.
Con esto en mente, Jeff Gothelf, autor de Lean UX, hizo este diagrama en donde explica qué herramientas de diseño se aplican en qué momento del proceso ágil.
En la primera etapa, Gothelf sugiere que para agregar historias de usuario al backlog de producto, se hagan ejercicios como Design Sprints y bajar los hallazgos de investigación de campo. Hay que recordar que el Backlog de producto es en dónde van todas las funcionalidades que esperamos que el producto tenga, ya sea en este Sprint o en algún momento del futuro. Aquí es dónde más “tiempo” hay para investigar porque, en teoría, todavía no se ha comenzado a trabajar en implementación
Para pasar features del Product Backlog al Sprint Backlog, Gothelf sugiere hacer sesiones de ideación y de bocetado en donde todo el equipo comience a visualizar cómo se imagina el flujo de implementación o cómo se imaginaría las pantallas. El hacer que este proceso sea colaborativo ayuda a que las ideas “sean de todos” y entonces haya un mayor compromiso en llevarlas a fricción.
En el desarrollo del Sprint es cuando se hacen los entregables “tangibles” del proceso de diseño. Wireframes, prototipos, maquetas, copies, MPVs. También en cada Sprint se pueden agendar sesiones de investigación cualitativa que deriven en otros entregables de diseño en sprints posteriores.
Lo importante de esta etapa es que, ya con un Sprint arrancado y con un backlog definido, no es buena idea hacer ejercicios de ideación o de exploración. Porque no generan entregables tangibles y pueden hacer sentir al Scrum que UX no contribuye.
Por último, es al cierre de cada sprint, durante los reviews, que se hace una evaluación “experta” de diseño (puede ser con análisis heurístico) o se realizan las pruebas con usuarios para obtener retroalimentación del entregable productivo.
Además de la etapa del proceso ágil en la que se encuentra cada proyecto, también hay una sugerencia de que metodología de investigación aplicar según el ciclo de vida en el que se encuentra el producto. Esto es importante porque determina qué tarea vamos a ejecutar en cada Sprint que genere la información que el Scrum necesita para continuar con su trabajo.
NNGroup (de Nielsen Norman) agrupa las metodologías de investigación en 4 grandes categorías:
- Discover: Cuando apenas se está explorando una solución y no se tiene definida ni una propuesta de valor, un segmento de usuario o un modelo de negocio.
- Explore: Cuando ya hay una propuesta de valor definida y más bien se quiere profundizar en entender la mejor manera de cumplirla.
- Test: Probar un producto que está en desarrollo, y está por lanzarse.
- Listen: Obtener retroalimentación de un proyecto que ya está en productivo y está generando data real de usuarios que lo están utilizando y más bien requiere mejoras, por encima de nuevas funcionalidades.
Cómo última variable, además de escoger el método de investigación correcto según el sprint y según la etapa del producto, también tenemos que escoger la metodología que nos da la información que necesitamos en términos de si queremos entender un comportamiento a nivel poblacional y con valor estadístico (cuantitativa) o si queremos analizar un comportamiento, mapa mental o sesgo cognitivo en particular, que requiere entendimiento cualitativo.
Diferentes metodologías, cuando se aplican correctamente, arrojan distintos tipos de datos. El entender esto nos ayuda a evitar resultados como “3 de cada 5 usuarios que entrevistamos sienten confusión” que estaría aplicando un atributo cualitativo (sentir confusión) a un valor estadístico (3 de cada 5).
En este caso, lo correcto sería que durante la entrevista hubo usuarios que expresaron confusión (no importa cuantos) y que 3 de cada 5 no completaron la tarea (25% de tasa de éxito de la tarea evaluada).
Ojalá esta información te sea de utilidad. No olvides que esto es solo la “superficie” de los conceptos y que si quieres entenderlos a cabalidad lo más recomendable es leer la literatura de cada uno de los conceptos.
El correcto manejo de estos principios te va a ahorrar mucho tiempo y trabajo, porque no necesitas andar inventando el hilo negro. Además, el fundamentar tus hallazgos y propuestas en este tipo de principios te permitirá también mostrar que es más que una opinión o un capricho, porque objetivamente si podemos escoger qué metodología utilizar, objetivamente podemos definir qué es buen diseño y que no.
Usa sabiamente esta información, compártela y escríbeme si tienes alguna duda o comentario. Felices trazos.
