[User Experience] Un poco de User Experience Design (Parte 2)

En la parte 1 de este artículo presenté la diferencia entre UX y UI, qué es UX Design y mostré el 1ero de 4 pasos del proceso para el diseño de interfaces propuesto en [1] (Figura 1). En este nuevo post continuaremos explicando los demás pasos.

Figura 1 –4 step design process (imagen basada en [1])

En el curso de [1] en cada momento nos dice que debemos tener en mente el concepto principal de User Experience Design:

¡Los usuarios utilizan interfaces para cumplir una tarea!

Dicho esto, seguimos  …

Paso 2: Design Alternatives ( “Diseño de alternativas” )

Para dar inicio a este paso, debemos ya tener claro cuál es el espacio del problema (problem space): es decir ya sabemos quiénes son nuestros usuarios, cuáles son sus objetivos/metas y la forma actual en la que desarrollan sus actividades. De esta forma, estaremos listos para utilizar esta valiosa información y desarrollar varias opciones de diseño que mejorarán la experiencia de nuestros usuarios (UX). Es el momento de “Pensar más alla” o … Thinking outside the box; y aquí haremos un breve paréntesis de este paso 2, porque considero que es importante entender este concepto de “ir más alla”

Significa poder responder: ¿Cómo unes los 9 puntos de la Figura 2 con máximo 4 líneas sin levantar el lápiz del papel y sin pasar dos veces por el mismo punto?:

Figura 2 – Reto de los 9 puntos

  • ¿¡Qué!? No, no se puede Pamela
  • ¡Claro que sí! Intenta hasta la solución que parezca más descabellada. ¿Ves?

Leer más

[User Experience] Un poco de User Experience Design (Parte 1)

En nuestra empresa LiOnline tratamos a nuestros clientes de forma personalizada y entendemos que sus clientes son lo más valioso que tienen y por tanto los productos y/o servicios que les entregan deben satisfacer sus necesidades a través de la mejor experiencia de uso (Experiencia de usuario – UX).

¿UX? (El famoso ‘iuex‘) ¿Qué es? Particularmente, empecé a escucharlo muchísimo estos 3 últimos años y una definición sencilla es: Cómo el usuario se “siente” o qué “impresión/percepción” recibe cuando usa un producto y/o servicio. Este término fue acuñado por Don Norman [11].

y UI (User Interface o Interfaz de Usuario) es cómo nuestro producto se ve, es decir la apariencia física o diseño visual (look & feel) con la que el usuario interactua.

Antes de entrar al objetivo del post el cual es explicar un poco sobre el “Diseño de Experiencia de Usuario (User Experience Design), me gustaría dejar en claro la diferencia entre UX y UI por medio de un ejemplo:

La evolución de la botella de Ketchup de Heinz
Henry J. Heinz diseñó la botella con un objetivo claro “la pureza mediante la transparencia”, así los compradores podían ver el estado de la famosa salsa de tomate [7].

Yo era niña cuando vi por primera vez dicha botella y recuerdo que me pareció muy elegante y fina. Lamentablemente pasé de la admiración a la frustración en segundos: ¡Cómo saco ketchup! ¡Papá, ayúdame, no sale nada!. Y para él también no era una tarea fácil y así para muchas personas más en el mundo. ¿Qué estamos haciendo mal?, según Heinz existe una forma correcta para hacerlo [5][6].

Es decir a pesar de tener un envase de ketchup con buena apariencia (UI), la experiencia de echar ketchup a las comidas para la mayoría de consumidores era muchas veces frustrante (UX) y no conseguir realizar dicha tarea de forma intuitiva es una señal de que “se debe mejorar” el diseño. Y así fue, surgió la versión de plástico con un diseño diferente que facilitó la vida para muchos y me incluyo. (Ver figura 1)

¡Ojo! Es cierto que al día de hoy aún existen consumidores que prefieren usar la clásica botella con el método de Heinz. Además, hay un factor que actualmente las empresas deben considerar en sus productos: “La preservación del ambiente” y definitivamente un envase de plástico va en contra de ello.¡He ahí un reto más para las empresas! [8]

Figura 1 – Definición de UI/UX (imagen de [2])

Sabiendo ya la diferencia, surge la pregunta: ¿Cómo logramos crear una buena experiencia de usuario?

Empecemos …

Resultado de imagen para KEEP CALM AND UX

Leer más

[Tip] ¿Cómo hago para elegir un software adecuado?

Creo que en algún momento, todos hemos pasado por la difícil decisión de elegir un software para resolver una determinada tarea (desde un básico calendario hasta un complejo software de desarrollo de aplicaciones web). Hoy en día, tenemos muchas opciones disponibles en el mercado para cualquier tarea y entre tantas ¿cuál debería seleccionar?

Resultado de imagen para pensando gif

Me gustaría comentarles cómo suelo buscar y decidir la mejor opción

Leer más

[SCRUM] Daily Meeting y demás comunicaciones con Slack

En artículos anteriores he hablado sobre qué es Scrum, cuáles son sus principios, aspectos y procesos, cómo certificarnos como Scrum Master y más.

De qué trata una Daily Standup Meeting?

Hoy me gustaría comentarles sobre Daily Scrum o Daily standup meeting que como recordarán forma parte del principio “Timeboxing” o “Bloque de tiempo asignado“. La productividad de un equipo ágil se logra usando el tiempo de forma eficiente, es por ello que el principo deTimeboxing es uno de los más críticos pues permite que el equipo se mantenga enfocado en el cumplimiento de sus tareas en el tiempo asignado.

Figura 1 – Timeboxing [3]

Específicamente para la Daily Scrum el tiempo asignado es de 15 minutos por cada 24 horas. En esta reunión cada miembro del equipo, uno por vez, debe responder las siguientes 3 preguntas:

  • Qué hiciste ayer?
  • Qué harás hoy?
  • Cuando crees que terminarás esa tarea? (opcional)
  • Existe algún impedimento/obstáculo para la realización de tus tareas?

Haciendo esto promovemos la transparencia: Todos sabemos en qué andamos y si tenemos o no algún problema (que no es solo del tipo “tengo X bugs en mi código”. En [1] encontramos ejemplos de impedimentos:

  • Mi computadora tuvo un problema y necesito un día más
  • Aún no llego el software/hardware/programa que pedí hace un mes
  • Me gustaría aprender ___________ y para ello me gustaría trabajar en par con fulanito (el famoso programming pair
  • El jefe del área X me ha pedido apoyarlo “por uno o 2 días”

El Scrum Master es el responsable de resolver dichos impedimentos. En aquellos de tipo técnico en donde el Scrum Master no puede resolverlos directamente, él deberá asegurarse de encontrar alguna persona (ya sea del equipo o externa) que pueda ayudar a resolver ese problema rápidamente.

Recomiendo la lectura de [4][5] para conocer qué es lo que NO debemos hacer en la ‘daily‘ y más tips.

 

Leí que la daily tiene que ser presencial, el primer evento del día de trabajo, todos de pie y sin discusión. ¿No es un mundo ideal?

Déjame decirte que sí y pues somos humanos y vivimos en un mundo real. El artículo [6] empieza diciendo “Vamos a ahorrar tiempo, evitemos esta ‘ceremonia’ [daily], es demasiado antiguo!” y cuando empecé a leerlo me sentí identificada con los problemas que surgen de la forma tradicional de conducir una daily.

Y no es que la daily tradicional exija que sea presencial, puede ser hasta por videocámara pero algunas veces sucede que aún asi no se da de la forma que esperamos y podría hasta ser contraproducente. Les contaré algunos de los problemas que percibí cuando empecé a participar de dailies:

  • Las dailies eran programadas a las 9am y hay que decirlo el tráfico de Lima (y la ‘hora peruana’) no permitía que empezáramos a esa hora o si empezaba no estábamos todos al inicio ¿que ocurría entonces?: Algunos miembros perdíamos lo que se había dicho pues no había un registro (y pues tener una persona para redactar una acta de reunión diaria es con certeza improductivo)
  • Otro problema era que la reunión podía durar más de 15 minutos. Porque sin querer o queriéndolo empezábamos a discutir y analizar las respuestas en ese momento y la daily no es para eso.
  • Algunos miembros podíamos no estar interesados en escuchar en ese momento a los demás: ¿imagina que eres el último en responder las preguntas?. ¿no te sentirías aburrido?. No voy a mentir, sí a veces.

¿A que hora empezábamos el trabajo real?: 9:30 o 9:40. ¿Cómo podría hacer más eficiente una daily?. Porque ¡ojo! doy fe de los beneficios de una reunión diaria.

Actualmente estoy utilizando Slack como medio de comunicación y colaboración con mi equipo de trabajo. Al inicio me parecio que era whatsap para empresa. Luego de casi 1 año de usarlo, lo ¡recomiendo fuertemente!. Inclusive realizamos nuestras dailies en Slack gracias a un bot llamado Limitbot.io

Cómo funciona Limitbot como daily? (sin detalles técnicos)

  • Configura las 3 preguntas indicadas líneas arriba
  • Configura el horario en que avisará a cada miembro del equipo para responder las preguntas del paso anterior
  • En el horario indicado, Limitbot enviará una notificación como por ejemplo “Hello Pamela! It’s time for our standup meeting *Standup*. When you are ready please answer the following question:”
  • Es hora de responder una a una las preguntas. Al finalizar el pequeño cuestionario, las respuestas son almacenadas en un “channel” (equivalente a un grupo) que podríamos llamar #dailies.
  • Ese channel estará disponible para todos en cualquier momento: ¡cumplimos con la transparencia!. El Scrum Master podrá revisar las respuestas y buscar soluciones a los impedimentos registrados.

Figura 2 – Preguntas configuradas usando Limitbot  [3]

Probablemente te preguntarás ¿no va en contra de lo que dice Scrum?. No me condenen por favor, yo concuerdo con [7][8]: me libré de una reunión jeje.

Resultado de imagen para happy inside out gif

Tú que opinas? estás a favor de las dailies tradicionales o te animarías por alguna herramienta como um bot de Slack? 🙂

Referencias

[1] Daily Scrum Meeting – Mountain Goat

[2] 21 Ways to Use Slack Bots to Simplify Everyday Tasks

[3] What is timeboxing?

[4] Daily Scrum meeting: tips

[5] Scrum Daily Meeting 

[6] What if we do daily scrum stand-up over slack?

[7] Limitbot.io

[8] Stop the meeting madness

Imagen principal del post tomada de [5]

[Front y Back End] Node.js y NPM

El desarrollo web ha evolucionado a pasos agigantados. Me gustaría empezar con una anécdota sobre ello: A inicios del año pasado, 2017, me reuní con 2 grandes amigos de la universidad y me comentaban sobre tecnologías como Node.js, Angular, React y hablar sobre la tendencia de ejecutar “Javascript en el lado del servidor”. 

Pensé, bueno es hora de …

Así que empecemos … ¿qué es Node.js?

Node.js fue creado en el año 2009 y con ello cambia el concepto de JavaScript pues éste pasa de ser un lenguaje para desarrollo web exclusivo del lado del Front-End (lado del cliente) para ser utilizado también en el Back-End (lado del servidor) [5]

Node.js es un entorno de ejecución en el cual los programas escritos en JavaScript son compilados, optimizados y finalmente interpretados por la máquina virtual V8 de Chrome, la cual es la misma que usa Google para ejecutar JavaScript en su navegador Chrome [1] [2]. Su modelo de operaciones E/S (entradas y salidas) sin bloqueo y orientado a eventos lo hace liviano y eficiente [7].

En [1] nos dice que el uso principal de Node.js está en la construcción de APIs pues su modelo asíncrono, que trabaja con un único hilo (thread) consume pocos recursos del hardware.

¿Modelo de operaciones sin bloqueo, asíncrono? ¿Qué es eso? continuemos 🙂

Leer más

[Front End] Mundo JavaScript en 2018

En enero 2018, estuve comparando 2 tecnologías para desarrollo web del lado Front-End: la librería JavaScript “React” y el lenguaje de programación “ELM” que genera código JavaScript. Para dicha comparación revise diversos artículos y cada uno de ellos me dejaba más preguntas (existían conceptos que no conocía o había olvidado) que respuestas.

¡¿Cuánto ha evolucionado JavaScript?! ¡Dios!¿Cuántas herramientas? No voy a tener tiempo para aprender todo!  – pensé 

… JavaScript posee un gran ecosistema de librerías, frameworks y herramientas que cambian rápidamente y es casi imposible mantenernos siempre actualizados. Es por ello que durante la elección de tecnologías JavaScript para nuestros proyectos webs podríamos sufrir de:

 “JavaScript Fatigue”

Sofocación/Ahogamiento por conocer varias tecnologías y no saber por cual empezar

Tengo algunas preguntas para empezar este post: ¿Qué nos está trayendo JavaScript 2018? ¿Aún debería utilizarlo? ¿Si hay tantas opciones, cómo voy a elegir la mejor?. En el video de [1] y el artículo [6] pude encontrar algunas respuestas.

Leer más

[SCRUM] Ser Scrum Master Certified y ¡no morir en el intento! (Parte 2)

En la parte 1 de este artículo, mencioné donde encontrar los recursos/material de preparación para los exámenes Scrum Fundamentals Certified (SFC)  y Scrum Master Certified (SMC) disponibles por la empresa SCRUMstudy, bajo la cual yo me certifiqué. Durante mi revisión de artículos para la elaboración del presente, me encontré con algunas preguntas para certificación como Scrum Master que me parecieron “extrañas” pues utilizaban algunos términos diferentes a los que había aprendido con el SBOK, fue ahí que recordé que existen 3 grandes empresas certificadoras de Scrum:

  • SCRUMstudy
  • Scrum.org
  • Scrum Alliance

En el artículo de Scrum Alliance vs SCRUMstudy se muestra un cuadro comparativo de ambas empresas. Uno de los puntos que concuerdo con dicho artículo totalmente es que un verdadero Scrum Master (sin importar por cuál empresa obtuvo su certificación) podrá responder a qué se refiere el Manifiesto Ágil: “Hemos llegado a valorar …:

  • A los individuos y su interacción, por encima de los procesos y las herramientas.
  • El software que funciona, por encima de la documentación exhaustiva.
  • La colaboración con el cliente, por encima de la negociación contractual.
  • La respuesta al cambio, por encima del seguimiento de un plan.”

Dejando ese punto en claro, seguiré enfocada en el Scrum Master Certified (SMC) de SCRUMstudy.

Leer más

[SCRUM] Ser Scrum Master Certified y ¡no morir en el intento! (Parte 1)

Entre los días 1 y 2 de julio de 2017 llevé un Curso Oficial de Scrum en el Instituto Gesap en Lima y cuya experiencia relaté en un post anterior.

Para recordar qué es Scrum: Es uno de los métodos ágiles más populares. Es un framework adaptable, iterativo, rápido, flexible y eficaz, diseñado para ofrecer un valor considerable en forma rápida a lo largo del proyecto [1]. Así que vale la pena aplicarlo en la gestión de nuestros proyectos.

Figura 1 – Flujo Scrum para un sprint (SBOK)

El objetivo de este post es sugerirte material para que inicies su aprendizaje de Scrum para luego estar preparado para rendir el examen de Scrum Master Certified. Quizás te estés preguntando ¿debería certificarme? Personalmente te recomendaría que

¿Por qué?

Actualmente, en el mercado laboral, tanto en Perú como el mundo, existe una demanda de profesionales certificados en Scrum, pues ellos ayudarán a las organizaciones a obtener un mejor nivel en la gestión de proyecto y por tanto incrementar el indicador ROI (Retorno de la Inversión) [2].

Les voy a contar un poco de mi experiencia durante mi búsqueda de trabajo en Lima – Perú. Luego de participar del taller de Scrum, inicié mi búsqueda de puestos de trabajos que envolviera Scrum. Encontré que las principales empresas del Perú estaban/están optando por un enfoque ágil y por tanto requerían de profesionales con la misma visión y con conocimientos de Scrum. En algunos casos como requisito “deseable” y en otros como “obligatorio”. Admito que perdí posibles oportunidades por no certificarme. ¡Ahora ya no! … ¡y tú tampoco!

Leer más

[Front End] Creación de ícono personalizado – ¡Estilo Fontawesome!

¿Qué se te viene a la mente al ver estos íconos?

Seguramente, ya los has visto en alguna página web y reconoces su significado sin importar si tu idioma es el español, inglés o chino, debido a que los íconos se han convertido en un lenguaje universal. Con un simple ícono, representación visual simbólica de un objeto u concepto, nos ahorramos explicaciones largas e innecesarias. Además, si te encuentras en un sitio web, los íconos te facilitan la navegación [5][7].

Ejemplo: El famoso ícono de la “lupa” nos indica que iniciaremos una búsqueda.

En LiOnline buscamos diseñar sitios web enfocados en obtener una positiva experiencia del usuario y los íconos nos ayudan en ello pues hacen que las interfaces sean más intuitivas y amigables es decir de fácil entendimiento por parte de los usuarios.

El sitio web de nuestro cliente BYC Grupo Inmobiliario, empresa de venta/alquiler de propiedades, cuenta con íconos que representan las características que posee una propiedad:

  • Número de habitaciones – ícono de una cama
  • Número de baños – ícono de una ducha
  • Cantidad de fotos disponibles para esa propiedad – ícono de imagen
  • Metros cuadrados – ícono de un plano.

Imagen 1 – Sitio web de nuestro cliente ByC

Imagen 2 – Propiedad en Venta de ByC

Luego de haber entendido qué son los íconos y porqué son importantes, nos moveremos a ¿cómo los implementamos (creamos) en un sitio web. Antes del 2014, los íconos estaban en  *.jpg, *.png u otro archivo de imagen. Siguiendo el ejemplo de ByC, entonces podíamos tener un archivo “cama.png”, o “ducha.png”. ¿Qué problemas nos trae trabajar los íconos como archivo de imagen?

  • La solicitud de mútiples imágenes al servidor, hace que el sitio web se cargue lentamente.
  • Las imágenes pierden resolución/nitidez al aumentar su tamaño
  • Al tener un ícono en imagen, no es posible modificar, por ejemplo, el color. Había que crear la misma imagen pero con diferente versión de color.
  • No se pueden animarse las imágenes fácilmente.

Por tanto, definitivamente utilizar un archivo de imagen para un ícono no era una buena solución [1][4]

Veámoslo de forma gráfica: En la imagen 3, tenemos un ícono de “casa” (no es un archivo imagen) y un ícono de “regla” (archivo tasacion.png), con un zoom adecuado ambos se ven con buena resolución. ¡Ok!

 

Imagen 3 – Íconos para representar los servicios de  ByC

Sin embargo, hagamos un zoom ++++, ¿qué ha sucedido? en la imagen 4, vemos que la “casa” ha mantenido su resolución a pesar de haber aumentado de tamaño, algo que no sucede con la “regla” la cual vemos borrosa.

Imagen 4- Ícono en imagen vs Ícono en icon-font

Por suerte, hoy tenemos una solución para eso: “Icon Font”, el ícono de la “casa” es de ese tipo.

¿Qué es un Icon Font? ¿Cómo lo utilizo? ¿Puedo crear mi propio ícono?, ¡aquí responderemos esas preguntas!

Leer más

Mundo y mente sin fronteras: Pensamientos de una inmigrante

Joven (brasileño): Hola, disculpa soy nuevo en esta ciudad, ¿Podrías indicarme un buen lugar para comer?

Yo: Hola. Sí claro (le doy las indicaciones)

Joven: Qué lindo acento, ¿de donde eres?

Yo (sonrío): Soy de Lima, Perú

Joven (intenta hablar en español): Yo conozco Lima y Cuzco, todo muy bonito.

Yo (en español): Qué chévere, Cuzco es una de las ciudades más turísticas en Perú. (…) Disculpa, ¿entendiste mis indicaciones?.

Joven: Sí claro, hablas bien portugués. Muchas Gracias

Barão Geraldo – Campinas – São Paulo – Brasil

Quise empezar este artículo con esa pequeña conversación real que sucedió el último día de Julio 2018 en Campinas – Brasil, para demostrar lo enriquecedor que es compartir experiencias de nuestras culturas. ¡Qué orgullo decir que soy del Perú en tierras extranjeras!

Aprendí amar a un país que me acogió desde hace unos años: Brasil. Su idioma, su música, su arte, su naturaleza, sus tradiciones y especialmente su gente que siempre me trató con respeto, amabilidad, cariño y me dio la mano cuando lo necesitaba, hicieron que poco a poco Brasil se volviera un “hogar”. ¿Será que este trato al extranjero es el mismo en cualquier otro país? ¿ … en mi país, Perú?

No, decepcionada digo no.

Leer más

1 2 3 5