3 librerías imprescindibles de Java
Guava Guava es un conjunto de librerías principales de Java desarrollado por Google. Incluye nuevos tipos de colecciones (MultiMap y MultiSet), colecciones inmutables, una librería para modelar datos estructurados en grafos, así como utilities para concurrencia, I/O, hash, almacenamiento en caché, strings y mucho más. Como Apache Commons, es modular, pero presenta un diseño mejor. ➡️ https://guava.dev/ Log4j2 El logging es fundamental para el desarrollo de un software, especialmente en su etapa de producción. Al registrar todos sus eventos, permite entender su funcionamiento y ayuda a localizar la causa de un error cuando éste se produce. Java cuenta con sus propios recursos de logging, pero existen otras librerías que ofrecen funcionalidades más avanzadas. Log4j2, junto con Logback, es la librería simple de logging más conocida. Destaca por ofrecer una mejor performance a través del logging asíncrono. Además, su API está separada de la implementación, lo que permite que el equipo de Log4j2 haga mejoras de forma segura y compatible. Proporciona filtros avanzados, basados en datos de contexto, marcadores, expresiones regulares y otros componentes en el Log Event. Utiliza una arquitectura de plugin. ➡️ https://logging.apache.org/log4j/2.x/ Jackson Jackson es un conjunto de herramientas imprescindible para el procesamiento de datos en Java. Incluye una librería interpretadora / generadora de JSON en tiempo real (JSON es actualmente el formato por excelencia para la transmisión de información entre cliente y servidor). Asimismo, dispone de una librería de Data-Binding, que convierte POJO en JSON y viceversa, y módulos para el procesamiento de datos en formatos como Avro, BSON, CBOR, CSV, Smile, Java Properties, Protobuf, XML o YAML. Además, admite otros tipos de datos ampliamente utilizados, como Guava, Joda y PCollections. Es modular, con un núcleo con funcionalidades básicas y numerosas extensiones. ➡️ https://github.com/FasterXML/jackson
Qué es el Daily Scrum
La Daily Scrum es un tipo de reunión que existe en la metodología Scrum y que tiene bastante importancia en el desarrollo completo del proyecto. Es una reunión diaria y muy breve, no debe superar nunca los 15 minutos, que van a tener todos los miembros del equipo, que básicamente para lo que sirve es para saber cómo va cada miembro del equipo. Es habitual que esta reunión se alargue mucho o que en la misma se hablen temas que no corresponden a la misma, por lo que vamos a dejar claros algunos conceptos y a dar algunos consejos para seguir en estas reuniones. La Daily Scrum está pensada principalmente para responder a tres preguntas, es decir, cada miembro del equipo tiene que responder a tres preguntas, que serían las siguientes: ¿Qué hice ayer? ¿Qué es lo que voy a hacer hoy? ¿He tenido algún tipo de problema durante el desarrollo o si tengo algún problema? Esas son las tres cosas que debe decir cada miembro del equipo, por lo que para un equipo de Scrum, que debe tener entre 3 y 9 personas, en 15 minutos da tiempo más que suficiente para detallar simplemente esas cuestiones.
¿Qué es Scrum? Roles y proceso
Scrum es un marco de trabajo (framework) ágil en el que se aplican un conjunto de normas para organizarse de manera colaborativa a través de diferentes roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Su objetivo es obtener el mejor resultado posible y conseguir una alta productividad. El origen del concepto de Scrum está basado en un estudio realizado en el año 1986 por Harvard Business Review (HBR) titulado “El juego de desarrollo de nuevos productos ” de Hirotaka Takeuchi e Ikujiro Nonakasobre, sobre los procesos de desarrollo de productos que tuvieron mucho éxito en Japón y Estados Unidos y cuyos responsables eran empresas como Canon, Xerox, Honda o HP, entre otros. Scrum se define por la realización de entregas parciales de manera regular de un producto final, que se van priorizando según indica el responsable del proyecto (product owner). Scrum es utilizado principalmente para proyectos de desarrollo de software con entornos complejos que requieren la obtención rápida de resultados, y en el que van cambiando los requisitos. Esto supone trabajar de manera flexible y productiva. ¿de dónde viene el término? El término “scrum” surge del rugby. En concreto, hace referencia a un tipo de formación que lleva a cabo un equipo para reanudar el juego tras un error o una infracción de las normas. El término ha sido tomado en este marco para definir la gestión eficaz de equipos en el desarrollo de productos, en el que sus componentes aprenden mediante las diferentes experiencias, se organizan y trabajan en los problemas con vistas a mejorar continuamente. ¿Cuáles son los roles de Scrum? Product Owner: es el encargado de optimizar y maximizar el valor del producto, siendo la persona encargada de gestionar el flujo de valor del producto a través del Product Backlog. Adicionalmente, es fundamental su labor como interlocutor con los stakeholders y sponsors del proyecto, así como su faceta de altavoz de las peticiones y requerimientos de los clientes. Además, al ser intermediario entre los stakeholders y el equipo de desarrollo, debe saber entenderse con ambos. Scrum Master: Se encarga de gestionar el proceso Scrum y ayuda a eliminar impedimentos que puedan afectar a la entrega del producto. Su objetivo es conseguir un equipo de alto rendimiento en los que se incluye el equipo de desarrollo, product owner y sus relaciones con la organización y stakeholders. Equipo: lo forma un grupo de personas multidisciplinar de entre tres y nueve miembros. Es un equipo de profesionales encargados de llevar a cabo incrementos de desarrollo en cada sprint. Se caracteriza por ser autogestionado, empoderado, auto-organizado y tiene los conocimientos y capacidades necesarias para completar el trabajo. Proceso El marco de trabajo Scrum se basa en ajustar los resultados y responder a las exigencias reales y exactas del product owner. Scrum se ejecuta en bloques temporales que son cortos y periódicos, llamados Sprints, que suelen oscilar entre 2 y 4 semanas, que es el término para la retroalimentación y la reflexión. La dinámica que se lleva a cabo es la revisión continua de entregas, debido a los cambios que se van produciendo en los requerimientos. En cada iteración se presentan los avances del producto y el posible entregable. Sprint planning El Sprint planning es un evento en el marco de Scrum donde el equipo define los elementos del product backlog en los que trabajarán durante ese sprint y analizarán su plan inicial para completar esos elementos. Los equipos marcan en cada sprint un objetivo que utilizarán para determinar los elementos del product backlog que trabajarán durante ese sprint. La Planificación de Sprint responde a las siguientes preguntas: ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza? ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento? Ejecución Cada día el equipo de trabajo realiza una reunión (daily) de 15 minutos como máximo. Aquí se analizan las dependencias entre tareas, el progreso del proyecto, los obstáculos que impiden el desarrollo, y se buscan las soluciones necesarias para permitir que se cumpla con la previsión de los objetivos marcados al final de la iteración que permitan cumplir con la previsión de objetivos a mostrar al final de la iteración para poner en común la evolución de las tareas asignadas, y, a la vez, diseñar posibles soluciones a los fallos. Normalmente, se utiliza un tablero sencillo donde organizar el Backlog así como las tareas en las que se está trabajando en el sprint actual y su progreso. Lo fundamental de esta herramienta es la transparencia para que todo el equipo visualice de manera clara las cosas que están haciendo, el progreso y los objetivos que tienen que cumplir. El tablero puede realizarse en un formato físico, como una pizarra o realizarlo a través de herramientas online como Trello. El Scrum Master, se encarga de que el equipo cumpla los objetivos durante la iteración. Asimismo, el product owner revisa junto al equipo la lista de requisitos y, si es necesario, cambian los objetivos del proyecto de las siguientes iteraciones para maximizar la utilidad del producto y el retorno de la inversión. Inspección y adaptación: Sprint review: cuando finaliza la iteración el scrum master junto al equipo presenta a los stakeholders el incremento del producto. Esta reunión tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración Retrospectiva: Es un punto en el tiempo donde el equipo se reúne y reflexiona sobre acontecimientos pasados y su manera de trabajar y acuerda acciones de mejora. Al finalizar la retrospectiva se definen una serie de acciones y responsables de las mismas con el fin de mejorar de cara a siguientes Sprints Beneficios de Scrum para las empresas Fomentar la motivación y compromiso del equipo que trabaja en el proyecto. Predecir el tiempo y establecer fechas realistas de entrega de proyectos. Fomentar la responsabilidad del equipo y aumentar la autonomía y la auto-organización. Mejorar la productividad y la calidad. Minimizar costes y maximizar el ROI (retorno de inversión) del proyecto. Conclusión Scrum es un framework para trabajar colaborativamente en equipo, y obtener el mejor resultado posible de un proyecto. Nos ayuda a identificar situaciones en las que no estamos realizando incrementos del producto deseados y a acortar el tiempo en las entregas del desarrollo del producto. Con esta manera de trabajar se consiguen equipos altamente productivos y motivados. ¿Trabajas habitualmente con este marco de trabajo? ¿Te estás iniciando en Scrum?
Pasos para hacer la Daily Scrum perfecta
Qué es la Daily Scrum La Daily Scrum es un tipo de reunión que existe en la metodología Scrum y que tiene bastante importancia en el desarrollo completo en un proyecto. Es una reunión diaria y muy breve, no debe superar nunca los 15 minutos, que van a tener todos los miembros del equipo, que básicamente para lo que sirve es para saber cómo va cada miembro del equipo. La Daily Scrum está pensada principalmente para responder a tres preguntas, es decir, cada miembro del equipo tiene que responder a tres preguntas, que serían las siguientes: ¿Qué hice ayer? ¿Qué es lo que voy a hacer hoy? ¿He tenido algún tipo de problema durante el desarrollo o si tengo algún problema? Esas son las tres cosas que debe decir cada miembro del equipo, por lo que para un equipo de Scrum, que debe tener entre 3 y 9 personas, en 15 minutos da tiempo más que suficiente para detallar simplemente esas cuestiones. Consejos para la Daily Scrum Muchas veces en la Daily Scrum ocurre que cuando alguien plantea un problema, se empieza a intentar solucionar el mismo, o bien el Product Owner decide hacerlo de otra forma, por lo que la reunión se va alargando. Para evitar que pase esto, lo que debemos hacer es acabar la reunión a los 15 minutos o cuando cada uno haya respondido a esas tres preguntas, y fijar otra reunión más adelante para tratar el problema que se haya presentado, ya que la Daily Scrum tiene otros objetivos. Otros consejos que se recomiendan seguir son los siguientes: Realizar la misma siempre en el mismo lugar para que el equipo esté habituado al mismo. Normalmente se realiza delante del tablero Kanban, para así poder ver cada uno el avance de cada uno de los compañeros. También es aconsejable hacerla a la misma hora todos los días. Deben estar moderadas por el Scrum Master, es quién debe preguntar a cada uno de los miembros del equipo y actuar en consecuencia, es decir, dar a cada uno de ellos ideas para solucionar los posibles problemas, indicarles si una tarea debe ir más rápida, etc. Es aconsejable que en la Daily Scrum esté todo el equipo completo, ya que si no es así las personas que no asisten no saben cómo va el proyecto y lo ideal es que todo el mundo esté bien informado sobre eso. Como ya hemos comentado antes, es muy importante enfocarnos únicamente en responder a esas tres preguntas anteriores. Otras tareas que podemos realizar en la Daily Scrum Un ejemplo de esto sería un miembro del equipo que tiene una tarea asignada de 7 horas de duración. Al llegar a la Daily Scrum le dice al Scrum Master que el día de ayer estuvo haciendo esa tarea durante 5 horas y no se encontró ningún problema. Entonces el Scrum Master refleja esas horas de avance en ese gráfico de avance o burn-down. Los resultados de hacer lo anterior es que tendríamos el gráfico de avance actualizado y además la identificación de posibles problemas, para que luego podamos agendar una nueva reunión para solucionar esos problemas. ¿Te fue util esta información ? escríbenos te leemos
Los 3 Hostings que No Conocías ¡Gratuitos sin Publicidad!
He rebuscado por todos lados y no he encontrado ninguno que cumpla con las 3 características imprescindibles que debe tener un hosting para mí. Dicho esto, paso a recomendarte los 3 alojamientos webs gratuitos con mejor pinta del mercado actual. 000webhost Completamente gratuito, en inglés y sin WordPress instalado. Puede servirte para probar cómo quedaría tu web montada una vez instales WordPress. Llévame a www.000webhost.com Award Space De nuevo, nos encontramos con un servidor en completo inglés con un plan básico completamente gratuito en el que te dejarán subir hasta 1GB de información a la web. Llévame a www.awardspace.com x10hosting Y como tercer opción o alternativa de pruebas, puedes usar este alojamiento web gratis sin publicidad. Llevan más de 10 años dando servicios, lo que la convierten en una de las opciones más fiables. Llévame a www.x10hosting.com
No te quejes, resuelve.
Hay personas que se quejan de todo. Para ellos cada situación representa un problema y nunca una solución. La queja es una manifestación de impotencia. Sin embargo, la queja es una conducta aprendida, un hábito que, como tal, puede desactivarse y modificarse. Quejarse es fácil, resolver es difícil. Resolver es para profesionales. [Durante el transcurso de un partido] «el atacante pega afuera porque la pelota está mal armada. Entonces le reclama al armador, diciéndole que quiere la pelota más alto y más cerca de la red. […] El armador gira y, al ser un juego de equipo, reclama a los receptores que le pasen la pelota en forma precisa. Porque si el armador no recibe correctamente, no puede armar la pelota para que el atacante la reciba como pretende. El armador dice: el atacante la tira afuera porque yo no se la doy como él quiere y eso sucede porque ustedes reciben mal. […] En ese momento los receptores giran para ver en quiénes pueden descargar la culpa… pero no hay nadie a quien culpar. Los receptores reciben el saque adversario. Por consiguiente, no pueden decirle al rival que saque despacio para que ellos puedan recibir bien». Para conseguir un mejor resultado, la queja no sirve. Esto hay que resolverlo. «Los atacantes no hablan del armado, sino que lo resuelven. No juzgan el armado, lo resuelven. […] Si no eliminamos la queja, los atacantes hablan del armado y no del ataque. Se convierten en expertos del armado, hablan del armado en el bar, en el vestuario, en todos lados. Pero el problema es que ellos atacan, no arman» «Yo quiero atacantes que le peguen bien a pelotas mal armadas. Para que luego puedan pegar excelente, pelotas bien armadas. Entonces, no hablemos. Resolvamos. […] Si la realidad es como es y no como yo quiero que sea, entonces cuando reciba una pelota mal armada, la resolveré bien. No resuelvo una pelota mal armada de la forma en que resolvería una pelota bien armada. Porque si así lo hiciera, no sería un buen jugador. Resuelvo la pelota mal armada como debo hacerlo y resuelvo una pelota bien armada como debo hacerlo… y ambas formas son distintas». Interpretar la situación de juego, elaborar una respuesta para esa situación y luego responder bien, técnicamente, es lo que representa el «jugar bien». Esto aplica a todas las circunstancias de la vida. Interpretar la situación, elaborar una respuesta para esa situación y responder correctamente, es lo que identifica a un buen jugador, a un buen profesional, a un buen ciudadano. Dado que la realidad habitualmente difiere de cómo queremos que sea y dado que por lo general nos encontramos con personas y profesionales que «juegan mal» —es decir, que interpretan y/o responden incorrectamente a lo que se les pide— lo más fácil es quejarse. Pero la queja no sirve, es inútil, es comportamiento de bajo desempeño. Y si su comportamiento manifiesta bajo desempeño, usted no puede decir que es una persona de alto desempeño. Cuando cambiamos la queja por la acción, modificamos nuestro enfoque. Convertimos la sensación de impotencia en capacidad de resolver, mediante la toma de control de la situación. Convertimos aquello que no controlamos en controlable. Y al convertirlo en controlable, podemos actuar. Dejamos de lado la creencia en impotencia para empoderarnos. No se queje, resuelva. Quejarse es fácil, resolver es difícil. Por eso, resolver es para profesionales. ¿Qué te pareció? <¡Escribe tu opinión ahora!
La protección de las marcas se obtiene mediante el registro, y en algunos países, también a través de su utilización. Aún cuando las marcas puedan protegerse a través de su uso, es recomendable registrarlas presentando la solicitud apropiada en la oficina nacional de marcas (algunas oficinas de marcas disponen de mecanismos de solicitud de registro en línea).
Marcas prefieren apps para hablar con sus clientes
En Colombia, WhatsApp ya cuenta con una penetración del 67% de los usuarios móviles según Merca 2.0 y, de acuerdo con un estudio de Tigo Une, es la segunda aplicación más usada por los colombianos con un tráfico de 14,23%. En Infobip, hemos sido testigos del impresionante crecimiento del número de empresas que están utilizando WhatsApp para comunicarse con sus clientes y prevemos que esta tendencia continuará. Así mismo, las apps tienen interfaces mucho más dinámicas que dan la facilidad a las marcas de innovar en diseño e interacción. Especialmente en campañas específicas que pueden ir ligadas a mensajes push o de geolocalización y que le den la oportunidad al usuario de interactuar con la aplicación de forma diferente y única. El liderazgo de las aplicaciones no solo en el mundo móvil sino también en el mundo digital está dando un precedente de como deberán comportarse las marcas con sus usuarios. La personalización, respeto, rapidez e innovación harán parte de las nuevas tendencias de comunicación en el marketing y servicio al cliente.
¿Qué es ser un diseñador UX?
Luego de leer decenas de definiciones, creo que lo más sencillo es resumir una definición de UX como: La UX ( User Experience en inglés para «Experiencia de Usuario») es la ciencia de comprender el contexto para mejorar la efectividad. En los primeros días de la web solo había diseñadores. Estos individuos multidisciplinares diseñaban páginas, las estructuraban con tablas HTML, creaban la base de datos y programaban el CMS (si lo había). En esa época era factible hacer todos estos trabajos porque el campo de conocimiento era bastante limitado entonces, y por lo tanto, los resultados eran bastante básicos. El campo del conocimiento creció, los sitios se volvieron más complejos, y empezaron a surgir nuevas funciones. En primer lugar las funciones se dividieron entre el diseñador y el desarrollador. Entonces los sitios empezaron a demandar back-ends1 mucho más complejos, y así surgieron los arquitectos de base de datos, administradores de sistemas, arquitectos de sistemas y una gran cantidad de papeles secundarios. Del mismo modo el front-end (lo que ve el público) dio lugar a la especialización en diseño de la interfaz, diseño de movimiento y, más recientemente, el diseño de experiencia del usuario. El diseño de experiencia de usuario implica una serie de actividades (investigación, arquitectura de información, diseño de interacción, etc.), así como un puesto de trabajo por derecho propio. Para proyectos más pequeños es perfectamente factible para una sola persona planificar la arquitectura, dibujar wireframes, diseñar la interfaz, e incluso código de las páginas, de la misma manera que sería factible para un constructor único planificar y construir una extensión de su propia casa. Sin embargo, cuando un proyecto se vuelve más complejo necesita de personas con más experiencia. Así como los grandes proyectos de construcción exigen aparejadores, delineantes, arquitectos, interioristas, diseñadores de señalización y toda una serie de otros expertos, los mismo sucede con los sitios web y, desde hace relativamente poco, con las apps (aplicaciones). Hace 10 años estas nuevas especializaciones que surgen hubieran resultado una exageración, pero hoy están siendo aceptadas. Sin embargo, ¿por qué alguien necesitaría un título pretencioso como «Arquitecto de Información»? Hay una gran diferencia entre pasar un par de días trabajando en wireframes para un proyecto y pasar meses realizando prototipos y pruebas de una aplicación compleja, con cientas de interacciones. Tal vez por eso, los diseñadores web expecializados en la experiencia del usuario se identifican a sí mismos como profesionales UX. Pero también existe un número creciente de profesionales que se sienten en la libertad de utilizar esa misma denominacion, porque apenas han esbozado algunos wireframes y han realizado un par de pruebas de usabilidad. Para definirse como profesional UX se necesita una comprensión profunda de la psicología cognitiva, la interacción persona-ordenador y diseño de investigación. Es decir, mucho más que solamente manejar bien la parte gráfica. Se necesita tener experiencia en el manejo de entrevistas a usuarios finales, evaluaciones de usabilidad y estudios etnográficos. Un profesional UX es más versado en la creación de personajes, modelos conceptuales, escenarios, flujos de usuario y story boards. Es capaz de crear wireframes y prototipos con el uso de una amplia gama de herramientas. ¿Qué perfiles encajan en la carrera profesional de UX? Se debe establecer la diferencia entre un experto UX y un diseñador o creativo UX. Un representante de recursos humanos de una empresa francesa, me comentó recientemente lo difícil que le resulta encontrar perfiles UX analíticos, más que creativos. Hay roles estratégicos que todos los profesionales UX deben desempeñar, sin importar sus títulos o cómo y dónde sea el contexto en el cual trabajan. Una persona no tiene por qué asumir todas estas funciones, pero cada uno de nosotros debe jugar al menos una de estas funciones, la que le resulte más afín. Las funciones y responsabilidades en la experiencia del usuario dentro de una organización pueden ser las siguientes: Educador: Las responsabilidades de la función educadora incluyen tutoría dentro de la profesión UX. Por ejemplo, escribir y hablar en las conferencias. Innovador: Los profesionales UX desempeñan un papel innovador mediante la implementación de diseños que muestran a los demás lo que una gran experiencia de usuario puede llegar a ser. Disruptor: La «disrupción» es una forma más radical de la innovación. Los profesionales UX que asumen el papel disruptor, logran que las cosas cambien a un ritmo más rápido. Partner: Los profesionales UX que ejercen un papel de partner (socio) deben establecer alianzas con otros profesionales afines, tanto en la parte académica y como en la práctica. Las funciones que los profesionales UX pueden asumir no se limitan a estas cuatro. Se trata de una profesión multi-disciplinar, por lo que conviene caer en la construcción de límites estrictos. En lugar de eso, es mejor crear puentes con otras disciplinas. Definamos una serie de términos en el argot UX/UI. Bien podrían ser ramificaciones de un tronco general de lo que es ser un diseñador de experiencia de usuario y las podemos incluir dentro de los cuatro roles mencionados: User experience designer (DIseñador de experiencia de usuario) Information architect (Arquitecto de información) User centred design (Diseño centrado en el usuario) User testing (Evaluaciones de usuario) Usability expert review (Experto en auditorías de usabilidad) User experience specification (Especificación de experiencia de usuario) Personas, user journeys, and task based design (Personas, flujo de usuario y diseño basado en tareas) ¿Dónde puede aplicar un entusiasta o profesional de UX sus conocimientos? Está muy mal comprendido el alcance que tiene la aplicación de conocimientos de UX hoy en día. Se piensa que solo grandes empresas pueden pagar por un profesional que reuna alguno o algunos de estos perfiles, que sepan llevar los roles mencionados. Un artículo sobre el tema publicado Smashsing Magazine en 2010 identifica las áreas de mercado que pueden sacar el máximo provecho de los profesionales de experiencia de usuario: Sistemas complejos: Cuanto más complejo el sistema, más complicada será la planificación y la arquitectura. Los sistemas que involucran una gran variedad de tareas del usuario debe ser percibidos como algo valioso, agradable y eficiente. Dejar de lado la experiencia del usuario definitivamente te va a llevar al «no éxito». Start Ups: En general estos modelos de negocio no tienen los recursos para contratar a empleados dedicados exclusivamente a la UX, pero sí pueden contar con algún perfil sólido que sea capaz de ser un «líbero» en la organización. Por ejemplo un desarrollador que tenga mucho interés en la usabilidad o un diseñador que sea apasionado por el diseño centrado en el usuario. En este contexto la formación uno o más miembros del equipo en cursos o congresos puede ser de gran ayuda. Proyectos con presupuestos ajustados: Es cierto que las empresas medianas y pequeñas no pueden jugarse una cuenta por intentar incluir en el presupuesto un apartado de investigación UX, pero contar con modelos básicos y enfocados a la construcción de la mejor solución, más que un producto final, es seguro se beneficiarán de la aplicación de conceptos de UX. Proyectos de largo plazo: Por simple lógica, sumar una pieza al proceso de producción tradicional extenderá la línea de tiempo. Ese tiempo puede ser asignado para diseñar la UX. Como se ve, no se necesita ser un gurú de la UX trabajar en el tema. Lo cierto es que hay gran avidez de profesionales hoy en día y no existen suficientes para cubrir las necesidades. Qué cosa no es UX y qué no te hace ser un profesional de la UX La denominación «UX/UI designer» abunda en cientos de perfiles de personas que entienden que son profesionales de experiencia de usuario. He visto en infinidad de blogs comentarios sobre UX que están haciendo únicamente alusión a un excelente trabajo de «pixel perfect» o a un muy bonito efecto en jQuery. Incluso se habla de UX únicamente en relación a la usabilidad de la interfaz. No es correcto. A quienes se ha formado en comunicación, HCMI (Human Machine Interaction en inglés para “Interacción Hombre Máquina”)o diseño, les resultará sencillo convertirse en diseñadores UX. Pero hay que tener claro que la experiencia de usuario no pasa únicamente por el diseño visual o gráfico, sino que es mucho más. Por ejemplo, se necesita conocer las preguntas correctas que es importante que sean respondidas antes de que el proyecto comience (o antes de que el profesional se involucre en él). Se debe comenzar el trabajo con reuniones efectivas, objetivos claros y los puntos que hayan sido aprobados bien entendidos por todos. Se deben definir los requerimientos del proyecto sin ambigüedades. Se debe conocer al usuario destinatario y representar sus necesidades a través del proyecto, siendo capaz de elegir y utilizar las herramientas y técnicas que permitan mostrar las ideas al equipo de trabajo de forma visual. Se necsita estar seguro de que el sitio o aplicación sea fácilmente ubicable por usuarios y motores de búsqueda, y finalmente comunicar y evolucionar el diseño con el equipo una vez que el desarrollo comienza. Como puede observarse, la cosa es más compleja de lo que se suel pensar. No debes considerarte un diseñador de experiencia de usuario si: No hablas con los usuarios. No puedes identificar tu público objetivo. No defines el problema antes de intentar resolverlo. No puedes articular los objetivos de los usuarios. Diseñas para tí. Tomas decisiones de diseño basado en tus experiencias personales. No se tienen en cuenta los objetivos de negocio. No utilizas métodos UX. No diseñan para diferentes condiciones y casos extremos. Sólo piensas en la interfaz. Como dice Whitney Hess2 en el blog Mashable no debes considerar a la UX como: Diseño de interfaz de usuario. Un paso en el proceso. Algo acerca de la tecnología. Solo de usabilidad. Únicamente sobre los usuarios. Cara. Fácil. El papel de una persona o departamento. Una sola disciplina. Una elección. Tomado de https://foroalfa.org/