Cómo saber si eres un ‘UX Chamuller’ (y qué hacer para dejar de serlo)

Chamullar (verbo). El acto de adornar oraciones con elementos innecesarios.

He aquí una lista de lo que he conseguido en mi vida gracias a chamullar:

  • Escapar de una paliza
  • Colarme en un concierto,
  • Conseguir pareja
  • Terminar la secundaria
  • Viajar sin documentos
  • Hacer que el primer párrafo de mi artículo fuera una lista para así parecer un redactor con recursos literarios. BOOM.

En general, mi relación con el chamullo ha sido buena, pero cuando traté de llevar esa experiencia al mundo digital  — y en especial al de la UX —  todo empezó a fallar.

¿La razón? Los usuarios. En un entorno cotidiano — “offline” — , los receptores de mi chamullo eran un público más o menos cautivo: tenía herramientas para retener su atención, como leer su postura corporal para adaptar mi discurso.

Entre otras herramientas más sofisticadas.

En cambio, en contextos digitales, el usuario elige qué contenido consumir y qué contenido pasarse ceremoniosamente por sus zonas más ocultas. Y, según las estadísticas, hay mucha información que termina en ese lado oscuro. De hecho, el Nielsen/Norman Group estima que, en un sitio promedio, un usuario solo lee el 20% del contenido.

Así que si quería que mi contenido entrara en la primera categoría, debía ser importante, especial, directo, y que responda a una necesidad de información.

O sea, todo lo contrario al chamullo.

Pero ¡ojo!, el ‘UX Chamulling’ va más allá de las palabras. También incluye imágenes, vídeos, colores, y demás elementos de una interfaz. Lo importante es saber detectarlo para luego evitarlo.

Y como un ‘UX Chamuller’ en recuperación, he logrado encontrar algunos síntomas, por ejemplo:

1. Utilizas frases ‘amigables’ en tus interfaces.

Entiendo tu postura, amigo UX: Quieres generar empatía y una real conexión con tus usuarios. Y para eso, utilizas frases lindas, amigables, que tocan el corazón de la gente.

Un botón tan largo no toca el corazón de la gente. De plano le atraviesa el pecho.

Como en mi caso de chamulling, apelar a estos sentimientos puede aplicarse en una conversación real, pero al trasladarse a una plataforma digital, las frases son sólo relleno. Parafraseando a Steve Krug en ‘Don’t make me think’:

Las frases amigables son como las conversaciones de ascensor: no tienen contenido, son sólo una forma de ser sociable. Pero la mayoría de usuarios web no tiene tiempo para ‘conversaciones de ascensor’, quieren ir directo a lo importante.

“Cómo apoyar a Typewolf: blablablablablablablabla”

2. Quieres diseños al estilo de Dribbble

Si la UX fuera un barrio problemático, Dribbble sería el que vende las drogas. Primero te invitaría a mirar lo que tiene, y te convence de que es lo mejor del mundo. Luego, te animaría a probarlo.

Y lo haces. Realizas tu diseño pensando en una gráfica que viste en Dribbble. A mitad de camino te das cuenta de que quizás algunos elementos no funcionan tan bien. Pero continúas. Ese es el problema con las adicciones: bloquean estas pequeñas alertas..

Tomen el ejemplo de este rediseño:

Se ve increíble y funciona perfecto… siempre y cuando vivas en un mundo en el que todos tus usuarios suben fotos profesionales con fondos simples, y donde a Facebook no le importa ganar dinero (¡ja!), pues no se han establecido espacios para la publicidad.

No tengo nada en contra de los diseños hermosos. Sí tengo todo en contra de los diseños que sacrifican funcionalidad por estética. Si estás forzando contenido para adaptarlo a tu bello diseño, estás siendo un ‘UX Chamuller’.

3. Utilizas ‘Lorem Ipsum’

Tengo un reto para ti: La próxima vez que quieras enviar un e-mail no lo redactes directamente. Utiliza primero Lorem Ipsum, y mira cómo queda. Cuando se vea bonito, ya puedes reemplazar el falso latín con el texto real que querías enviar en ese correo. ¿Te pareció una perdida de tiempo? Qué bueno, porque lo es.

Para tus diseños de webs o apps o cualquier interfaz, el resultado es el mismo: utilizar latín no te salvará de tu destino.

A diferencia de otras ocasiones en las que solo el latín te salvará de tu destino.

Y tu destino es que, eventualmente, tendrás que re-acomodar (o volver a hacer desde cero) tu diseño ‘loremipsum’ para adaptarlo al contenido real.

Para evitar esto, ningún proyecto de diseño debería empezar sin tener el contenido definido. Pero entiendo que eso no siempre es posible, y en ese caso vas a tener que redactar el contenido tú mismo.

“Pero Nico” — me dices con tu voz de dolor sit amet consectetur — “yo no sé redactar y probablemente lo que escriba sea incomprensible y terminen desechándolo”. Ah, ¿y qué pensabas? ¿Que tu cliente iba a leer tu Lorem Ipsum e iba a decir “Es exactamente lo que quería, utilicémoslo para vender mi producto, por favor”?

Si es realmente tu caso, te diría que es momento de aprender a redactar. Un UX Designer debe encargarse de brindar una gran experiencia a nivel visual, interactivo y de contenido. Si solo sabes manejar programas de diseño y esperar instrucciones, entonces no eres un UX Designer, eres un ‘chofer de mouse’.

4. Usas ejemplos que encajan perfectos en tu diseño

Tienes que crear una sección de perfil de usuario. Tu instinto UI te hace crear un card de 200 px de ancho, con una imagen de un sujeto sonriente (con lentes de carey, probablemente) y abajo un nombre muy ‘UX’: “Mark Hall”. Justo después del nombre, su fecha de nacimiento “2 de abril”. Lugar de Nacimiento: Lima. Todo encaja perfectamente en tu contenedor.

El problema con el mundo es que tiene muy poco de Mark Hall, y tiene mucho de Consuela Bananahamock Fernandez van Bronckhorst de Icorrobarrutia, nacida el 30 de noviembre en Ciudad del Cabo. ¿Está tu UI preparado para esto? ¿O creaste una interfaz que chamulla sobre su perfección?

5. Usas plantillas ‘tal-co’ (tal-como vinieron)

Déjame confesarte algo: Amo las plantillas. Están muy bien diseñadas, tienen efectos fantásticos, son responsive… básicamente el trabajo ya está hecho, y solo tienes que llenarlas de contenido, ¿verdad?

Bueno, sí. El problema es que en ocasiones las plantillas (hechas con Lorem Ipsum, probablemente) tienen muchos espacios para rellenar. Y en vez de adaptar la plantilla a las necesidades de tus usuarios, generas más contenido para llenar los espacios en blanco. (Esas itálicas son de puro juzgamiento.)

Ese contenido extra que generaste, esa foto que pirateaste de Shutterstock con la “búsqueda por imagen” de Google, ese titular con frases vacías, ese párrafo que parafrasea un contenido anterior… todo eso es chamullo al más alto nivel.

6. Escribes para Google (SEO)

Un ‘UX Chamuller’ entrenado sabrá alargar textos ad infinitum (¿loremipsum?) para poder incluir todos los keywords que permitan a Google indexar su página. El problema con este tipo de contenidos es que generan frustración: el usuario entró a tu página a buscar una respuesta, no a que le re-frasees la pregunta 10 veces en los tres primeros párrafos:

En este artículo te voy a contar cómo hacer para no escribir chamullo para el SEO. Estate atento para descubrir, en unos segundos, cómo no chamullar, florear, vender la pescá, cuando redactas para que Google detecte palabras clave en tu contenido.Mucha gente se pregunta ¿Cómo evitar el chamullo en las redacciones de Search Engine Optimization? En realidad es bastante simple dejar de chamullar cuando escribimos para los motores de búsqueda.

Pregúntate si el SEO está ayudando a tu empresa. Quizás hay más gente entrando a ver tu página, pero ninguna realmente se queda porque no encuentra lo que busca. O porque tu chamullo le impide llegar a su objetivo de usuario. O quizás porque los bombardeas con publicidad irrelevante.

Solteras en su área buscan chamullar.


Cómo dejar el ‘UX Chamulling’

Tres palabras: estrategia de contenido.

Hay mil formas de explicar lo que es, pero una con poco chamullo se resumiría así:

Toda pieza de contenido debe cumplir un objetivo específico.

‘Pieza de contenido’ es todo elemento que transmite información al usuario: Imágenes, videos, fotografías, íconos, texto, audios, tablas, números, infografías, etc.

Los ‘objetivos específicos’ pueden ser: informativos, de engagement, de empatía, de marketing, de branding…

Sobre esta información nueva, te hago la siguiente pregunta:

Cuando pensaste en hacer ese sitio web y automáticamente pensaste en poner una cabecera grande con un vídeo de fondo ¿lo hiciste porque tenías un objetivo específico para esa imagen? ¿o fue porque los chicos cool del barrio lo hacían y tu también querías ser popular?

Parte de tu recuperación de ‘UX Chamuller’ es notar que se puede seguir siendo cool sin tener que usar un header con vídeo o un efecto ‘parallax’ 👇

De hecho puedes ser ‘the coolest’.

“Pero Nico, en mi compañía / start-up / negocio / carrito sanguchero no hay un estratega de contenidos”

Entonces, querido UX Designer, tú debes asumir ese trabajo.

Si estás encargado del UX Research, asumir también el rol de Estratega de Contenido ayudará a emparejar el storytelling de tu producto con el que se muestra en tu interfaz.

Si eres diseñador de interfaces, es tu oportunidad de escalar al siguiente nivel y empezar a construir un producto coherente a nivel visual y de contenidos. Va a ser como redactar el guión de una telenovela, y luego encargarte del escenario y del maquillaje, ¿CUÁN GENIAL PUEDE SER ESO?

Pare de sufrir

Con estas lecturas recomendadas:

*El concepto de “chofer de mouse” lo tomé prestado de una charla de Daniel Mordecki sobre interfaces intuitivas.

“Hackeando” los Design Sprints para hacer que siempre funcionen

Durante varias semanas estuve pensando cómo escribir y estructurar este artículo, para contar bien mi experiencia de cómo he logrado hacer que los famosos Design Sprints (lo mejor que hay por estos días para diseñar soluciones validadas), realmente funcionen, sobre todo en el escenario más adverso: Las corporaciones. ¡Aquí vamos!

Érase una vez…

Hace un año atrás, decidí comprarme el libro Design Sprint como parte de una investigación que respondía a la inquietud de cómo hacer que el proceso de diseño lograra ser mucho más eficiente y menos costoso aún -de lo que ya era con Lean UX.

Quise entender de primera fuente, que tan interesante era esta “famosa” metodología de la que venía escuchando hace un buen tiempo. Y resultó sorprenderme con creces. Ese grupo de diseñadores cracks de Google Ventures, encabezados por Jake Knapp, habían logrado acortar el proceso de diseño de manera asombrosa, probando con éxito en muchas startups de Sillicon Valley, una metodología que servía para desarrollar o validar ideas de productos y casi cualquier desafío que tuvieran por delante. Todo lo que contaban en el libro me hizo mucho sentido y quedé tan entusiasmado, que quise ponerme a trabajar de ese modo casi inmediatamente.

El espejismo de la utopía

Sin embargo, la primera duda que me surgió (y que de seguro a muchos, de los que aún no han tenido el placer de trabajar de esta manera, también les surge), es que si dado el contexto en que esta metodología se inventó –el de las startups– podría realmente ser aplicada con proyectos de grandes empresas. Un escenario donde la convocatoria de stakeholders, con poder decisión, suele ser difícil. Porque los altos y medianos cargos están siempre con la agenda muy apretada y contar con su participación en largas reuniones seguidas, parece ser –muchas veces– imposible.

Con mayor razón cuando se trata de diseñar. Porque al final se supone que a uno, como consultor externo, lo contratan para dar solución a los problemas casi como un mago, para que cuando el proyecto termine, el cliente levante el dedo para arriba o para abajo, para decirnos si está conforme o no con el resultado. Dependiendo de qué tan convincentes seamos para “venderle” la solución, en la que seguramente, trabajamos solos en nuestro laptop durante varias semanas.

Pero esta metodología al contrario de eso, tiene como requerimiento clave la participación y colaboración directa de nuestro cliente, en su más amplio espectro de personas y cargos. Es absolutamente necesario que en la mesa de trabajo estén presentes todos: jefes de proyecto, desarrolladores, marketing, diseñadores y cualquier persona que trabaje en la empresa, que pueda aportar una visión o perspectiva relacionada con el problema y así transformarse en co-creadores.

Aquí, los escépticos –como yo también lo era– pensarán en que convencer a dichas personas, a que, como dice el libro: liberen sus agendas por una semana completa y se dediquen full time a nuestro proceso, es derechamente una utopía. Por lo tanto, el único término que inevitablemente les rondará en la cabeza es: Imposible. Pero yo he comprobado que no lo es, y eso es lo que principalmente quiero contar.

Manos a la obra

Design Sprint en institución educacional

La primera vez que me lancé a probar Design Sprint, lo hice como un taller. Puse en práctica la metodología, para ayudar a un área de diseño y desarrollo de una importante entidad educacional. Una unidad encargada, por una parte, de desarrollar el software para solucionar diversos problemas administrativos y por otra parte, ser también los proveedores de hardware para todos los departamentos internos de la organización. Un área con desafíos complejos, pero con prácticas un tanto obsoletas, para responder con velocidad a sus requerimientos, donde habitualmente ni siquiera se hacen el tiempo ni saben cómo validar, si las soluciones son realmente efectivas o sirven bien para lo que deben.

Así que armamos equipos de 8 personas, mezclando perfiles bien representativos, como los que anteriormente describí y desarrollamos 2 sprints. Cada uno enfocado en un problema diferente. La idea principal era entregarles una herramienta que les permitiera continuar desarrollando e iterando mejores soluciones para todos los desafíos que venían. Para mejorar sustantivamente sus procesos, con una mirada más innovadora. Y de paso, por mi parte, experimentar y sumergirme de lleno en la práctica de esta metodología, para adaptarla o mejorarla, según el escenario al que me enfrentara más adelante. Y por supuesto alentar, con el ejemplo a mis compañeros del equipo a seguir mis pasos y lanzarse también, sin miedos ni prejuicios.

El resultado fue increíble, los equipos quedaron súper motivados y lograron ver cómo en una semana pudieron modelar una solución y probar con usuarios las hipótesis que levantaron y detectar en muy poco tiempo los errores que debían corregir. Un tremendo aprendizaje para ellos y para mí.

Seguido de eso, aprovechando mi entusiasmo, intenté hacer exactamente lo mismo con un cliente corporativo y no tuve buenos resultados, porque fue imposible conseguir que los stakeholders estuvieran dispuestos a dedicar 4 semanas completas a 4 sprints. El proyecto se llevo a cabo con un intento fallido de la metodología y resultó ser un híbrido muy extraño entre la vieja manera de hacer las cosas y la nueva. La conclusión: era absolutamente necesario adaptarlo.

Adaptación

Luego de las primeras experiencias con Design Sprint, revisé una a una las actividades y los tiempos y logré dar con la manera de poder adaptar el proceso y acortarlo mucho más, sin romper el espíritu ni dañar la integridad de la metodología. Mantener su esencia intacta, pero acomodada a las circunstancias.

Así que facilité un nuevamente Design Sprint, durante los 5 días como dice el libro, pero acorté los tiempos por actividades. Lo que nos permitió hacer todo en jornadas de 3 horas diarias, en vez de 6 como dicta la metodología. Y funcionó perfecto.

En retrospectiva, además de validar que se podía hacer en menos tiempo del propuesto, sin sacrificar ninguna actividad, me di cuenta también que quizás era posible suprimir algunas dinámicas, para darle más espacio y tiempo a otras que resultan ser fundamentales. Ese sería el próximo paso en mi aventura de poner a prueba los límites de la metodología.

Time-Timer

El desafío mayor

Y me tocó nuevamente el turno de enfrentarme al cliente “enterprise”, donde otra vez, tuve la oportunidad de proponer trabajar con Design Sprint. Y es ahí donde surge la problemática que describía al comienzo del artículo y por el cual falló mi primer intento en este contexto. El gran desafío era como convencer al cliente de lo bueno que trabajar así, pero por sobre todo, requerir de su participación y compromiso durante 5 días continuos por varias semanas. Así que pensando en cómo podría hacerlo funcionar, me la jugué por hacer el proceso en los mismos 5 días, pero con la participación del cliente limitada a sólo 3 días. ¿Cómo?

Simplificación

Gracias a la retrospectiva de la experiencia adquirida hasta ahí, concluí que cada día de sprint se sustenta en tareas claves, las cuales son irremplazables y absolutas responsables de que la metodología funcione. Así que la propuesta consistió básicamente en quitarle carga a los stakeholders y hacerlos participar sólo de lo esencial, simplificando el proceso a lo siguiente:

  • Día 1: Hipótesis, objetivos y mapeo de la solución.
  • Día 2: Revisión de referentes y bocetos de la solución.
  • Día 3: Análisis, discusión, votación y convergencia en la solución a prototipar.
  • Día 4: Prototipado de la solución.
  • Día 5: Pruebas con usuarios y conclusiones.

Por lo tanto, la idea era comprometer al cliente corporativo, sólo de lunes a miércoles en reuniones, inicialmente de 3 horas el lunes y martes y de 1,5 horas el miércoles, por cada semana de sprint. Lo importante es mantenerlo siempre conectado con el proceso y siendo siempre un co-creador activo de las soluciones que se vayan probando para cada hipótesis. Lo que permite que no aparezcan sorpresas al final del proyecto. Además con la ventaja de poder obtener resultados semanales concretos y plasmados en un prototipo funcional y navegable.

¿Y qué pasa entonces con el jueves y viernes? Ese es un trabajo que asumo yo. Porque objetivamente, no es necesario forzar al cliente a prototipar, si para eso estamos nosotros los diseñadores. Tenemos los skills suficientes para hacerlo seguramente mejor que ellos. Y lo mismo aplica para el viernes, cuando hay que ejecutar las pruebas. Sin embargo, la invitación a participar como espectadores está permanentemente abierta. Siempre y cuando, estas pruebas se realicen bajo el concepto de “laboratorio de usabilidad”. Porque muchas veces, cuando el target de usuarios es amplio o exploratorio, personalmente prefiero los “test de guerrilla”, dado que los usuarios son mucho más honestos que en un ambiente de laboratorio. Seguramente una discusión que es material para otro artículo o con gusto para compartir un café.

Resultados actuales

Poner en marcha este modelo para hacer Design Sprint ha sido todo un éxito. Al menos así lo hemos sentido y estamos felices con el resultado en el equipo y el cliente también lo ha demostrado. Se nota su entusiasmo desde el primer sprint, porque puede ver lo valioso y pragmático de trabajar así.

Así que hemos empezado a aplicar esta versión “hackeada” en todos los nuevos proyectos con excelentes resultados. Clientes contentos y equipo motivado. Mis compañeros y yo hemos estado trabajando ahora en pequeños ajustes y constante retrospectiva al final de cada proyecto para saber qué nos hizo falta y cuáles resultan ser los aciertos más concretos.

Hemos trabajado en proyectos con grandes y medianas empresas, instituciones públicas y privadas y por estos últimos días estamos probando la metodología en remoto con una startup, aprovechando las herramientas colaborativas para el mapeo o la votación de propuestas para el prototipo. Y creo que tenemos también la mejor impresión. En un próximo artículo prometo contar el detalle de los ajustes y sobre la experiencia a distancia.

Resumen y conclusiones

Dada la positiva impresión que hemos tenido hasta ahora y lo motivante que ha sido liderar proyectos aplicando esta metodología, me gustaría resumir las grandes ventajas que yo le encuentro:

  • El pragmatismo Lean + Agile
    Design Sprint es una maravilla del pragmatismo, que mezcla magistralmente las prácticas ágiles con el espíritu Lean, dejando de lado todo lo que realmente no aporta. Poniendo énfasis en lo que se conecta directamente con la propuesta de valor.
    Al importar el modo de trabajo Agile/Scrum en sprints, empuja la eficiencia y evita la parálisis creativa.
  • Alineación de visiones
    Como todo el equipo (cliente + consultores) son parte activa del proceso todo el tiempo, se toman las decisiones en conjunto y se evitan las sorpresas. El equipo aprende unido y en consenso se alinean en torno al mismo objetivo y propósito. Todos son co-creadores en un entorno de participación y colaboración.
  • Integración con desarrollo ágil
    Dado que esta metodología está inspirada en el desarrollo ágil. Adaptando el proceso de diseño al modo de sprints con entregas semanales, logra conectarse naturalmente con los procesos de desarrollo en entornos ágiles.

    Uno de los proyectos de los que trabajaron compañeros del equipo con Design Sprint, comenzó a ser desarrollado desde el término del primer sprint de diseño, lo que permitió una salida a producción con las primeras historias de usuario que daban vida real al MVP, mientras los demás design sprints estaban en progreso.

    Y otra de los detalles interesantes en esa misma línea, es que al término de cada sprint, el equipo de desarrollo puede empezar a escribir las historias de usuario y detectar los vacíos que puedan haber quedado fuera del prototipo, para que los diseñadores reaccionen en tiempo real y así no afectar el futuro del desarrollo.

  • Flexibilidad y versatilidad
    Estoy absolutamente convencido que es una metodología muy flexible para cambios y adaptaciones en hartos sentidos. Basta con sólo cuidar el core y las actividades clave para que todo ande a la perfección.
  • La perfección no existe (?)
    Es tanta la maravilla que he visto en la práctica de la metodología, que personalmente me ha costado encontrar algún problema de peso. Sin embargo, dudo que Design Sprint sea una metodología perfecta, es como cualquier otra, una guía, no una receta absoluta e inalterable para asegurar el éxito. Siempre es necesario probar diferentes sabores (como en la comida) y encontrar el ajuste preciso, el aliño o toque personal. Aguzar el oído en la tuerca y apretar hasta encontrar la medida justa. Aunque vale agradecer infinitamente a sus creadores por estos regalos y creo que es súper valioso también aportar con la mirada y la experiencia personal de todos nosotros, que siempre le servirán a los demás para ampliar sus perspectivas.

Diseñadores, desarrolladores y a todos los que trabajan en UX, los invito a que lean el libro (si aún no lo han hecho), que experimenten con la metodología y contribuyan al debate, para enriquecer el conocimiento de toda la comunidad.

Y por supuesto que cualquier duda que tengan, siempre feliz y dispuesto a ayudar. O si con su experiencia discrepan conmigo, bienvenidas las críticas también.
😉

Me aburrió Sketch

No pretendo escribir un manifiesto en contra de Sketch, ni de las otras herramientas que hoy encabezan la lista como favoritas entre los diseñadores de interfaces. Sólo quiero plantear mi visión personal acerca del uso innecesario de estas herramientas sobre todo para quienes tenemos experiencia escribiendo HTML/CSS, y optar por ellas a la hora de diseñar nuevas interfaces, y de paso hacer una invitación a perder el miedo.

Soy un diseñador dedicado a la experiencia de usuario hace varios años y desde hace muchos más, he dedicado tiempo a aprender e investigar permanentemente sobre los procesos de diseño y herramientas disponibles que nos ayudan a hacer mejor nuestro trabajo. Entre esas, hay un par que conocí en los últimos años y que he usado bastante, porque me parecen excelentes y porque hacen una dupla genial: Sketch +Invision.

Pero como decía al principio de este post, no lo escribo para hablar mal de estas herramientas, sino que para explicar porqué (enhorabuena, como dicen los españoles) me aburrí de ellas.

La maravilla de Sketch

Primero que todo, me gustaría decir que considero a Sketch una maravilla. Aunque lamentablemente sea sólo para usuarios de Mac. Sé que muchos consideran caros los Mac (con mucha razón) y otros tantos los detestan, así que mucha pena por los Windows/Linux users, que se la pierden.

En su última versión desarrollaron interesantes mejoras y complementos dentro del software para manejar mejor los objetos y hacerlos más inteligentes a la hora de repetirlos (los overrides) y un sin fin de otras cosas muy geniales. Además de tener una interfaz simple y amigable, ideal para diseñadores que se formaron usando Illustrator de Adobe (o el prehistórico Freehand) e incluso los que se aventuraron con Phostoshop para hacer interfaces en el pasado y sobre todo para los viudos del difunto Fireworks. Y que además de todo eso, tiene full integración con Invision, una plataforma web para crear prototipos, igualmente genial. Pero que sin embargo insisto, me aburrí de usarlas.

¿Por qué me aburrí?

Todos sabemos o creemos que escribir código supone una dificultad extra que puede verse reflejada en el tiempo. No obstante es un pro excepcional para el proceso de la implemementación en desarrollo. Y ahí hay un punto insuperable.

Por lo tanto, si yo sé HTML, ¿para qué gastar el doble de tiempo dibujando interfaces en Sketch (o el software que sea) y luego armando un prototipo en Invision (o el software que sea), si lo puedo hacer directamente en código?

Algunos podrán alegarme que HTML no es muy flexible o mejor dicho, tan rápido de manejar a la hora de probar si esto queda mejor de una manera u otra, que es lo que hacemos todos los diseñadores cuando estamos “creando”. Sin embargo, si estamos en un proceso de diseño de experiencia de usuario, habremos pasado por fases previas donde las interfaces estarán precedidas por wireframes que al menos fueron “microvalidados”. Entonces al momento de ponernos a trabajar en un prototipo, generalmente ya tenemos una base y un layout predefinido.

Así que, meterse directo al código es algo bastante lógico. Y para lo único que se justificaría gastarse un poco de tiempo usando Sketch, sería para trabajar un look and feel más prolijo. Para decidir cuál será el estilo visual que tendrán las interfaces de lo que estamos diseñando. Basta con probar algunos botones, algunos campos de formulario, y uno que otro detalle más y ya. Sólo bastará con diseñar una pantalla y tenedremos todo lo que necesitamos. No es necesario seguir gastando tiempo ahí, diseñando cada una de las interfaces porque será tiempo perdido. Y si a eso le sumas que las interfaces tienen que ser responsive, más tiempo perdido.

Hoy día, en web existe una amplia variedad de frameworks que nos facilitan la vida al hacer código, incluyendo sus microinteracciones, y lo mejor de todo, es que tienen abordado el responsive web design. Bootstrap, es el mejor ejemplo.

Perder el miedo a cerrar Sketch y abrir Sublime

Algunos también podrán insistir aquí que escribir código es mucho más lento. Pero creo que eso es una aseveración planteada desde el miedo. Un miedo que también tuve por mucho tiempo, debo reconocerlo. Pero ya por fin, es parte del pasado.

Así que, me decidí a cerrar Sketch definitivamente y lanzarme a prototipar directamente sobre HTML/CSS, lo que me ha dado muy buenos resultados, incluso en rápidos sprints, donde sólo hay un día para hacerlo.

Contaba con una ventaja que no estaba aprovechando sólo por miedo. O me había encantado tanto usar Sketch que me estaba olvidando lo genial que es mirar tu prototipo funcionando casi de verdad, adaptado en diferentes dispositivos y que cambiando un par de líneas de código o reglas de CSS podía hacer mucho más (y mucho más rápido) que duplicando artboards en Sketch o peor aún, simulando las interacciones después en Invision.

Lo mejor de todo esto, es que un prototipo HTML, es algo que agradecerán mucho los desarrolladores, que no necesitaran tener que tomar el Invision, y mirarlo para tratar de replicar las interacciones o mirar las interfaces del manual de diseño que tuviste que hacer en Zeplin o en PDF, para imitar las interfaces, con todos sus detalles. Así entonces, cuando el software esté terminado, no existirá ese maldito GAP entre lo que diseñaste en Sketch y lo que terminó resultando. Incluso harás un diseño responsable, probado de que lo que propones efectivamente se puede hacer.

¿Entonces estoy sugiriendo no usar más Sketch?

No, en absoluto. Pienso que Sketch es genial para modelar, para el momento de la “creación” y perfeccionamiento del look and feel. Es mucho más amigable que HTML para ello, porque nos permite con soltura, probar, mover, cortar, pegar, repetir, duplicar, achicar y agrandar rápidamente. Pero en la mayoría de los casos, basta con hacerlo para una sola pantalla, y de ella obtener las medidas y posición del layout o el estilo visual de los elementos de interfaz. Los colores, sombras, bordes, tamaño de la tipografía, etc. Es lo mejor que existe para manejar y exportar assets, tipo SVG.

¿Y qué pasa con el diseño mobile?

Por supuesto que no podemos ignorar que Sketch es insuperable cuando hablamos de diseño de aplicaciones móviles. Porque aún no hay nada tan simple para nosotros, los diseñadores, con respecto a meternos en el código de apps nativas, como si lo es en web.

Sin embargo la gran nueva de era de Javascript mueve la aguja de vuelta hacia la web. Hoy por hoy, las aplicaciones híbridas, están tomando fuerza por sobre las nativas, sobre todo por lo práctico y económico que es desarrollar un sólo código. Otra razón para acercarse a HTML.

Mi consejo

Si eres un diseñador con experiencia en HTML, te sugiero que hagas como yo y cierres el Sketch, abras sublime (o el editor que prefieras) y te sumerjas en el código. O si quieres puedes compartir tu desacuerdo en los comentarios, con los fundamentos que quizás me hagan entender lo equivocado que estoy.

Si eres uno de los que no sabe mucho de HTML/CSS, y por eso no te atreves a aventurarte, te recomiendo retomar el aprendizaje y mejorar, para hacer un trabajo mucho más eficiente. Recuerda que la práctica hace al maestro.

Y si eres de los diseñadores que no se manejan nada con el código, te invito a que aprendas ya. A la larga te darás cuenta lo bueno que es trabajar de este modo.