Los primeros días como lead de diseño en WordPress.com fueron complicados.
Rápidamente me di cuenta de que mi rol había cambiado completamente, y que difícilmente volvería a tener tiempo para pasarme jornadas enteras diseñando.
Cuando empecé, en diciembre de 2024, escribí sobre cómo planteaba mis primeros 30, 60 y 90 días.
Esto es lo que ha cambiado para mí, lo que he aprendido por el camino, y por qué el rol me gusta (pese a diseñar menos).
1. Liderar es ver el producto entero
Enseguida descubrí que lo más importante era entender la unidad de negocio: cuál era la situación actual, qué objetivos teníamos y qué proyectos estaban en marcha. También necesitaba saber qué proyectos llegarían en el futuro, porque pasé a ser la persona encargada de dimensionar y organizar un equipo de diseño.
Mi día a día pasó de Figma y proyectos muy concretos a una cantidad ingente de información que debía procesar, ordenar y conectar. No es lo mismo trabajar en uno o dos proyectos que tener visión sobre unos diez para ayudar al responsable de producto y al de ingeniería a darles forma y a priorizarlos.
De repente me vi rodeada de métricas, lenguaje de negocio y mucha más responsabilidad: todo el mundo me pedía (y me pide) opinión sobre detalles de los proyectos. Eso significa que la valoran, pero también que tengo que entrar «dentro» de cada proyecto para dar feedback, a la vez que lo conecto con otros que están pasando en otra parte de la unidad de negocio.
Tuve que aprender a soltar y a hacerle entender a mi ego que yo ya no soy la persona que tiene el conocimiento profundo de un área concreta.
2. Entender al equipo es crucial
Una de mis máximas es «las personas van por encima de los proyectos». Sin las personas no existen los proyectos: por mucho que haya una fecha de entrega, si la persona que está trabajando en el proyecto no está bien, no saldrá. O no saldrá lo mejor que esa persona sabe.
Hay que entender y cuidar al equipo, defenderlo cuando es necesario y darle feedback cuando hay algo que podría mejorar.
Pronto vi que la relación que tenía con ellos ya no era de igual a igual: con el cambio de rol, inevitablemente me veían «con más jerarquía». Me senté (virtualmente) con cada uno para comprender qué les bloqueaba, qué les interesaba, cómo diseñaban y de qué manera preferían recibir feedback.
Gracias a esas conversaciones y a nuestros 1:1 regulares, ahora entiendo mejor cómo reacciona cada persona. Sé ver (casi siempre) cuándo alguien está estresado, enfadado o contento, e intento asignarle proyectos que tengan coherencia con sus objetivos y con hacia dónde quiere crecer en su carrera.
3. Lo que escribo ha cambiado
En Automattic todo pasa por escrito. Hasta la guía de bienvenida, que es pública, lo deja claro: «Communication is oxygen». El trabajo se comparte en P2 (nuestros blogs internos), y de por qué escribir importa tanto ya hablé en escribir para pasar a senior.
Pero mis P2 ya no son tanto de «he hecho este diseño para este proyecto». Ahora propongo cambios, experimentos e ideas a nivel de negocio.
Por ejemplo, flujos que detecto que no funcionan bien porque se diseñaron alrededor de un requisito técnico. En lugar de resolverlo desde el lado técnico, hace años se diseñó una solución temporal que crea una UX que no es positiva para los usuarios y muchos tíquets en soporte. ¿Funciona? Técnicamente sí, pero puede mejorarse.
Son propuestas en las que necesito alinear a mucha gente para que salgan adelante, en una empresa de unas 1.300 personas donde mi unidad de negocio es la parte más grande. Y no es lo mismo compartir un enlace de Figma o un prototipo que un escrito que contiene tu razonamiento, basado en datos objetivos, y la propuesta final para convencer a otros stakeholders.
Cuando cambié de individual contributor a liderar el equipo de diseño, alguien que ya tenía esa posición en ingeniería me dijo que a partir de ese momento mi voz tendría más peso.
En su momento no lo entendí, porque yo no tenía previsto cambiar cómo me comunicaba. Lo que sí cambió es cómo los demás leen lo que escribo o escuchan mis propuestas.
4. La calidad ya no depende solo de mí
Me costó mucho, y a veces me sigue costando, aceptar que el valor de mi trabajo no está en lo que yo produzco. El valor de mi trabajo es la suma de todo lo que hace mi equipo.
Si lo hago bien, la experiencia de usuario en WordPress.com será buena, y las métricas que buscamos impactar mejorarán. También habrá menos bugs visuales y, en resumidas cuentas, todo tendrá mejor calidad.
¿A qué me refiero cuando hablo de calidad? A que los flujos, y cada interfaz por separado, utilicen los mismos componentes, patrones y estándares. Que los textos estén escritos con el mismo tono y estilo, y que todo esté bien conectado.
Y esto, lo creas o no, es muy difícil cuando trabajas con siete personas.
Te pongo un ejemplo: en WordPress.com, la interfaz para buscar un dominio aparece en el onboarding, pero también en algunos flujos de upgrade dentro del panel de control. El diseñador que trabajaba en ella estaba bastante aislado (en parte por las zonas horarias, que en una empresa distribuida pesan más de lo que parece).
Le sugerí que mirara el flujo completo, incluido el onboarding, que es responsabilidad de otra diseñadora. No lo hice para evitar trabajo duplicado, sino por calidad. Nadie usa la pantalla de dominios por sí sola: llegas a ella desde algún sitio y sigues hacia otro.
Al final lo trabajó coordinado con ella, y el resultado quedó más alineado con los pasos anteriores y posteriores del onboarding.
Apuntes finales
Diseño mucho menos que antes. Ahora mi día a día es entender el negocio, conectar proyectos, cuidar al equipo y velar por la calidad de todo lo que sale.
Y eso es lo que me gusta del rol: el resultado ya no depende de lo que yo diseño, sino de lo que consigue todo el equipo. Esto es, quizás, lo más difícil y lo que todavía me cuesta soltar:
Con todo esto, la gran pregunta es: ¿sigo siendo diseñadora? Yo creo que sí: la diferencia es que mi día a día ha cambiado, pero sigo siendo responsable de los flujos, la calidad, los usuarios y, en resumidas cuentas, del diseño.
