¿Porqué es necesario mapear las skills y competencias de los diseñadores de mi equipo?

Alexandra Mengoni León
DesignOps Latam
Published in
9 min readApr 18, 2023

El mapeo de skills y competencias en el equipo de diseño es una de las iniciativas más complejas que creo hay dentro de lo que hacemos en DesignOps. Claro, hablando desde mi experiencia de un equipo de casi 300 diseñadores. Es por ello que mi recomendación siempre va a ser: “empieza cuando está aún pequeño el equipo, no te vas a arrepentir”.

La forma en que se desarrolla esta iniciativa va a variar mucho según el tamaño de equipo, la industria en la que se encuentran, la madurez del equipo, su misma estructura. Yo vengo a compartirles cómo fue mi experiencia realizándola en una empresa de servicios, específicamente una agencia digital como lo es Huge, donde trabajo actualmente como DesignOps Manager. Como nosotros no teníamos nada documentado, decidimos empezar mapeando las compentencias a través de un self-assessment, es decir, cada diseñador se iba a autoevaluar en las diferentes competencias mapeadas. Luego ya vendría otra etapa para que sus managers validen qué tan precisa era esa evaluación.

Sobre este proyecto se venía hablando prácticamente desde que ingresé a Huge hace 2 años. En ese momento tenía un alcance diferente ya que nos enfocábamos solo en el equipo de diseño de Colombia que eran aproximadamente 120 diseñadores. Con los cambios que ha tenido la empresa en el último año, nos abrimos a atender no solo a Colombia sino a todo el equipo Global. Ahí se empezó a complejizar el reto, al ser más diseñadores, pero nos permitía ejecutarlo una sola vez y no hacerlo por partes con cada oficina.

El artículo está dividido en 5 partes: La relevancia que tiene esta iniciativa desde diferentes frentes; los actores involucrados según la experiencia que he tenido; las herramientas que utilizamos para este mapeo; algunos resultados hasta ahora obtenidos; y los aprendizajes que valen mucho la pena compartir.

La relevancia

Empecemos entendiendo la utilidad que tendría este tipo de iniciativa en cualquier tipo de equipo de diseño y porqué es tan importante hacerlo.

En primer lugar, es sumamente importante entender cómo se cuentra hoy el equipo, lo cual nos va a ayudar a responder preguntas como las siguientes:

  • ¿Cuáles skills tienen y en qué nivel?
  • ¿Cuáles son las fortalezas del equipo? y ¿cuáles son nuestras debilidades?
  • ¿Quiénes podrían ser referentes en ciertos temas? ¿les interesa compartir ese conocimiento?
  • ¿Qué necesitamos reforzar en el equipo por las necesidades y exigencias del mercado y nuestros clientes?
  • ¿Cuáles capacitaciones son más prioritarias en el equipo?
  • ¿Los niveles de skills hacen match con el seniority de cada diseñador? ¿Está acorde con su plan de carrera?

Esto a su vez, nos podrá permitir asignar de una manera más eficiente a los diseñadores a los proyectos. Nos ayuda a hacer ese match entre lo que necesita el proyecto vs las habilidades que tienen los diseñadores y quiénes pueden calzar mejor para que sea un win-win.

Skills ejemplo. Creación propia.

Sin embargo, me atrevería a decirles que no solo basta con conocer qué tenemos y qué necesitamos sino también, qué le interesa al diseñador reforzar, aprender y desarrollar. Aquí se complejiza mucho más la conversación, sin embargo, a largo plazo podremos tener beneficios como la retención del talento, hacer más eficiente la inversión en capacitaciones, reforzar la motivación del equipo, etc.

Skills ejemplo. Creación propia.

Entender ese nivel de interés de los diseñadores me permitirá:

  • Asignar a proyectos a los diseñadores que desean reforzar esos skills
  • Transparentar si ese es un skills que el diseñador podrá aprender en los proyectos que ofrece la empresa o no
  • Asignar temporalmente, por ser una necesidad, pero tomando en cuenta que lo tendremos que rotar si no lo queremos perder
  • Enfocar las conversaciones y esfuerzos de desarrollo en aquello que realmente le interesa al diseñador

Hasta este punto, hemos tocado básicamente los puntos más internos del equipo que son el desarrollo de su talento y en qué proyectos lo pueden reforzar. Pero, hay que tomar en cuenta que este tipo de iniciativa no afecta ni beneficia solo a los diseñadores sino que hay muchos otros actores importantes.

Los involucrados

Les comparto un poco cómo fue mi experiencia en Huge, empezando por mencionar quiénes han sido, hasta ahora, todos los involucrados.

Creación propia para el artículo.

Equipo core

  • El diseñador es el actor central, teníamos la necesidad de entender qué nivel tienen hoy todos los diseñadores en cada skill. En este caso, ellos mismos eran los que iban a completar la evaluación.
  • El DesignOps: Es quien se encargó de orquestar a los diferentes actores, unir todas las partes y en este caso, diseñar los dashboards a ser utilizados luego por los principales interesados.
  • Los Directores Creativos: Quienes son los más expertos en cada Craft, por lo que ellos fueron los que definieron el listado de skills a ser mapeados. Aquí se tomó la decisión de que los skills de UX (por ejemplo) no se mapeen solo entre los UX designers sino que los skills de todas las prácticas de diseño se evalúen en todos. Esto fue necesario al ser una empresa de servicios. Terminamos con un listado de un poco más de 100 skills, debido a la variedad de tipos de proyectos que tenemos.
  • El Customer Succes Manager (CSM) de Airtable: Fueron quienes nos ayudaron a armar todo el “backstage” de forma eficiente para que los dashboards funcionen y poder compartirlo con los stakeholders necesarios. En nuestro caso, fue la herramienta elegida.

Stakeholder involucrado

  • Talent Development: Un actor clave ya que toda esta información les permitiría encontrar esas necesidades de capacitación, entender qué falta reforzar en el equipo y definir prioridades según hacia dónde va el equipo y el negocio.
  • IT: En nuestro caso, al usar Airtable, teníamos que estar seguros de que IT nos proporcione y nos actualice la base de datos de todo el equipo, que provenían de otras herramientas oficiales de la empresa, y construir correctamente los dashboards en la herramienta. Así poder hacer los filtros y agrupaciones que necesitamos.
  • Team Design: El equipo encargado de asignar al talento a los proyectos. Considero, hasta ahora, que es el equipo que más beneficio obtuvo de esta iniciativa, en la sección de “Resultados” les cuento más.

Stakeholder informado

  • Reclutamiento: Si bien no lo hemos hecho aún, en una siguiente etapa de este proyecto sería súper útil que este equipo tenga bien mapeados esos skills que están buscando en los candidatos para comparar con las evaluaciones que se les hacen.
  • PMs: Tener claridad de cuáles son esos skills que tiene el talento que están ingresando al equipo ayudará a tener conversaciones diferentes y más enfocadas en lo que necesita el proyecto en ese momento.
  • Otras disciplinas: Esta iniciativa tuvo sus inicios en el equipo de diseño, sin embargo, escaló rápidamente a otras disciplinas hasta incluso lograr homologar la misma evaluación para las que entraron en esta primera etapa. Ha sido clave trabajar de la mano con los otros líderes y apoyarnos en el proceso.

Las herramientas

Nuestra idea inicial era usar Airtable, ya que es donde teníamos la base de datos de todo el equipo. Las diferentes aplicaciones e interfaces que tiene la herramienta ayudaría a que fuera más eficiente el proceso y el consumo de la data. Sin embargo, su punto débil era el formulario, ya que para nuestra necesidad, el form no se adaptaba ni respondía a la estructura que le queríamos armar. Intentamos resolverlo con el CSM pero no lo logramos.

Es por ello, que el formulario que usamos fue la vieja confiable: un Google Form. Este nos permitió agrupar los skills con el “Multiple choice grid”: un skill por fila y un nivel por columna (teníamos en total 5 niveles). Separar el formulario por secciones, ya que no solo mapeamos skills sino también el nivel de uso de herramientas, las industrias en las que tenían experiencia, sus intereses en cuanto a los tipos de proyectos en los que querían participar, y su preferencia por formatos de aprendizaje. Esto hizo que la evaluación sea mucho más rica y nos brinde mayor claridad para realizar acciones de desarrollo de talento y de asignación de proyectos.

Por otro lado, tuvimos un trabajo manual en cuanto al traslado de todo ese input de un spreadsheet al Airtable. Y luego empezó lo más interesante que es armar los dashboards que usarían, sobre todo, los miembros del Team Design. Principalmente, usamos la funcionalidad de “Interface” donde se pudo reprensentar el listado de todos los diseñadores y al seleccionarlos ver el perfil de cada uno, incluyendo todo el detalle mencionado:

Por otro lado, y es aquí donde recibimos el apoyo de los CSM de Airtable, desde un punto de vista de Team Design se necesitaba también visualizar la data de manera inversa: buscar no solo por diseñador sino buscar por skill (por ejemplo, quiénes son los que tienen más de 3 estrellas en determinada skill). Aún estamos en WIP de esta sección ya que ha involucrado el uso de Apps y Automatizaciones, funcionalidades que no he explorado mucho aún.

Para esto, es importante no solo ponernos en el escenario de cómo se usa la data hoy sino la proyección que tengamos para ella. Hoy nos puede funcionar muy bien para esta etapa, pero qué pasa cuándo:

  • Ingresa un nuevo miembro al equipo, ¿necesida completar el Google Form? ¿podemos hacer la auto-evaluación desde el Airtable?
  • Tenemos que actualizar algún skill porque tiene el diseñador un nivel diferente, ¿tiene acceso al Airtable para editar esa skill? ¿necesita completar todo el formulario de nuevo?
  • Se va un diseñador del equipo, ¿automáticamente se borra de la base de datos? ¿necesitamos borrarlo o lo almacenamos?
  • Según la cadencia definida, hacer otra evaluación a todo el equipo, ¿necesitamos guardar el histórico de los niveles de todos los skills?

Los resultados

Este proyecto lo pusimos en ejecución a finales del 2022, y aún no hemos podido observar todos los beneficios que puede estetraer, sin embargo, si tenemos un indicador que rápidamente se ha movido que es con respecto a la búsqueda de perfiles para proyectos desde la perspectiva de Team Design.

Involucrados en la consulta:

  • Antes: Tenían queconsultarle a al menos 2 personas (un Director Creativo y el diseñador en cuestión) sobre los skills de un diseñador.
  • Ahora: Ingresar al Airtable, filtrar y conseguir la info que busca sin depender de otras personas ni interrumpir sus labores.

Tiempo de demora:

  • Antes: Entre 3 días e incluso 1 semana (si el diseñador se encontraba de vacaciones) para validar si contaba con cierta skill y su nivel actual.
  • Ahora: Solo le toma minutos en la búsqueda con los filtros habilitados y los diferentes dashboards creados.

Este es un claro ejemplo de cómo una iniciativa de DesignOps no beneficia solo al equipo de diseño sino a otros stakeholders.

Algunos aprendizajes

Como todo en esta vida, hay cosas que se pudieron hacer mejor, oportunidades de mejora, que definitivamente han servido para aprender. No me los guardo, sino que decido compartirlos para aquellos que se encuentren pasando por un reto similar en sus equipos.

  • Comunicar correctamente a los diseñadores el propósito de esta iniciativa para generar un sentido de urgencia y responsabilidad. Que prioricen realizar esta auto-evaluación y que sean muy consientes del puntaje que ellos mismos se otorgan.
  • Compartir la leyenda de lo que significa cada nivel para no generar dudas en los diseñadores y que ellos sean capaces de auto evaluarse sin tanta duda.
  • Hacer una revisión junto a los líderes de las respuestas obtenidas ya que podrían haber personas que se otorgan puntaje más bajo de lo que deben (usualmente los más seniors) o puntajes más altos de lo que realmente poseen (usualmente los más juniors).
  • Dejar en claro que esta no es una competencia, no buscamos juzgar el nivel de nadie ni buscamos comparar a los diseñadores por las respuestas dadas.
  • Capacitar a quienes van a usar la herramientas. Ellos no han sido los creadores de esto y puede que no usen tanto el Airtable, en este caso. Para que sean ellos independientes y le vean el valor a lo contruído deben saber usarla.

--

--