web + mobile visual rebrand

A rebrand across web and mobile working as a designer, dev, and PM.

Problem

Over the years our visual identity had become disjointed, outdated, and was no longer scalable with the resources we had.

DISJOINTED

  • Our mobile apps still had remnants of the previous rebrand from years ago, so areas of the app would feel quite different to each other.
  • This made it harder to design and develop the apps as you had to swap between two different libraries with different constraints and rules.

OUTDATED

  • We had a couple users reach out asking if our notification emails were a scam because they looked so old.
  • Our colour palette and imagery style was no longer up-to-date, falling behind with modern trends and competitors.

NOT SCALABLE:

  • Our illustration style wasn't easy to recreate and we had no one that could make new illustrations. So we became stuck with what we had and often the illustrations didn't make sense with our needs or provide value.
  • Our platforms were all in different states of rebrands which made it harder to build and maintain, with no clear alignment of our brand direction.

SO, WE NEEDED A SOLVE THAT:

  • Solidified a cohesive, scalable brand identity across the entire product experience.
  • Was easy to understand, learn, and adopt internally so we can be in alignment with our visual identity moving forward.

Goals

  • Cohesive experience

    A cohesive journey across all aspects of 7shifts.

  • Scalable

    Allows the team to easily create new experiences across all platforms.

  • Natural to adopt

    It should be easy to understand the changes and how to use them moving forward. The rebrand shouldn't impact teams velocity.

Challenges

1. CAPACITY

The project officially had one designer (me), one web dev, and one mobile dev for each platform.

There was no product manager so a few of us filled that gap. I determined what the final design was in the product, worked with devs to split out the work and tech plan it all out, and then communicated project updates to the rest of product along the way. I also helped as a web dev to help get all the web changes done by the release date.

We had around five months to complete the rebrand, and each one of us had at least a small amount of side work to do while working on the rebrand.

2. SCOPE OF WORK

The rebrand required work on web and two mobile apps for iOS and Android, all in very different states of design system adoption and living with various levels of tech and design debt. This made things especially challenging to plan and scope down to something a small team could reasonably complete by the launch date.

3. A SINGLE SEAMLESS RELEASE

We had a set date to launch the rebrand and we couldn't release parts of it before this date. But once that date hit, everything had to be flipped over including all three platforms changes, as well as all of our internal documentation, Figma libraries, etc.

For example, to help other projects know what they'd look like when they're released, I created a Figma file with common rebranded screens and some design guidelines for teams to use.

User needs

  • EXTERNAL USERS

    • A consistent experience across all aspects of 7shifts.
    • A delightful experience that feels modern and with the times, especially with our recent addition of pay products that require a level of confidence and trust.

  • INTERNAL 7SHIFTS TEAM

    • High level summary of the changes and the project roadmap.
    • Clear and early communication of any specific rebrand changes that impact someones work.
    • Easy to learn and adopt the rebrand changes.

How it started...

When I was added to the project the majority of the big brand changes like font, colours, and imagery had already been decided. It was now my teams job to determine how to apply these changes to the product and ship those changes by a set date.

figure 1

Guidelines from the agency

The guidelines were very high level, including only font, colour palette, imagery style with set libraries to pull from, and logo information.

The guide was missing guidance around details such as border radius changes (all examples were inconsistent) or examples applying the high level changes to the product on any platform.

It was up to me and my team to determine how to apply all these style changes to the product.

Figure 3

So many audits

I completed a handful of audits on things like common pages, imagery, forms, and empty states to understand the state we were currently in and what work we'd need to do to apply any holistic rebrand changes.

These audits also helped later on with exploring rebrand changes and catching any edge cases we'd need to consider.

Figure 2

Visual assets guide

The imagery style switching to a bento layout required redesigning all empty state images, which included over 150+ empty states.

I made a guide with guidelines, examples, and links to our new asset library for the team to help guide us while redesigning all of our empty state images. This guide remains as a resource for designers now that each designer has to create any net new imagery for their domains.

Figure 5

Status colours

We have five statuses: upsell, info, warning, success, and danger. The agency had no mention of status colors and our previous upsell color was removed in the new palette. We had to look at all our new palette to determine what would take it's place.

Four of the five thankfully didn't need changes, so it was just upsell that needed an answer. From the colours available the new lime was too bright for what we wanted and the new blackberry replaced our previous eggplant blue, so those were off the table. That left the new eggplant purple.

After sharing it with the product team we were all happy with trying it out as our new upsell color across the apps.

Figure 4

Full colour palette

The new brand colours only included three shades for each, but in order for them to work with certain UI elements in our design system we needed a full six shades for each. So, I had to determine the missing three for each by comparing to the others, using it in context, checking contrast between certain levels to ensure it's still AA accessible, and sharing with designers to eventually get a palette that we were happy with.

Figure 6

Typography updates

We got two new fonts to play with, with general guidelines that one is for headings and the other is for body text, and all text should be black. But the way we use our text styles in the product didn't exactly line up with these simple rules.

After trying a few versions we landed on a set of rules that was aligned to the brand guidelines of headings vs. body, while still working well with how we use each text style in the product.

Figure 7

Border radius

The examples we were given were much more bubbly, but had different border radius values across screens and even within the same screen would be slightly different. When we asked they didn't have a set value they were using.

Using the audits mentioned above I made a handful of screens in Figma that covered ~95% of our web and mobile app UI. Using these screens I narrowed down our elements to require three border radius tokens and understood how each was generally used, and then determined the value for each.

To determine the value I played around with our multiples of four rule until the three tokens used across the screens matched the border radius look that was in the rebrand guide.

Web and mobile were able to follow the same rules for the three border radius tokens but mobile had smaller values since that experience is at a smaller scale.

How we implemented the changes

Once we knew how we were going to apply the agency guidelines to the product, then came the planning stage.

WEB UPDATES

Web has a much higher adoption of our design system, so we were able to make a lot more holistic changes with our limited capacity. All that said, it still required a lot of legacy code migration work up-front to allow us to make those final holistic changes later on. Through this work we were able to reduce our legacy components folder by ~70%.

The main chunks of work included:

  • Migrating old legacy pages or components to use sous chef, our component library.
  • Migrating forms to use form sections. Part of the web rebrand was changing our app background from white to a light grey and form sections needed to be in cards. Most of the app worked as is with the background swap except forms.
  • With the grey background change on a feature flag we were able to test pages, find issues, and fix them without having the grey background on for anyone else.
  • Swapping style updates like colour, font usage, and border radius in sous chef in a beta release so we could test it ahead of time without impacting sous chef usage and process.
  • On release day all we had to do was merge a PR with the sous chef version upgrade.

MOBILE UPDATES

Mobile was much different because at the time barely any of the app used a reusable UI library. So sweeping changes were much less realistic. Our mobile devs also had other high priority projects on the go so their capacity was very limited. Due to this we had to take a step back and ask what we realistically need done for release vs what could we slowly make progress on over the next year or so.

To determine what we'd do for launch day, the mobile devs and I had a jam session looking at my "final" version of mobile with all changes we'd like applied. For each component we discussed the scope to change for each platform. Using this information we made a much smaller list of need to haves for release, should have shortly after, and then should have in the next ~year.

Our todo list went something like this:

Need to have

  • All instances of our logos swapped across all three mobile apps (7shifts, 7punches, and 7tasks). This also included things like notifications, the nav bar in app, app listing pages in the app store.
  • Gradient backgrounds including removed brand colour gone, replaced with our primary brand colour. This applied to the login page, dashboard, more menu, and my account pages.
  • Release the above on the same date as the web release. Due to mobile release cadence we had to complete the mobile work in the previous mobile release that was a few days before our actual release date.

Should have shortly after

  • Use the new fonts
  • Button colours swapped
  • Various navigation components colours swapped
  • Imagery swapped

Should have in the next ~year

  • Border radius updates
  • Default avatars updated to match web
  • Migrate any remaining key, high traffic areas to use sous chef

What I learned

  • DO'S

    Complete UI audits to understand the full scope of your changes

    • When you know all use cases it makes it much easier to make confident holistic changes.
    • Seeing the full picture makes it easier to ideate because you have a good understanding of all the use cases you need to cover.

    Share early and often

    • Changing habits takes time. Sharing rebrand updates regularly with designers and devs allowed them to be aware of the changes, give input along the way and feel ownership, and slowly learn these changes, so that by the time it went live people were happy and familiar with the new brand and knew how to follow it moving forward.

    Have guides easily available

    • Guides provided an artifact I could share, get feedback on, and eventually get sign off to start executing these changes.
    • When you're a small team, things come up and we can only be in so many places at once. Having guides allowed us to still take vacation without worry, or allowed others to be empowered to solve issues on their own and not need us when we're say in a meeting wall kind of day.

  • DON'TS

    Wait on an agency that only gets you half way there

    • Things dragged on initially, and when we kept not getting the results we wanted or expected from them we had to just cut them off and do lots of it by ourselves anyways.
    • In hindsight we could've probably just done it all ourselves. We would've saved a lot of time, money, and energy. Agencies don't know your brand, your users, etc., which can be nice as fresh eyes, but when it's just constant back and forth that doesn't get anywhere then I don't feel it's worth it anymore.

    Pleaaaase use a reusable component library early on 🙏

    • The majority of our work was just migrating to use the component library.
    • Had we used reusable components from the start it would've cut our web scope at least in half. And mobile could've actually stuck to the full rebrand plan.
    • Mobile wasn't able to do the majority of rebrand changes due to the lack of an adopted reusable component library. We're still working on this today over a year later.