The Journey of Rebranding 7+ Years Old App

Hello everyone. So I'm here today to walk you through the journey of rebranding seven years old app. But before I'll take you on this very exciting journey, let me introduce myself. I'm Kasia Trzemska, I'm design system tech lead for Clio, a company based in the UK.

Yeah, enough about that. So let's start the journey. And before we'll talk about rebrand itself, it's worth actually taking a look at Clio as an app and the stage of where it has been when we first started thinking about rebrand. So we are talking about pretty old app, pretty old code base, seven years is ages if you think about React community and React Native, because this is what Clio was written with. But let's talk about it in a second.

We are also talking about loads of different screens served for our users with loads of different content and features within these screens. When it comes to the architecture of Clio, at some point we successfully migrated the app over Expo, which is pretty exciting and already eases loads of things. So as already mentioned, most of the app is written with React Native, but mostly because of the fast pace Clio is moving, we also serve some of the content through React.

Yes, React in web views. And this, the funny part is actually coming, still coming. So the React app is served as a view of the MVC of Ruby on Rails. So yes, we have a pretty interesting stack. There's loads of different text and lots of different languages involved, but it worked. It worked so far. It was pretty good.

And I've mentioned fast pace, and I really mean that. Clio is moving super, super fast. We are A-B testing loads of things. So if you think about what we could potentially A-B test, we A-B test things like changes in the signup flow, for example, to understand the impact of taking off some of the screens or maybe changing the flow to a more linear kind of style, or maybe just keeping it all very simple in one form.

But we also A-B test things like changing the content of the CDA somewhere to understand, again, what a difference it does make to our users. But it brings us to some of the challenges this approach brings. So whenever you think about feature testing, you need to obviously bring in some different sides of the test. One of the sides is winning. And on top of that, we are testing another feature.

And then another side is winning. So based on this three, we are testing another feature. It actually brings us a question, what happens with this losing sides of given tests? And you would say, yeah, you should basically clean that up as soon as possible. And we did that in most cases. But sometimes, because of the holdouts, so the necessity to keep some tests running for a longer period of time, we sadly had to leave some of these dead sides of the tests, and our codebase was growing and growing because of that.

Some of the features are still in web views, which also was not perfect. So again, fast pace, sometimes we really need to test something very quickly. And I don't know if you've been building things with React Native. But if you did, you know that sometimes it takes a little bit longer to build a full flow, a full feature within a React Native comparing to React. So when we wanted to test something very quickly, we usually tested it within the web view. We also do believe that if the feature is working, if our users are happy with the feature, and there is no other reason we see that we should migrate it over to React Native, we'll keep things as it is because we prefer to spend this time on investing into user experience and building other features and improving other features that actually need our attention.

But when we took a look at some of the parts of the app, and especially thinking about the upcoming rebrand, we've noticed that there are some differences in how things look, especially in the web view. So here you can see three example screens of features served in a web view, and you can see that there are some differences within how we show icons, how we show titles and headers and CTAs. You would even say maybe not that it's not like the same app, but it looks different. What about design system? So at this stage of when I'm talking about when we started thinking of rebrand, design system was mostly a library of components, and we struggled. We struggled with a couple of different things.

So we struggled with tokens spread across web and Native as already established. We had some features being served in the web, so a completely different app, and we didn't really have universal components or tokens being shared across two different apps. Flexible components was a different thing we struggled with. So over the years, we managed to create a really nice library, but we also had some very changing requirements when it comes to our components and how we want the app to look like. And because of that, we started accepting style prop, for example, which made our components look like little monsters sometimes. We also managed to find ourselves in a situation where we, at some point, had three different color palettes living in the app and being used at the same time, which was pretty interesting.

Also, I think still worth mentioning that we found ourselves in a situation where we served typography in a couple of different styles and through a couple of different components. So, yep. We struggled a little bit. And if you look at screens of the app, you can notice that this styling is a little bit different. Depends on where you looked at. Okay, but let's move forward. So starting point. So I gave you a little bit of an overview of how the Clio looked like back in the days, but how we actually started thinking on rebrand, about what we need to do. So understanding the mess was, I think, the biggest point of planning the rebrand, planning how we can get there and how we will get there. And how we can understand the mess. So through the design system, obviously. And my understanding of the mess was to collect the data, understand where we are and how we can actually improve the situation. So I introduced a script using React scanner to crawl the codebase, which was run through GitHub Actions every day and send the data over to Redshift, which we could count and check and query through the count. And the data I'm talking about was mostly tokens and components usage.

So we had to understand where we are. And we were around 50% of components, shared components for adoption. Not bad, not good, somewhere. We were somewhere. But also keep in mind that most of these components were very, very flexible, which actually leads us to the second point. So we struggled with thousands of random magic values. I'm talking here about just using 15 as a font size somewhere, or maybe 17 somewhere else. Or maybe just setting a spacing as 11, because it just matches the design back in the day. And other defined values were just not there yet. Lots of unused screens was another big finding of ours.

Because of the run A, B tests and not always properly done cleanups, we had some dead code living in the codebase, which, you know, would be good to get rid of at some point. And that takes us to the rehab. So the big plan was to get the app to the state where rebranding is not a big deal anymore. And as I already mentioned, we had to do loads of cleanup, loads of different kinds of cleanups. We had to narrow down the number of sets of tokens from three to one. Somehow, right? I think it's worth it. Because, as you know, in engineering usually it looks like, yes, we have three different sets of tokens. Let's introduce a new good one. And now we have four different sets of tokens. This is usually how it looks like. So it's good to sometimes just do the proper cleanup and organize this chaos before moving forward. We standardized color, spacing, the typography, but also things like border, border radiuses, and other things, also shadows. Like all different kinds of styling tokens, which can come to your mind, we just organized into defined sets of tokens. We have also created an action group focused on cleaning up web views.

So here a little bit of context. We, at the stage of, you know, planning the rebrand, there were a couple of different solutions to what we want to do with web views. One of them being, for example, introducing universal components library and migrating everything to use these components. Same with tokens. Maybe just rebranding web view, sorry, the web app and the React Native app alongside. But we took a look into data again and how many of these web views we have. How big of an effort would it be to clean up web views, so basically migrate the most used ones over to React Native, because both rebranding the web and rebranding and introducing universal components library and then migrating the thousand-plus screens of Native app was a big investment. So back in the time, the best solution when it comes to effort versus impact was to clean up web views, clean up the mess, migrate everything over to Native, and this is what we've done.

The big part of preparing the code base for the rebrand was the design system communication. We really have done loads of work around communication, transparency, bringing in some processes, having some processes in place, because that was super important to establish good patterns of using design system on a daily basis, because our code base was growing every day. And obviously, we've done this whole cleanup, but we also had to think about the future, think about what happens in a week if we will not establish some good processes. First, we celebrated all of our squads adopting design system, and we really made it super public. We went to all hands with some leaderboards, because we had the design system adoption data, we also had data about which domain is owned by which squad, and through the code ownership documentation in GitHub, we also knew which of the squads are owning which of the domain. So we could build leaderboards for which squad is doing the best and which squad maybe is not doing so well. But we focused on celebrating the squads which are doing very great. We also promoted design system adoption through squad level OKRs.

Setting OKRs every term is a very big thing for at Clio. We do believe that we want to have one common goal, business goal, company goal, which every squad is working towards every term. And at some point, we managed to convince our leadership to get design system adoption as a quality OKR for every squad. That was a big, big deal and really improved the design system adoption across the whole company.

We have also tackled all of these random values spread across the whole code base. And you ask me, how? How? Not why. How we've done this. And I will say automation. Automation did the rescue and we really automated whatever the heck we could, sorry, whatever we could. We automated, I mean, not everything. There was still loads of manual work, sadly.

But for example, the typography unification, we really managed to scale the work through automation. We managed to get this working through the code mode. So as I mentioned, we use a couple of different components. For example, text with some obviously random magic value, size 15. And text component, we had our own text component implementation. But in some places, we also use text component coming directly from React Native. React Native comes with these handy components. And we used it sometimes.

And so, we decided to introduce on top of this, introduce typography component with more established way of how we want to present text in our app. So, we came with, you know, set of sizes, set of types for typography, and then mapped all of the different sizes across the app into different, into some type of typography and some size of typography. And then run code mode to do the mapping. It was super, super helpful, super fast and performant. And the only work left here for us was to run end-to-end tasks to make sure that nothing was broken on the way.

Another, I think, very worth mentioning thing which we've done, which we've used and automated, was using linting rules, loads of linting rules. We used linter and some custom rules to, you know, keep things clean, pretty much. So, whenever we, for example, deprecated a component, we introduced a linter rule to forbid using the deprecated component. We've done the same with magic values. We've done the same with, in general, not using tokens. So, we tried to not be too strict and annoying with these linter rules but find the perfect sweet spot of introducing them and making them useful to the engineers instead of annoying.

Finally, let's talk a little bit more about rebrand and the vision meets reality. So, here you can actually see finally a screen from the rebranded version of the app. Super sweet, if you ask me. I really like the new layout. Comparing to the very colorful one from the previous version. But, yeah, let's talk about meeting the reality. So, you remember me mentioning about the over a thousand of screens of Clio. And, yes, the first point of the plan was to adopt the design system. So, whether we, you know, if we will be at the stage of, okay, there we have 80% of design system adoption, if we will rebrand all of the components, all of the components, everything should just click.

And, yes, the first point of the plan was to adopt the design system. So, whether we, you know, if we will be at the stage of, okay, there we have 80% of design system adoption, if we will rebrand all of the components, all of the components, everything should just click. But also, it wasn't that simple. You still had to check every single screen if everything works and the layout is correct. And also, through the rebrand, some of the screens have changed the layout. So, we had to do a little bit more work. But a thousand screens is a lot. Even for a company as big, let's say, as Clio, so, we had to be a little bit smarter about what we want to do. And the plan was to focus on the highest traffic volume screens.

So, we manage, we have loads of data in general. At Clio, we really do trust in data. And we measure a lot. And thanks to that, we could easily understand which of the screens are visited the most by our users, which of the screens are the most important ones for our users. And we focused our efforts on these screens. So, we focused first on 200 highest traffic volumes. We are really talking about, you know, 80% of whole traffic being navigated to these screens, comparing to 20% of traffic being somewhere else. So, it really made sense back in the time to do that. We obviously spent time on rebranding the rest of the screens in the other, the second stage of rebrand.

But over there, we mostly focused on adopting design system, just using the right components, making sure everything looks right. But when it comes to the other screen, the most important screens, like the ones in here, as you can see, the rebrand was more than just using one component versus the other. Sometimes it was introducing like a brand new screen. Also, yeah, because we are A-B testing everything at Clio, we decided that we want to A-B test rebrand experience. This is a huge A-B test, if you ask me. We are basically decided to test two different, completely different experiences within one app.

And we made it happen. And there were some of the side effects of this approach. One of the biggest side effect was that we enabled product squads to work on the rebrand within their domains without, you know, just worrying that they will break some other experiences they could, thanks to A-B testing, just rebrand some of the screens that they've been working on behind a flag, and then had an easy way to just switch in between two versions, thanks to what? Thanks to Teams. That was our solution to just bring a new brand on top of existing ones, existing one.

And how we made this, how we made this happen. So, I mean, it wasn't really any complex solution. We used a very known pattern of providers in React. And we created our own team provider, which under the hood used a pretty simple hook. You can see global rebrand hook, which was returning true false kind of information. And then based on that, we used a theme and returned the theme into value of a provider. And then every component, actually, we'll talk about this in a second.

The hook itself is, the version here is a little bit simplified, but in general, we've made a query to get information from a backend if given user should see A or B side of the rebrand. And based on that, we've returned the result back to the provider. We also, at some point, introduced a local switch for the rebrand to make it easier for our engineers and also our internal users to switch in between two brands. So, the local switch was working on top of the A, B test. So, there is a little bit of logic of taking a look at if, this was our operation done on if we should take the cached rebrand access, which wasn't true before. It was more complex. And then, also, take a look at the theme override and just switch based on the initial value and the switch in the local app. So, that was how it was handled within the app.

And when it comes to design system components, all of these design system components within the provider, right, were referring to use global theme, a hook, which was using the theme from the context and took the tokens directly from there and used them. As simple as that. But that was the theme. So, it enabled us to switch in between two different brands.

We also managed the whole rebrand through Rebrand Champions across the whole organization. We found people from each squad being responsible for reporting about the rebrand process. Thanks to that, we kept transparency and communication on a very high level. It was super important to keep the communication clean and clear, so everyone is aware of what's going on and what's coming.

We also created a special space to share the state of rebranding screens called Screen Atlas. Within our internal tooling, we had a space where we uploaded all the screenshots of the old brand and the rebranded version. This made the status of the rebrand visible to product people, content folks, and non-technical individuals. We rolled out the rebranded version of the app as an A-B test at the end of the work to understand the impact and have a quick switch-off if needed, which fortunately was not required.

Also, we took this data into account, so we could query them and we understood where we are when it comes to rebrand. We rolled out the whole rebranded version of the app as an A-B test at the end of the work to understand the impact, to, you know, have a quick switch off if something bad would happen, if we would introduce a bug somewhere on the way. But also, if all of our metrics would tank, we probably maybe potentially would also, you know, just switch off the A-B test and think about what we can change within the new brand, what we could maybe tweak to not tank metrics so badly. But everything went well, so we didn't need that. Okay. So, this is how it went.

But let's talk a little bit about lessons learned. I think I've mentioned most of the lessons learned through the talk, but let me repeat myself again. Transparency is a key. We really need to be transparent with all of the steps you are taking, with all of the plans you are making. It's good to have them written down and being shared across the whole organization. I also found that communication is really a key. You really, you can repeat yourself. You can, it will look to yourself when you like look in the mirror that you are so boring. You're saying the same things over and over, but this is how you get to people.

This is how you make a thing a priority, and I found that this is super important. When you want to make a success from a project as big as this, divide and concur. That was a huge, huge thing for me. If you think about the stage Clio was at the very beginning, when we started thinking about rebrand and where we've have gone, it has not happened over a weekend, a month, a week, call it as you want. It took us, actually I think it's worth saying this, it took us a year to get there. But we haven't done, we wouldn't have done this without, you know, picking our bottles. I think it's super important, and it's also super important to do it based on not some kind of a gut feeling, but based on some data. So yes, do that, collect data, have some data to prove your point. It will make things easier later down the road. Delegation is your friend. That's a big one for me. I always found it hard to delegate. I always found it hard to, you know, share my work with some people. And I found that sometimes the project is so big that you won't be able to do it on your own. You just need help.

And it's good to get help. It's also good to get second opinions. It's good to share with people. It's the way you grow. And it just makes things so easier, so easy. So yeah, I highly recommend.

And last but not least, have a clear plan. It also makes things easier. Again, communication, transparency. But consider all of the different things at the very beginning. There always will be some surprises on the way. I'm not saying no. But having a plan will just help you stay sane through this whole journey.

And that was all from myself. Thank you so much. And I'm hoping you enjoyed it.