Refreshed brand
Here I share the challenge and experience of leading the PedidosYa design team to research, evaluate, create, communicate, transmit, and implement an updated brand in an already solid and established company.
The end, at the beginning
The refreshed brand was the first thing I decided to do when I joined PedidosYa, and it was one of the most challenging, beautiful, and complex experiences I've ever had in my professional life. I needed to define a brand, and I wanted to do it collaboratively with people who didn't even know each other (and from different specializations and roles), with work models that had little in common, in a company that's a nonstop engine. To add to the complexity, all of this was added to the daily responsibilities the teams already had. And the most complicated thing is that for this process, there was nothing written down; there are no manuals or courses. I had to rely on my knowledge, planning, and, above all, my perception. And, as with everything, iterate, iterate, and iterate. But I can say it was a success.
Rebranding is one thing, brand evolution is another. But what do I mean by refreshed brand?
So I decided to first research, search for, and find an updated, more modern brand with clear rules, connectivity, and scalability. By the end of the process, I wanted everyone to be clear about everything related to the brand: from the onboarding process for an employee on their first day at PeYa (as the company is known internally) to the user experience, the app launcher, a public MUPI, or how PeYa should respond to a tweet. Everything should be based on the same foundation.
Working on this was heaven for me. I've never enjoyed my job so much and felt so at home as I did during this process.
First, I realized that the designers didn't know each other. That is, they knew each other from the same department (for example, Product), but they had no relationship with Marketing, Back Office, or HR. I decided to hold introductory meetings for each of them (there were eventually 18 cross-company designers), with a dynamic and creative approach so that no one would feel embarrassed or judged. That's when the teamwork began to gradually develop.
Although the Head of Design has the final decision, that decision must be something we all put together. And "all together" doesn't just mean designers, so we invited key people from HR, product owners, developers, agile coaches, receptionists, C-levels, and others to some meetings. The idea was to conduct a kind of global Design Thinking session to understand the state of our brand, everyone's perception, listen to different perspectives, and empower each other with a shared purpose.
When I joined PedidosYa, the main objective I set for myself was to research, align, implement, and make the cross-company brand visible. But after a few days at the company, I realized the main problem was the lack of branding. Yes, there was a PDF with the logo and the corporate red color scheme, but… nothing more.
Research and current status
At the research meetings, each designer brought the pieces, screens, or whatever they'd been working on in the past and present. Thus, we built up a mountain of hundreds of pieces. What did we achieve with this? It highlighted the lack of branding, the lack of rules, the lack of usability patterns, the lack of color schemes, the lack of tone of voice and language for the user/receiver, among several other inconsistencies.
As an anecdote, we found four types of calls to action for the same purpose (one marketing email had an orange one, the same one in the app was red, burgundy on the website, and transparent on social media), 21 different types of light grays for the apps alone, 11 types of red, five fonts at the discretion of the assigned designer, various applications of the logo that didn't even respect the safe zone, texts with colors that didn't pass the A accessibility level (my initial idea was to reach AA), and several other issues. The gap was even wider when comparing one department with another.
Tuning
After this research, together and visible to everyone, we saw the state of our brand before our eyes, so we all wrote a manifesto outlining what we had and where we wanted to go. We were all part of this; we were all a link in this brand redefinition.
Definition of attributes
From the beginning, I knew (based on the business itself) that we didn't want to rebrand, so what we needed to do was align and update our brand. But based on what? To do this, through various workshops, we decided to define the brand attributes we wanted to convey. This process took several meetings, and the designated team included, in addition to the designers, various key people from the company and external sources. The attributes were our backbone: in every session and in every corner of the office, they were captured through posters, magic cubes, and merchandising.
“Consistency” and corporate standardization
After defining the attributes and using them as a foundation, we began creating 360-degree rules for our brand, which we called the "umbrella brand." We held sessions to define different aspects of the brand. There were workshops to define rules for using the logo, corporate fonts, color palette, iconography, visual elements, illustrations, patterns, tone of voice, aesthetics, and photography. We created key visuals for where we wanted to go as an app, as a user experience, as an advertising campaign, and as a communication tool.
The challenge here was how to make a brand impact everyone: so that if a user uses the app, they feel like they're in the same atmosphere as if they saw a giant poster on the highway.
A significant issue was the team's coordination of the taxonomy and "branding" of the various corporate elements. In other words, to ensure everyone spoke the same language, we all named each element. This way, if one person tells another, "Use the primary font for this copy," they already know they should use Alt Text. Or if they say, "Use the color Pink for that web template," they already know they should use the #F77EE9 value.
Between fonts, lawyers and laws
A whole chapter should be written about defining the typeface, but I'll summarize it here: we held a series of meetings to determine, based on the defined attributes, what the corporate typeface should be. After several searches, discussions about legibility, accessibility, personality, and which "a" best suited our purposes; after several workshops and testing sessions, we settled on two desired typefaces (a primary and a secondary).
But there was a small problem: the legal aspect. After some research, we realized that PedidosYa had to pay US$5,000 if it decided to use the chosen font as the primary font in the app, which didn't make sense. But we were already in love with it and wanted to get around this problem somehow, so we decided to use that font for the graphics (which involved a much lower cost), for which it worked perfectly, and look for a "sister" font for the app.
We managed to find the perfect sister: a typeface for the digital elements that, at first glance, to a standard eye, was indistinguishable from the other. The reason we didn't use the typeface chosen for the app for everything else is because we conducted several studies, tests, and surveys, and we realized that in the graphic pieces, especially the large ones, the quality and consistency of that typeface wasn't optimal: quality was lost in the node strokes, the organic shape, and the smoothness.
From this we were able to create clear, simple and concise rules for the use of fonts.
Regulation and transactional visibility
After defining the brand and communication characteristics, we began producing guidelines for each classification. There was a general standards manual for everything (logo, fonts, colors, elements, tone of voice, photography), and several more were created according to the different application needs: some for the product (apps and website), back office (partner portal), email marketing (newsletters), CRM, out-of-home, third-party, human resources... We also created templates for Google's corporate suite with all the elements: Google Slides, Google Docs, Google Templates, Google Forms, and manuals and video tutorials on how to use them, among other things.
We also created a resource bank with various assets: logos in different applications and formats (positive, negative, horizontal, vertical, vectors, bitmaps), images, elements, swatches for download with corporate colors (hexadecimal, RGB, RGBA, HSL, CMYK, PANTONE), fonts, and more. We created a corporate brand site with all the information, assets, design systems, manuals, and more.
The next step was to communicate, train, and make this new refresh visible throughout the company. That's why, for certain sectors, workshops and different types of communication were created to promote it. We promoted it through our official corporate tool, Workplace (Facebook for Business), an informative newsletter referencing the brand site, Slack pinned messages, and we added all these links to the Google Chrome bookmarks bar for the more than 2,000 employees (we turned to Infrastructure to make this visible and official for everyone).
Also, per team of designers per department, we chose a mentor or brand evangelist (it was optional) to serve as a point of contact for questions or concerns (although everyone was clear about what the brand was like because, in fact, they were the ones who created it).
Feedback and requests
We created different channels to gather feedback, report bugs, request additions, and address any other needs that arose. We created Slack channels, sent forms to the entire company asking for feedback, and measured their reception. Additionally, on our brand site, we tracked visits through Google Analytics and the download of various documents to monitor their progress. We interviewed people to test and measure, and qualitatively identify needs or new ideas to add. And, like everything, we iterated.
Applying the refresh
One of the things we were clear about was that this refresh had to be applied both internally (in-house) and externally (users and the public). One of the challenges we faced was applying it to components or products, frameworks, and processes that had been in place for years (for example, the app). The solution was simple: divide and conquer. That is, we implemented it across the company's various departments, and in each one we customized the process according to the context and needs (starting a graphic campaign right now isn't the same as changing the entire flow of the app).
In Product
Internally, the refresh couldn't be implemented overnight, given that in addition to business strategy and user perception factors, there was another important issue: the technical aspect. The app and website developers were already focused on extensive technical debt, and adding another factor of this magnitude would be counterproductive. Therefore, we took this process "baby steps" and divided it into three stages:
-
‘The Whitening’ (as we called it)
The app hadn’t been visually updated in quite some time and looked vintage. In my opinion, the gray background wasn’t light or soft enough, making it feel like a design from the ’90s (our research revealed the use of 21 different hex values), and it was clear we needed a complete visual overhaul—starting with this. That’s exactly what we did first: after running qualitative user interviews to gauge perception, we updated all backgrounds to white.
Each of these changes was rolled out in specific releases and carefully tracked, monitoring user behavior through metrics, social media feedback, app store reviews, and drop-off rates—making sure performance stayed stable while tracking adoption.
-
Atomic, UI Kit & Design System
For the Product and Tech designers, we created a massive Design System in Sketch containing every color, element, component, and screen variant for each system, so that every screen in the flow could be rebuilt using these standardized parts. During the first few months, I was the sole owner of the master file and the only one authorized to modify it. We built every component from scratch, and as scaling needs emerged, we expanded the system collaboratively—deciding together whether new elements were needed or if existing ones could be reused.
Whenever a designer had to create a new user story or a simple screen, they would link to this library and pull from it directly. This meant that if, in the future, we needed to change a component like a text field at its core, I (or someone assigned) could update the master file and it would automatically propagate across all designs where it was used. In a way, we recreated a kind of SaSS for designers, where every component acted like a variable.
To build this Design System, we first researched and aligned on the information architecture so that components and symbols could be found easily by anyone (e.g., / iOS / Elements / Text field / Active). Naturally, we followed Atomic Design principles and made sure components were responsive across devices—each element was carefully crafted to be scalable without losing proportions.
We also built out the Design System in Zeroheight, documenting each component, screen, and usage rule—how to use it, how not to, values, etc. This documentation was linked to Sketch, so it stayed up to date with every change.
After several months of refining the process, we made the master file collaborative across all designers and documented everything in Abstract, enabling version control with branches, commits, and approvals for proposed changes.
-
Componentization in Development
We met with iOS and Android development leads, along with product owners, to present the UI Kit and propose that they adopt the same approach. The goal was for them to build a shared library of reusable resources—so that any component update would automatically reflect across the app or web, just like in design.
For the app flow and screens, we broke down the entire application into 38 modules, each scoped for balanced effort and size. We divided the work across three teams and six releases (one every three weeks), even running A/B tests to validate and refine each rollout.
The result: we increased conversion by 1 point.
More information
The dilemma aside with the apps
We had to evaluate, from the user perspective and of course the technical side, the possibility of moving from native systems to a general one for both types of devices, while always respecting the elements, flows, components, mental models, and natural patterns of each system (for example: the share icon for iOS should be the iOS one and the Android one its own so as not to cause uncertainty or doubt in the user). In other words, the idea was to move everything to React, but evaluating the time involved in the technical effort, it was decided to continue being native and, in parallel, develop a plan to move everything to React.
You could say that in Marketing, the process was simpler: the idea was that, after a certain date, every piece would be released with the brand refresh, but always keeping in mind that if that piece included elements that hadn't yet been released in Product and that were shared (iconography, for example), then we waited until the app release to coincide with the nature of the Marketing piece. You could say, then, that the Marketing refresh was tied to the Product releases. The important thing was the synchronization of the products and departments (a great team effort).
For example, email marketing previously had the call to action (CTA) in orange. Since the refresh, this has changed to PeYa's corporate red. But to introduce the red CTA, we first had to ensure that the app/website CTA was already active (i.e., visible to the user) to ensure consistency (it didn't make sense for the user to read the email, enter the app, and see a different color for the same CTA). This was a task that required extreme thoroughness, planning, and transparency between teams to ensure complete communication and synchronization. At the same time, it served to share knowledge across teams on how to work and empathize with the work needs of other roles and, above all, to work as a team toward a common goal: a shared brand. This was done with email marketing, out-of-home campaigns, TV campaigns, social media, and more.
In Marketing
CRM and a successful change
At the same time, and in order to streamline and enhance the CRM refresh, the designer in charge of everything CRM-related suggested migrating our email delivery system (marketing, transactional, etc.), which was quite old, to a new one called BeePro. This facilitated and saved a ton of time and hours of effort: we created new layouts for each category, customized colors, fonts, usage modes, and tutorials. At the same time, due to its versatility and simplicity, these types of components no longer had to be handled by a single person with coding and markup knowledge, which created a pointless funnel effect. This streamlined, facilitated, and helped with timelines and production.
In Human Resources and other departments
Having our refreshed brand and promoting it throughout PedidosYa made the transition simple. All teams relied primarily on our data source, our brand site, so they could create branded presentations, letterheads, email signatures, or directly download our iconography and illustrations.
And of course, all kinds of standards manuals were available depending on the brand's use. And if any documentation was missing or something unclear or ignored, we always had the option of expressing the point of view of anyone involved with PedidosYa.
