Refreshed brand

Aquí cuento el desafío y la experiencia de liderar al equipo de diseño de PedidosYa para investigar, evaluar, crear, comunicar, transmitir y aplicar un brand actualizado en una empresa ya sólida e instaurada.

El final, al principio

El refreshed brand fue lo primero que decidí hacer cuando entré en PedidosYa y fue una de las experiencias más desafiantes, lindas y complejas que he pasado en mi vida profesional, dado que necesitaba definir una marca y lo quería hacer de forma colaborativa con personas que ni siquiera se conocían entre sí (y de distintas especializaciones y roles), con modelos de trabajo que poco tenían en común, en una empresa que es una locomotora que no para y, para sumarle más complejidad, todo esto fue sumado a las responsabilidades diarias que ya tenían los equipos. Y lo más complicado es que para este proceso no había nada escrito; no hay manuales ni cursos. Tuve que basarme en mis conocimientos, planificación y, más que nada, mi percepción. Y, como en todo, iterar, iterar e iterar. Pero puedo decir que fue un éxito.

Una cosa es el rebrand, otra el brand evolution.
Pero, ¿a qué me refiero con refreshed brand?

Por lo tanto decidí en primer lugar investigar, buscar y encontrar una marca actualizada, más moderna, con reglas claras, con conectividad y escalabilidad. Al final del proceso quería que todos tuviéramos claro todo lo referente a la marca: desde el onboarding de un empleado que tiene su primer día en PeYa (así se le dice internamente a la empresa) hasta la experiencia de usuario, el launcher de la app, un MUPI en la vía pública, o cómo debería contestar PeYa un tweet. Todo debería partir de lo mismo.

Trabajar en esto fue el paraíso para mí. Nunca disfruté tanto mi trabajo y me sentí tan en mi ambiente como durante este proceso.

En primer lugar, me di cuenta de que los diseñadores no se conocían. O sea, se conocían los de un mismo departamento (por ejemplo, los de Producto), pero no tenían relación con los de Marketing, Back Office ni Recursos Humanos. Decidí hacer reuniones de introducción de cada uno (llegaron a ser 18 diseñadores cross-company), con dinamismo y creatividad para que nadie se sintiera con vergüenza o juzgado. Ahí comenzó todo a pulir de a poco el trabajo en equipo.

Aunque el Head Of Design tiene la decisión final, esa decisión debe ser de algo que armemos entre todos. Y 'entre todos' no significa solo los diseñadores, por lo que invitamos a algunas reuniones a personas clave de recursos humanos, a product owners, desarrolladores, agile coaches, recepcionistas, c-levels y otros. La idea era hacer una especie de Design Thinking global para saber el estado de nuestra marca, la percepción de cada uno, escuchar las distintas ópticas y empoderarnos entre todos con un mismo propósito.

Cuando ingresé a PedidosYa el objetivo principal que me autoasigné fue investigar, alinear, aplicar y visibilizar la marca cross-company. Pero a los pocos días de estar en la empresa noté que el principal problema era que no había marca. Sí, había un pdf con el imago-logotipo y el color rojo corporativo, pero… nada más.

Research y current status

En las reuniones de investigación, cada uno de los diseñadores llevaba las piezas, screens o lo que fuere en la que estuvo trabajando en el pasado y en el presente. Así fuimos forjando una montaña de cientos de piezas. ¿Qué conseguimos con esto? Visibilizar la falta de marca, la falta de reglas, la falta de patrones de usabilidad, de cromatismo, de tono de voz y lenguaje hacia el usuario/receptor, entre varias inconsistencias más.

Como dato anecdótico, encontramos 4 tipos de calls to action para lo mismo (un e-mail de marketing tenía uno naranja, ese mismo en la app era rojo, en la web bordeaux, y en las redes sociales, transparente), 21 distintos tipos de grises claros solo para las app, 11 tipos de rojos, 5 tipografías a merced del diseñador asignado, distintas aplicaciones del logotipo en las que ni siquiera se respetaba la safe-zone, textos con colores que no pasaban el nivel A de accesibilidad (mi idea inicial era llegar al AA), y varios temas más. La brecha era aún más grande cuando se contrastaba un departamento con otro.

Puesta a punto

Luego de esta investigación, en conjunto y visible para todos, vimos frente a nuestros ojos el estado de nuestra marca, por lo que escribimos entre todos un manifiesto de qué es lo que había y a dónde queríamos llegar. Todos formamos parte de esto, todos fuimos un eslabón en este reinicio de definición de la marca.

Definición de atributos

Desde el inicio supe (por el negocio en sí) que no se quería hacer un rebrand, por lo que lo que debíamos hacer era alinear y actualizar nuestra marca. Pero, ¿con base en qué? Para esto, a través de distintos workshops, decidimos definir atributos de la marca que queremos transmitir. Este proceso llevó unas cuantas reuniones y el equipo designado era, además de los diseñadores, distintas personas clave de la empresa y también externas. Los atributos fueron nuestra columna vertebral: en cada sesión y en cada rincón de la oficina estaban plasmados a través de posters, cubos 'mágicos' y merchandising.

“Consistencialización“ y estandarización corporativa

Luego de definir los atributos, y tomándolos como base, comenzamos a crear reglas 360 de nuestra marca, a lo que llamamos ‘marca paraguas'. Armamos sesiones para definir distintos aspectos de la marca. Hubo talleres para definir reglas de uso del imagologotipo, tipografías corporativas, paleta cromática, iconografía, elementos visuales, ilustraciones, patrones, tono de voz, estética, tratamiento fotográfico... Creamos key visuals de a dónde queríamos ir cómo app, como experiencia de usuario, como campaña publicitaria, cómo comunicación.

Lo desafiante de esto era cómo hacer que una marca se impacte en todo: que si un usuario usa la app sienta que está en la misma atmósfera que si ve una gigantografía en la carretera.

Un tema no menor fue la puesta a punto entre los equipos sobre la taxonomía y ‘bautismo' de los distintos elementos corporativos. O sea, para que todos habláramos el mismo idioma, entre todos le pusimos nombre a cada elemento. Así, si uno le comunica a otro 'para este copy usá la tipografía primaria', ya sabemos que debe usar la Texta Alt. O si comentan 'usá el color Pink para ese patrón web', ya se sabe que debe usar el valor #F77EE9.

Entre tipografías, abogados y leyes

Sobre la definición de la tipografía se debería escribir todo un capítulo aparte, pero aquí voy a resumirlo: hicimos un montón de reuniones entre todos para ver, basados en los atributos definidos, cuál debía ser la tipografía corporativa. Luego de varias búsquedas, discusiones acerca de la legibilidad, la accesibilidad, la personalidad, de cuál 'a' se adaptaba más a nuestros propósitos; después de varios talleres y dinámicas de testeo, llegamos a dos tipografías que queríamos (una primaria y una secundaria).

Pero hubo un pequeño problema: la parte legal. Luego de investigar nos dimos cuenta de que PedidosYa debía pagar U$S 5.000 si decidía usar la tipografía elegida como primaria en la app, lo cual no tenía sentido. Pero ya nos habíamos enamorado y queríamos sortear este problema de alguna forma, por lo que decidimos usar esa tipografía en la parte gráfica (que implicaba un costo mucho menor), para lo que funcionaba a la perfección, y buscar una tipografía 'hermana' para la app.

Logramos dar con la hermana perfecta: una tipografía para los elementos digitales que, a simple vista, para un ojo estándar, no tenía diferencia con la otra. La razón por la que no usamos la tipografía elegida para la app en todo lo demás es porque hicimos varios estudios, testeos y relevamientos y nos dimos cuenta de que en las piezas gráficas, sobretodo en las de gran tamaño, la calidad y homogeneidad de esa tipografía no era óptima: se perdía calidad en el trazo de los nodos, la forma orgánica, la suavidad.

A partir de esto pudimos creamos reglas claras, simples y concisas para el uso de las tipografías.

Reglamentación y visibilidad transaccional

Luego de definir las características de la marca y la comunicación, comenzamos a producir los guidelines para cada clasificación. Hubo un manual de normas general para todo (logotipo, tipografías, colores, elementos, tono de voz, fotografía) y se hicieron varios más de acuerdo a las distintas necesidades de aplicación: hubo para producto (apps y website), back office (partner portal), e-mail marketing (newsletters), CRM, out of home, third-parties, recursos humanos... También creamos templates para la suite corporativa de Google con todos los elementos: Google Slides, Google Docs, Google Templates, Google Forms y manuales y videotutoriales de cómo es su uso, entre otras cosas.

Además creamos un banco de recursos con los distintos assets: logotipo en distintas aplicaciones y formatos (positivo, negativo, horizontal, vertical, vectores, bitmaps), imágenes, elementos, swatches para ser descargados con los colores corporativos (hexadecimal, RGB, RGBA, HSL, CMYK, PANTONE), tipografías y demás. Creamos un brand site corporativo con toda la información, assets, Design Systems, manuales, etcétera.

El siguiente paso era el de comunicar, capacitar y visibilizar todo este nuevo refresh para toda la empresa. Es por esto que, para ciertos sectores, se crearon workshops y distintos tipos de comunicación para promoverlo. Lo promocionamos a través de nuestra herramienta corporativa oficial Workplace (Facebook for business), newsletter informativo referenciando al brandsite, mensajes pinneados de Slack, y agregamos todos estos links a la barra de bookmarks de Google Chrome para los +2000 empleados (recurrimos a Infraestructura para que todos tuvieran esto visible y oficial).

También, por equipo de diseñadores por departamento, elegimos un mentor o un evangelizador de la marca (era optativo) para que fuera un referente para consultas o dudas (aunque todos tenían claro cómo era la marca porque, de hecho, la formaron ellos).

Feedback and requests

Creamos distintas instancias para tener feedback, reportar errores o petición de agregados y otras necesidades que surgieran. Creamos canales en Slack, enviamos formularios a toda la empresa pidiendo feedback y fuimos midiendo su recepción. Además, en nuestro brandsite trackeamos las visitas a través de Google Analytics y la descarga de los distintos documentos para ver su evolución. Entrevistamos a personas para ir testeando y midiendo y viendo de forma cualitativa las necesidades o nuevas ideas a agregar. Y, como todo, se fue iterando.

Aplicando el refresh

Una de las cosas que teníamos claras era que este refresh debía aplicarse tanto a la parte interna (in-house) como a la externa (usuarios y público). Y una de las problemáticas que nos surgió fue la de aplicarlo en piezas o productos, frameworks y procesos que venían de hace años (por ejemplo, la app). La solución a esto fue simple: dividir para conquistar. Es decir, lo fuimos ejecutando por los distintos departamentos de la empresa, y en cada uno customizamos el proceso de acuerdo al contexto y las necesidades (no es lo mismo comenzar a partir de ahora una campaña gráfica que cambiar todo el flow de la app).

En Producto

Internamente no se podía aplicar el refresh de la noche a la mañana, dado que además de factores de estrategia de negocio y percepción del usuario había un tema importante: el técnico. Los desarrolladores de la app y de la web ya venían focalizados en una deuda técnica extensa y agregarle un factor más, y de esta magnitud, sería algo contraproducente. Por lo que este proceso lo hicimos a lo ‘baby steps’ (paso a paso) y lo dividimos en 3 etapas:

‘La blanqueada’ (así la bautizamos)
La app visualmente no se actualizaba desde hacía tiempo y se veía vintage. En mi opinión tenía un fondo gris no lo suficientemente claro o suave que hacía que pareciera un diseño de los 90 (en el research nos dimos cuenta de que se usaban 21 distintos tipos de valor hexadecimal), y necesitábamos una renovación de todo pero primeramente de esto. Y fue lo que se hizo de inmediato: previa entrevista con usuarios para medir su percepción cualitativamente, pasamos todos los fondos a blanco.

Cada uno de estos cambios se realizó según release y fue cuidadosamente trackeado, monitoreando el comportamiento de las visitas a través de métricas, opiniones en las redes sociales, feedback en las app stores, cuidando que no aumentaran los drop off y midiendo su uso.
Atomic, UI Kit & Design System
Para los diseñadores de Producto y Tecnología diseñamos un inmenso Design System en Sketch con cada uno de los colores, elementos, componentes y screens para cada uno de los sistemas, para que cada pantalla del flow se renovara con estos elementos. Los primeros meses el archivo fuente lo tenía yo en mis manos y era el único que lo podía modificar. De raíz creamos todos estos componentes y, a medida que precisábamos escalar y expandirlo, lo íbamos haciendo colaborativamente solicitando nuevos elementos y viendo entre todos si era necesario crearlo o si se podía reutilizar otro ya existente.

El diseñador, cuando tenía que crear una nueva user-story o una pantalla simple, tenía que linkear esta biblioteca y tomar los elementos de ella. De modo que, si en un futuro, por alguna razón, se debía modificar de raíz un text field, por ejemplo, yo (o alguien a quien le asignara esta tarea) modificaba el archivo fuente y, automáticamente, se actualizaba en todos los archivos donde estuviera utilizado. Recreamos de cierta forma una especie de SaSS pero para diseñadores, en que cada elemento sería para lo que es a SaSS una variable.

Para realizar este Design System investigamos y acordamos cómo iba a ser la arquitectura de la información para que los componentes/símbolos pudieran ser encontrados fácilmente por los diseñadores (por ejemplo: / iOS / Elements / Text field / Active). Por supuesto que lo hicimos con la filosofía de Atomic Design y para todos los tipos de devices: cada componente estaba configurado para abarcar el ancho de los distintos celulares sin perder las proporciones (cada elemento estaba cuidadosamente pensado para que fuera escalable).

También creamos en Zeroheigh el Design System de Producto con cada elemento, componente y pantalla con toda la documentación de sus usos, cómo usarlo, cómo no, valores, etcétera. Esto quedaba linkeado a Sketch, por lo que se mantenía actualizado por cada cambio que se hiciera.

Luego de varios meses de trabajo, y una vez aceitado el proceso, cambiamos el archivo fuente para que fuera colaborativo por todos los diseñadores y quedara todo documentado en Abstract para tener distintas versiones y ramas (branches), poder hacer commit, pushear y que el responsable final aprobara o no dicho cambio o agregado.
Componentización en Dev
Nos juntamos con los líderes de desarrollo de iOS y Android y con los product owners y mostramos el UI Kit para comenzar a trabajar de la misma forma con ellos. Es decir, ellos debían crear una librería de recursos que fuera compartible entre los desarrolladores para poder reutilizar los elementos y, en el caso de que se modificara alguno, este fuera automáticamente impactado en la app/web. Fue exactamente la misma filosofía que empleamos los diseñadores.

Para el flow y las pantallas en sí, lo que hicimos fue bajar toda la aplicación en 38 módulos de tamaños y tiempos de esfuerzo equilibrados. Los dividimos para trabajar en 3 equipos y en 6 releases (cada 3 semanas hacíamos un release) con incluso AB testings para ir probando y testeando los roll-outs. Conclusión: subimos 1 punto en la conversión.

Más información

Disyuntiva aparte con las apps
Tuvimos que evaluar desde la perspectiva del usuario y por supuesto la parte técnica, la posibilidad de dejar ser sistemas nativos para ser uno general para ambos tipos de dispositivos pero respetando siempre los elementos, flujos, componentes, modelos mentales y patrones naturales de cada sistema (por ejemplo: el ícono de compartir para iOS debía ser el de iOS y el de Android el suyo propio para no provocar incertidumbre o duda en el usuario). O sea, la idea era pasar todo a React pero evaluando el tiempo de esfuerzo técnico, se optó por continuar siendo nativos y paralelamente ir desarrollando un planning para pasar todo a react.

Se podría decir que en Marketing el proceso fue más simple: la idea era que, a partir de cierta fecha, toda pieza iba a salir ya con el brand refreshed, pero siempre teniendo en cuenta que si en esa pieza hay elementos que en Producto todavía no se lanzaron y que son en común (iconografía, por ejemplo), entonces se esperaba a que se lanzara el release de la app para coincidir con la naturaleza de la pieza de Marketing. Se podría decir entonces que el refresh Marketing estuvo atado a los releases de Producto. Lo importante era la sincronización de los productos y los departamentos (un lindo trabajo en equipo).

Como ejemplo, antiguamente los e-mail marketing tenían el call to action (CTA) en naranja. A partir del refresh este pasó a ser rojo corporativo PeYa. Pero para estrenar el CTA rojo primero había que estar seguro de que el CTA de la app/website estuviera ya lanzado (o sea, a la vista del usuario) para que hubiera consistencia (no tenía lógica que el usuario leyera el e-mail, ingresara a la app y viera otro color del mismo CTA). Esta fue una tarea que requirió una prolijidad extrema, planificación y transparencia entre equipos para estar completamente comunicados y sincronizados. Al mismo tiempo sirvió para compartir conocimientos entre equipos sobre cómo trabajar y empatizar con las necesidades laborales de otros roles y, ante todo, trabajar en equipo en pos de un mismo objetivo: una misma marca. Esto se fue haciendo con los e-mails marketing, out of home, campañas en la televisión, redes sociales y demás.

En Marketing

CRM y un exitoso cambio
Paralelamente, y en pos de lograr aceitar y potenciar el refresh en CRM, el diseñador encargado de todo lo referente a CRM propuso migrar nuestro sistema de envíos de e-mail (marketing, transaccionales, etcétera), que era bastante antiguo, a uno nuevo llamado BeePro. Esto facilitó y ahorró un montón de tiempo y horas de esfuerzo: realizamos nuevos layouts para cada categoría, customizamos colores, fuentes, modos de uso, tutoriales, y, al mismo tiempo, por su versatilidad y simpleza, ya no tenía que encargarse solo una persona con conocimientos de codificación y mark-up de estos tipos de piezas, lo que hacía un efecto embudo sin sentido. Esto aceitó, facilitó y ayudó en los tiempos y en la producción.

En Recursos Humanos y demás departamentos

Teniendo y evangelizando nuestro refreshed brand en todo PedidosYa, fue simple la transición. Todos los equipos se basaron principalmente en nuestra fuente de datos que era nuestro Brand site, por lo que desde ahí se podían crear presentaciones con nuestra marca, hojas membretadas, firmas de e-mails, o directamente descargar nuestra iconografía e ilustraciones.

Y por supuesto que estaba a disposición todo tipo de manual de normas dependiendo el uso de la marca. Y si faltaba alguna documentación o algo que no hubiera sido claro o ignorado, siempre teníamos la opción de expresar el punto de vista de quien formara parte de PedidosYa.