<aside> 💡 For the best experience, view this on a desktop device due to detailed case.
</aside>
Sitecore-cover-designsystem.mov
The challenge
Working with Sitecore user interface can present several challenges, particularly for those who are new to the platform. One of the main challenges is the complexity of the system, which can make it difficult to navigate and find the features or tools that are needed.
Additionally, Sitecore's interface can be highly customizable, which means that different Sitecore implementations can have different user interfaces, further adding to the complexity. Another challenge is the learning curve, as Sitecore requires a certain level of technical expertise and knowledge of the platform's architecture and terminology.
Finally, keeping up with the updates and changes in Sitecore's user interface can be challenging, as the platform is constantly evolving and improving.
Result
Sitecore Horizon UI was designed to provide a modern and intuitive user experience for content editors and marketers. Moving away from the idea that you a certain level of technical expertise to use.
Documentation
Learnings
Please note that the Horizon UI presented in this case study reflects the design from 2018 to 2020, and its current styling may have evolved since then
This case study focuses on the efforts of building a new UI library for Sitecore Horizon which was part of Sitecore's ongoing efforts to improve the user experience of its CMS platform and enable businesses to deliver more personalized and engaging digital experiences to their customers. As a newly developed team we had two goals to pursue:
Sitecore has undergone significant UI changes since its inception in the early 2000s. Over the years, multiple component libraries were developed within the organization prior to the introduction of Horizon UI. Sitecore products have changed many user interfaces projects before.
In my role on the Horizon UI project, I have been tasked with finding a solution to prevent the creation of additional component libraries in the long run.
This led me to explore the emerging methodologies in design systems and system thinking, particularly influenced by Brad Frost's Atomic Design concept. This was back in late 2017, early 2018.
I have extensively researched and delved into the realm of design systems while working on the Horizon UI. As a result, I have endeavored to educate both engineers and designers at Sitecore about key principles such as:
With these methodologies, I aimed to create a cohesive and sustainable approach to the new future UI within the organization, ensuring consistency, efficiency, and scalability across Sitecore's products.
Design Tokens in action as SCSS variables (left), component documentation using tokens for engineers (right).
Initially, the approach for Horizon UI involved designing components in Photoshop, 2017, and then creating UI screens. This resulted in UI components being based on a predefined color scheme chosen by a designer that worked there at the time.
However, this approach became challenging to maintain when there were requests to change the sizes of elements or when we had to change colors again based on user testing results. Designers had to manually update each component's colors/size in Photoshop, sometimes overlooking certain states such as hover or pressed. This Photoshop rework could take almost one week of actual work within the team.
To address this issue, I introduced the concept of design tokens in our design team. I explained how design tokens work and how they can save time in the long run. Initially, I implemented design tokens as SCSS variables to facilitate collaboration with the front-end engineers.
Photoshop was also not the way. So we switched to Sketch and we were looking into Sketch Libraries. It was hard to give a master class into design tokens back then but with the engineers in my team we settled on using SCSS variables as a first step.
Designers were learning how to work with Sketch libraries at Sitecore and I was learning how to connect Sketch Libraries into a HTML file to build a design “vocabulary” based on what Atomic design was trying to teach. I ended up with my first ever design tokens in 2018.
Design tokens for:
And with these variables I asked designers to design the components going forward in Sketch. It saved a lot of the time for the iterative feedback we were constantly getting from user tests and upper management. Because now if we wanted to change a color everywhere in the Horizon UI we just had to replace a line of code. We got a lot of requests to change the colors and was taking ages to do that in Photoshop to 10 screens.
By connecting this world between Sketch and a SCSS variables list helped us be more efficient and have a common foundation.
My first design tokens as SCSS variables back in 2018.
Frontify role
In 2018, when we had to chose to keep Photoshop or move to Sketch, Figma was still in its early stages and not widely adopted. As a result, our design process involved designing in Sketch and presenting the .png screens to the developers. However, unlike the current capabilities in Figma, developers were unable to inspect the files directly. They expressed the need for documentation that would guide them in developing and styling these new components for Horizon UI. Later on, after one year of Sketch I pioneered for a Figma switch. In this one year with Sketch and SCSS variables we still did handoff like this:
How designers spec their design with tokens (SCSS variables) in Sketch.
Ensuring seamless implementation of our design work by the front-end engineers was a priority for me. I am pleased to say that our efforts were successful, as we experienced minimal friction during the implementation process.
The Frontify pages containing the component specifications served as a valuable resource for the developers, eliminating ambiguity and preventing any implementation-related inquiries. With clear guidelines at their disposal, the developers were able to write code that aligned perfectly with the design. A first in Sitecore history.
Designers had to fill in Frontify this template for component styling specifications.
****By utilizing the foundational design tokens mentioned earlier, I began specifying the components styling with them. However, due to security restrictions at Sitecore, we were unable to explore new software options to streamline this process like ZeroHeight. Fortunately, we had access to Frontify, and I identified a way to leverage it to our advantage in the process. Developers were provided with links to the relevant Frontify pages, allowing them to access the necessary information and guidelines for implementing the styling to the new Horizon UI components.
What developers received and had to follow for implementation.
The utilization of Frontify pages proved to be advantageous not only for the Horizon UI team but also for other development teams working on different products within Sitecore. With multiple development teams located across the globe, these pages served as a valuable reference for building local components in their respective products that were to mimic the upcoming Horizon UI.
By providing a centralized source of information and guidelines, we ensured consistency and efficiency across various teams working on different projects in parallel. As we were building Horizon UI other teams wanted to update their digital products to follow Horizon UI standards.
Devs were following the spec received from designers for each UI component.