Tough lessons learned from a re-design

We wanted to change one color… aaaand we ended up doing a whole redesign. Here’s what happened.

Our interface color scheme hasn’t changed at all since day 1 of Dashly. As the service developed, we noticed that the shades of gray used in the interface had stacked up to 30.

As more designers and developers joined the team, the project’s “legacy content” (all the resources that we had built from day 1) became massive and disordered. We had to find a way to systematize colors and streamline interface elements. So we decided to improve the interaction between designers and developers. This would help us save time when choosing colors at the design stage, and speed up product development.

We did not want to redesign simply on the premise of making things “prettier”. The primary goal of good design should always be functionality. For a redesign to make sense, it must be backed up with sensible metrics and sound reasoning. In our case, it was clear that systematization would help us move faster. 

Here’s what we focused on:

• many different components (buttons, switches, etc.) that looked almost identical and —as a result— often caused confusion;
• unused elements;
• lack of coordination between the design team and the development team, where elements during the design phase had a different name and appearance from when they were implemented in the final product
• reworking the old system, which was slowing down both the design and the development team.

Here’s how we went about the task:

• We eliminated obsolete elements in the interface
  • We ditched obsolete interface elements that were being used extremely rarely or not at all. Then we streamlined everything, so that all sections in the service are composed from the same elements and do not differ visually.
• We streamlined the development process
  • We wanted to save designers the headache of having to think about which color to choose and which buttons to use. By standardizing everything, the design process becomes faster, because you’re literally just assembling from a toolkit of components, just like a constructor.
• We synchronized the design and development teams
  • Designers and developers now have a common library that includes all the elements they will need, presented in a structured and standardized way. This simplifies collaboration and speeds up development.
• We upgraded the appearance of the elements
  • We tweaked the contrast, change the color palette, and gave everything a fresher look.

Breaking it up into manageable chunks

This is how we went about updating the design.

The first thing we did was to determine boundaries. If you don’t do that from the get-go, the job will never end. So we decided to tackle the design over a series of stages. Here’s what we came up with:

• Organize elements and eliminate the unnecessary;
• Find a new color scheme;
• Organize the palette;
• Work on the contrast of the interface;
• Apply a new font.

Optimizing our assets

The main color of the admin panel was blue, and it had been that way from the very beginning. So we decided to update it.

At first, we thought of using the color from the logo.

Toolbar in orange:

Nope, not good. Looks like some kind of alert or warning.

Next, we tried green:

Much better, but not quite what we were looking for. So we explored further.

Color theory mojo

As we played around with colors, we realized we needed a more systematic approach. So we started looking at color schemes for our new palette. We started with a “triad scheme”, which uses three colors that are at the same distance from each other on the color wheel.

We combined this model with our two existing colors —green and orange— since they were already used in the logo and marketing materials, and as indicators in your account.

Next, we used AdobeColor with these two colors to find a third. We got purple. Cool!

The dashboard is in the new color scheme.

Determining the full-color palette according to the HSL model

Ok, so now that we had our three colors, we needed to agree on how to work with them. For this, we used the HSL model as our basis. HSL stands for Hue, Saturation, and Lightness.

The HSL model is represented as a cylinder. The color tone is measured in degrees along a horizontal circle. The saturation is measured radially from the neutral axis of the cylinder to the more saturated edges. The lightness value is measured vertically along the cylinder axis, from absolute black to white.

We picked violet for our main color, together with several minor colors that we decided to use in our interface:

• yellow — for notifications;
• orange — for errors;
• green — for successful actions;
• black and gray — for background, text and neutral elements.

We divided the colors according to the HSL model from white to black with a step of 5% lightness. Then, based on our own guidelines, we decided which colors we would use.

For the base color, we picked a 50% lightness. Then we went with -10% for text, +45% for the background color, and so on.

Here’s the neat part.

Now, all the elements in the service are described by formulas, which in turn determine the colors, state on hover, and selection. This allows us to change parameters in one place, and have them updated everywhere.

By the end of the exercise, we had assembled a library of new elements and reviewed it with all the designers and developers.

Applying the design

Of course, it’s never as easy as plug and play.

Applying a new color wasn’t enough. Some sections became too bright or didn’t make visual sense. The previous color wasn’t too eye catching, so we used it in many places. As soon as everything turned bright purple, the emphasis shifted and it became difficult to work.

We began to systematically go through all of the pages and look for inconsistencies. A front-end developer with the help of our designers, collected screenshots of all sections in Miro and reviewed each element.

The team went through all the elements on all pages. There were so many changes that our developers ended up changing 850 files! In the first version, we still haven’t implemented all of the changes. The comments in yellow are planned for the next iteration.

For example, in the Auto Messages section, filtering by active / inactive messages was too bright, and distracted from the main button “Create auto message”. Additionally, the “Active” badge for messages was too bright, so we toned it down a bit.

In the “Settings” section there are a lot of tabs, buttons, data pickers, radio buttons and other elements. Here’s a snippet where you can see many changes at once. 

Conclusion — changing the color is never enough.

When we simply replaced the color blue with purple, we immediately realized that the interface became difficult to look at — it became almost unnerving. We could almost feel the wrath of the gods of design and layout burning down on us.

This was one of the toughest parts of the process — to change all of the blue into purple, and then realize that we’d have to review and tweak it all from scratch.

Outdated code only made things worse. We had to trash almost all of it as there were a lot of copies of the same elements.

Artemis Rum, frontend developer

Font and Contrast

Lots of people don’t give much thought to fonts. But fonts affect our perception of things no less than colors. So obviously, we had to rework our font.

The main problem with our existing typography, was its low contrast.

We decided to try PT Root UI for three reasons:

• It is free to use;
• It is more modern;
• It is more flexible.

And it can also be changed!

One of our key requirements when choosing a new font, was the number of styles. The fact is that the previous font (PT Sans) had only 2 weights — Regular and Bold. This makes it very restrictive when you’re trying to work with contrast. That’s why we chose a variable font where we can manually set the values ​​that we need, and adjust the font weight for the necessary contrast.

For the new font to actually work well, we needed to work out the gray palette, which is used to fill the text.

As for the selection of the main palette, we again used the HSL model. By changing the lightness, we split the gray color into 11 gradations — from absolutely black to white. Then we picked the shades for headings, typesetting, placeholders and other elements.

Now the typography has a more definite contrast, giving it a more modern feel.

Taking it for a test drive

When we had finally finished the design, we rolled it out on our own accounts (yep, we actively use our own service lol) and for our most dedicated beta testers.

Obviously, some people were a bit taken aback, because it wasn’t the design they were used to. But that’s normal.

What we REALLY wanted to know, was how our users felt about the product itself. Did they miss any features or information? Were some elements too overpowering?

One thing that came up, was that funnels were too bright. This made them tiring to use. So we gave them an overhaul. We made the fill lighter, but we added a contour to make it easier to see. The “Send” button in the chat from the side of the agents also got a revamp. This is the primary action in this section, but the button was too prominent. So now, we’ve made it so that it is inactive when the operator has not yet written anything. As soon as there is a message that needs to be sent, it lights up.

The moment of truth… did they like it?

Here’s what our users saw before and after the update:

As always, opinions were divided. Feedback was roughly split in half between positive comments and criticism.

And someone remarked that it is very bright

We understand. Change is always a bit of a pain. But we’re working closely with our users, collecting feedback and acting upon it as quickly as we can.

Summary

As we tackled this challenge, we improved the synergy between designers and developers, and set reasonable boundaries for creating new components and adding colors. As a result, we now have a single scheme that serves as a practical tool for both teams. 

The biggest benefit of this, is that it will significantly simplify future service updates.

As of writing this, we’ve already rolled out the new design to our whole user base.

Next, we will collect all the feedback and make the necessary improvements.

So, have you checked out the new design? Was there anything you particularly liked or disliked? Please tell us in the comments! We don’t bite 🙂