Cómo preparar un portafolio UX

Centrándose en el problema, no en la solución

Bueno, desde hace un tiempo veo que en general, los portafolios de presentación de colegas UX no se centran en lo realmente importante: El Problema. Centrándote en el problema te permite enfocar de manera mucho más clara la causa de frustración de los usuarios y definir cómo vas a resolver ese dilema. Por experiencia, las veces que por diversos motivos nos hemos centrado en la solución y no en el problema los resultados no han sido los más satifactorios, teniendo en cada caso que volver a iterar sobre lo desplegado y perder tiempo.

Cuando no te centras en el problema si no en la solución, puedes llegar a tener un cierto tipo de parálisis de análisis

Sucede lo mismo cuando creas tu portafolio UX, te centras en la solución y no en el problema lo que posiblemente cause que tengas que volver a estructurar la información que compartes con colegas, reclutadores, etc. Uno no va a contratar a un UX por lo bonito que deje una interfaz preparada con esmero en Sketch, por lo impactante que se vea una animación hecha en Origami o lo intrincado que se vea en tu pared de trabajo un workflow de wireframes sacados con UXpin o POP. No, eso no es lo que busca un reclutador (experto), no quiero un UX que me pinte bonito o me maree con cientos de prototipos.

Partes de un proyecto en un portafolio UX

Un UXer que demuestra que “entiende” el problema. Eso es lo que se busca. La recomendación es que plasmes en tu portafolio estos 5 puntos por cada caso de uso que presentes como proyecto:

• Reto
• Solución
• Enfoque
• Impacto
• Entregables

Así, tu portafolio claramente mostrará que tienes lo necesario para formar parte de un equipo de UX pues entiendes desde otra perspectiva el valor que aportas como diseñador, desde el entendimiento del problema a la generación de documentación final en cada proyecto en el que te involucres.

Hay cientos de portafolios con la coletilla UI/UX que sólo muestran interacciones, diseños de UI y nada más

El Reto

Un reclutador lo que busca es ver cómo el diseñador se centra en el reto, y sobre todo lo entiende (tantas cosas por entender aquí, desde la perspectiva del usuario hasta las posibilidades de la tecnología que utilizará para superarlo). El reto es lo que llamo “enamorarse del problema”. En el reto definirás a qué te enfrentaste.

Ejemplos de retos:

“Crear un framework a medida para trabajar en la app, unificar estilos visuales y consistencia en el diseño.”

“ Generar conversiones directamente desde la versión de escritorio hacia la versión en la nube de la aplicación, la conversión debía darse “en caliente” para no perder oportunidad.”

“Mejorar la última versión de la home page de la aplicación debido al incremento sustancial de cuentas sincronizadas por los usuarios que estaba convirtiendo en obsoleta, caótica y poco intuitivo el diseño de interfaz, se necesitaba dar un salto de calidad del “findability” de la pantalla que debería estar funcionando como el “centro de operaciones” de toda la aplicación”

La Solución

Como lo dice el título, aquí pondrás el logro final conseguido, el reto superado (o lo aproximado a ello, recuerda que hay limitaciones). Usualmemte la solución es una descripción análoga al reto, es lo ideal pero no tiene que ser necesariamente así. Un reto puede tener muchas soluciones y la definitiva pasa por una serie de iteraciones, test con usuarios, validaciones, etc… y es lo que “resuelve el problema”,

Ejemplos de soluciones:

“Se diseño un potente modelo de navegación similar a un “breacrumb“ que permite a los usuarios encontrar ordenadamente las fuentes que sincroniza.”

“Se diseñó un configurador que incluye opciones avanzadas con una interfaz limpia y clara permite responder en tiempo real las elecciones del usuario y con controles intuitivos.”

“Se decidió prototipar inicalmente para iOS, tanto para iPhone como iPad, debido a que se contaba con los recursos necesarios para esa ejecución.”

El Enfoque

En esta sección se describe la manera en que el equipo valoró el reto antes de la solución definitiva. Es la suma de las maneras de ver las cosas o las ideas y en consecuencia de tratar los problemas relativos a ellas, siempre desde una perspectiva interdisciplinar; puesto que tanto tú como diseñador como el equipo de front end, la información que proporcione el equipo de back end, los datos que obtienes desde la gente de soporte como los requerimientos de marketing son distintos y se dan desde diferentes realidades, no puedes hacer un enfoque tú solo por que “eres el diseñador”, debes describir cómo iteraste con el resto del equipo para proponer la solución. Esta parte es cómo “analizaste el problema”,

Ejemplos de enfoque:

“Varias iteraciones de concepto con el equipo de desarrollo y negocio, prototipado mediante sketches en papel, demo funcional en iOS para testers, validación interna con el equipo de negocio, creación de perfiles de personas.”

“Reuniones con el equipo de soporte para comprender la problemática de los usuarios representada por diferentes tickets que tenían el denominador común de exceso de correos de notificaciones, sketches e iteraciones con el equipo de desarrollo y soporte, validación interna con el equipo de soporte utilizando la herramienta Invisionapp, presentación de dos modelos de configurador, por tabs o con scroll hacia abajo, test A/B con usuarios para determinar el diseño más funcional.”

“Uso de la herramienta on line Uservoice para determinar sugerencias de usuarios, desarrollo de “lean personas” para definir mejor el tipo de diseño que se propondría, prototipado mediante sketches y wireframes de baja fidelidad e iteración con el equipo de desarrollo, validación interna con el equipo de desarrollo utilizando la herramienta Invisionapp, test de usuarios estilo guerrilla utilizando la herramienta Silverback”

El Impacto

Descripción de cómo cambió la vida de los usuarios, cómo mejoró el trabajo interno, cómo se optimizaron los tiempos, etc,…

Definitivamente, tu trabajo como facilitador ha tenido un impacto, no has pasado meses o semanas trabajando en una feature nueva y al momento de desplegarla no ha sucedido nada. Quienes hayan participado en su desarrollo y quienes se han enfrentado a ella como usuarios han sufrido (para bien o mal) un cambio, tanto de comportamiento como emocional, si no ha salido lo que esperabas, dilo, los mejores UXers se hacen a base de fallos, no debes tener miedo a equivocarte, la responsabilidad está sobre tus hombros pero es que es tu trabajo, puedes equivocarte, no es malo, lo malo es no enmendarlo, y para ello eres un UXer, probarás, verás tus métricas, evaluarás y actuarás en consecuencia, yo mismo he rectificado en el camino, las start ups somos muy lean en un inicio y la sombra del error es muy grande, pero no hay que temerle, y no hay que temerle por que las decisiones las tomaste basándote en supuestos reales, no en opiniones. El impacto es sobre “las consecuencias de la solución al problema”,

Ejemplos de impacto:

“La unificación final de estilos y consistencia visual de la UI de la aplicación permitió modernizar la interfaz, mejorar la comunicación con el usuario, generar nuevos patrones de microinteracciones, agilizar el trabajo y coordinación con y entre el equipo de diseño y el equipo de desarrollo front-end.”

“Esta nueva feature permite a los usuarios contar con una herramienta clave en la fidelización de sus comunidades.”

“Se incrementaron las conversiones a la versión profesional desde la versión gratuita.”

Los entregables

Como todo proyecto, ha generado un sinfín de documentación. Guárdala, archívala, no sabes cuándo un prototipo deshechado en un proyecto calce como un anillo para otra ocasión. Los entregables son importantes puesto que son la parte medible y verificable que se elaboran para completar un proyecto o parte de un proyecto. Tú como diseñador debes ser la estrella de los entregables intermedios (internos), puesto que son los que se utilizan para producir los entegables finales. Los entregables ayudan a definir el alcance y el avance del trabajo en el proyecto. “Son la medición y monitorización del trabajo para la solución del problema”.

Ejemplos de entregables:

“User flows + Sketches de concepto, mockups de alta fidelidad, demos funcionales”

“Sketches de concepto, mockups interactivos de alta fidelidad, demo funcional, vídeos de los test A/B de usuarios”

“Ficheros en PSD, demo interactiva para desktop, demo interactiva para iPad, sketches”