One year ago we rebranded from OnPage.org to Ryte and during that we redesigned all our tools from the ground up. We were super motivated and started creating mockup after mockup. Four months later, we realized that the design of all three tools was moving in dramatically different directions. We were building multiple different solutions for the same UX problems and starting to create a huge mess. We needed to find a solution to avoid this problem …immediately.
There was no need to reinvent the wheel: our tools all had similar UX requirements. For example, with Website Success, you monitor, analyze and optimize the technical errors on your website. Search Success does the same with your search engine performance.
Given these similarities, we knew that we needed to have a system in place to efficiently reuse design and react components and stop wasting time rebuilding the same things over and over again in different teams. Or else It would have become impossible for our users to switch between our tools without relearning the usage again.
In this article, we want to share the lessons we learned building our design system and how we dramatically increased the velocity of our design process with it by 8x. We also want to share our experiences standardizing the UX between our three products and unifying the customer journey for the millions of online marketers that rely on Ryte assets regularly.
Before introducing our design system, our platform faced three problems:
The main problem was that all products on the platform looked and felt very different. We had 11 different types of pop-ups, 23 types of buttons and 67 shades of grey which resulted in users having to relearn how to use the platform whenever they tried another one of our tools. This resulted in high bounce rates. Users were overwhelmed as they just wanted a frictionless way to improve their website, content and search engine presence.
Another problem was a bigger one — a slow, inefficient design process. It took us, a really long time to ship new screens because we had to build everything from scratch. We often needed to change things after the design was already implemented.
Building a design of a new screen in Sketch, sending the PDF to stakeholders and starting to code after their approvement just missed out on so many opportunities. The opportunities to user-test and to get a real ‘feeling’ from stakeholder- and UX-perspective for how the screen looks and behaves at the end with a clickable prototype.
The last major problem was an inconsistent user experience throughout our entire online presence. Our Wiki looked different than our Magazine. Our Magazine looked different than the platform and so on. So our research showed that whenever new users came into the tool it was hard for them to recognize that they were still in the same Ryte ‘Universe’. That was when we realized that design systems are not only relevant for tools but also for any website out there.
So there is a good reason that companies like Shopify, Atlassian or Hubspot all recently introduced their own design systems. They did it to overcome those design inconsistencies, accelerate their product creation process and increase their brand awareness.
When we successfully introduced our system we needed it because our products were out of control from a design perspective. We soon realized that you don’t only need such a system for a better design consistency. You need it because you get your design velocity and overall usability to a whole new level with it.
In our case — and very simplified — the design system consists of two things: a shared Sketch File and a shared Git repository for development with all the React components in it. Companies like Airbnb go one step further and merge both to be able to design with real components from the code in Sketch. We didn’t go so far because we saw some scalability issues coming with that approach regarding our company vision.
A handy definition of a design system is:
“A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.” (Design System Handbook)
Instead of designing the same button over and over again, today our UX team can focus on building innovative products that are super easy to use. We build entire new tool concepts in a matter of days and are immediately able to test them and gather feedback with clickable prototypes. Only by that, we will be able to reach our goal and create the best User Experience for website optimization tools on the market.
In the early days, we needed to rework many aspects of the design after it was already implemented. Today, we can just send it to developers, they implement it and after one iteration, we are done.
Our developers are really busy shipping new features and making our users happy. The last thing they want to do is waste time to rebuild things that were already developed by other Rytees. With the shared components Git repository, they can access all of the design components that are used throughout the platform and save tons of time by just dragging and dropping existing patterns. The components are built with React and documented in Storybook.
With 500.000+ users on our platform, we can’t rely on tutorials or webinars anymore to enable our users to get value out of Ryte. Everything needs to be self-explanatory and we only achieve that by constantly gathering feedback from customers. Watching them click through an InVision Prototype gives us a whole new perspective on our designs and enables us to continually level up the user experience.
Because our design system makes our UX team so much faster, they now spend less time maintaining out-of-sync Sketch files and more time conducting user research. Also when we hire new designers they are up and running so much faster. They can immediately build something and test it on real people.
We used Sketch for a while already and built the entire library with the symbols feature even though it just worked in one Sketch file. All UX designers worked in that one file, which was only possible using Abstract.
The file soon became really bloated and slow, so we were super happy when Sketch announced its Libraries feature in October 2017. We immediately pulled all symbols out of the monster Sketch file and dropped them in a library using the library symbol replacer plugin.
When it comes to developer hand-over and sharing designs within the team we recently fell in love with Zeplin. It has more or less similar functionality like InVision but is 10x faster and has some more features that really make our lives easier like tagging screens and sorting them by “last updated”.
Our design system consists of:
Because all designs of all screens we ever did are in sync with the most recent library changes, we have one huge InVision Prototype that is basically how we imagine our platform in the future. By constantly gathering feedback with it, we refine our vision regularly to always have the big picture in mind.
By constantly challenging every element we put in the library and always making sure that all UX designers use as many similar patterns as possible, we successfully introduced a process to keep our tools consistent and easy to use.
Many UX designers we talked to told us they think about introducing a design system in their company, but they just don’t have the time to do it. It’s true, it takes time to build one — but only when you do everything yourself.
When we started creating our library, there weren’t any other design systems to use as a foundation. We created the majority of it by ourselves and are proud to be early birds in the design system world.
But in the last few months, many companies started open sourcing their design systems or selling them for a decent amount of money. The Design System Repo is a good source for discovering the latest ones. Searching for the term “design system” in Product Hunt will also reveal many you can use as a foundation for your tool or website and save lots of time.
When building new screens and features, we constantly discover new elements that should be put in the shared library, but we try really hard to avoid duplicate elements that solve the same problems.
Additionally, when we realize that a component doesn’t really work or look beautiful in a specific setting, we adjust it. Changes in the shared library are natural and happen all of the time.
In the beginning, we tried to find ways to merge the tool library with the marketing-website library. Soon we realized that we just have different requirements. We realized that font-sizes need to be bigger and that you need different components when you don’t want to cut down on marketing possibilities.
But in the end, we found a way to unify the design systems as much as possible, so that all of our assets now have the same colors, icons, illustrations and similar typography, buttons, and headers.
We are an agile organization and every product squad has its own UX Designer. To enable collaboration on the design system, we initiated a design system guild and meet once a week to discuss if anyone has new elements to put in the library or changed something recently. Our frontend lead is involved so he understands what the components do and can spread them to the dev team more efficiently.
Of course, our UI designers and UX writers contribute to the system indirectly with beautiful icons, illustrations, and super comprehensive wording.
With multiple product teams located in Munich and Vietnam, good communication is vital to bringing our product forward. They need to know why it’s important to use the shared components. Because most devs are so busy shipping features and new screens, it’s just natural that they sometimes miss out on existing components they should be using.
We are still figuring this part out and are working toward trying to overcome this communication gap.
When our three tools started moving in different directions, we knew we needed to figure out a system to efficiently reuse design and code components throughout multiple design files and codebases. We needed to overcome design inconsistencies and a slow process while creating brand recognition.
We solved it by introducing a design system, a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications. The system exists in a Sketch File and as a shared components repository in all our codebases.
We learned a lot by building out our library. The most important thing that we recommend other is to not create a library from scratch and to use one of the many existing libraries out there as a foundation. It will save you time.
The library is a living document and changes are not only possible but necessary to keep it alive. If you have a software, trying to bring the styles together with your marketing-websites will increase brand recognition and thus user experience. If you work in a team, make sure to involve everyone necessary to spread the design system throughout the company.
You don’t need a design system when you have a small One-Pager and branding is not important to you. But with the right tools, the right people, and the will to unify your entire customer journey, there is nothing else that should stop you from introducing a design system in your company.
.png)
