Why we love Randstad
Randstad understands the importance of work in people’s lives like no other — they connect people with organizations to get the best out of both. We are proud to work with them.
On a daily basis, Randstad, Yacht and Tempo Team (all part of the Randstad Group) employees use plenty of internal applications to help people find a job. Several teams of designers and developers made it their mission to improve the experience of these apps.
Making the ecosystem of internal applications a joy to work with, is easier said than done. That’s why Brandshift — a multi-brand design system used by both Randstad, Yacht, and Tempo Team — was birthed.
However, the romantic promise of a design system — the same source of components for all teams, a more efficient design process, and better digital products — didn’t really come true. Brandshift wasn’t practical enough and therefore wasn’t used. Teams still did things their own way and designed from their own silo. Randstad asked us to join their team and rebuild the design system.
We immersed ourselves in the internal applications, teams, processes and designs of all three brands. From there, we redesigned Brandshift to help designers and developers make better products.
A design system: there’s no better investment
Imagine working on plenty of internal applications (from applicant tracking- and administrative systems to CRM systems), for three brands, made by teams in different countries. Did we lose you already? A design system is essential in such a complex environment.
“Working with a design system like Brandshift allows us to focus on testing and validating new ideas with users, rather than putting all our energy in designing screens over and over again.”
Let us quickly go through the pros of a design system: it is a set of reusable components and patterns and makes design work easier, faster, more consistent, and better. It offers ready-to-use building blocks. Thus, designers can focus on solving problems rather than worrying about pixels and button sizes. That’s from a designer perspective. However, in the end, it’s obviously all about the user (employees, in this case) — a design system benefits them just as much. Since all applications are designed from the same source, employees will recognize elements. This improves ease of use of different applications and eventually increases productivity.
3 steps to get started with your design system
We know it’s tempting to grab for tools like Sketch and Figma and start designing right off the bat. But please contain yourself: a more thorough approach is very much needed. These are the first steps we took:
- Line up a versatile team — (Re)designing a multi-brand design system like Brandshift, means teamwork. The design system has to match existing processes and people from several disciplines have to work with it. Your team should at least consist of a UX-designer, front-end developer and a product owner. Different perspectives are important.
- Catch up with stakeholders — Because we worked with stakeholders in several countries, who worked on different apps, for different brands, it was crucial for us to stay in close contact with them. We wanted to understand their goals, vision and expectations related to Brandshift. Defining a way of working was just as important: to whom do we report? Who decides? When and how do we link up with development? How do we communicate?
- Make an interface inventory - In a few workshops we’ve discussed the visual style and did an interface inventory. An interface… what? An interface inventory is a simple spreadsheet with screenshots of all the elements used on a website or in an app. From buttons to input fields and icons. An overview of these elements helped us understand which elements we needed to design and it made overlap between different brands and applications crystal clear.
And, ready to design!
The team is lined up, the context is clear, the way of working is defined and the first interface inventory is done. Almost time to move to the drawing board. But first, we worked out the interface inventory in more detail. We took screenshots of all pages and components, defined the idea behind them and gave them a name — that might sound silly, but a shared definition is essential. It helps avoid confusion in meetings, user stories, or chats. In essence, working out the interface inventory is about setting the scope: what do we have to design and why? How are different elements connected? You don’t want to rush this.
Once we had the answers, we started working on typography, color and spacing — this is what we call ‘style’; the foundation of all design work. From there, we experimented a bunch with components and patterns based on the principles of atomic design — from atoms, to molecules, organisms, templates and eventually pages. Step by step we worked on a component library in Sketch and a ‘Stickersheet’. A Stickersheet is a concrete translation of the Sketch library. It allows designers to copy-paste combined components and find the explanation behind certain interactions.
3 challenges we faced along the way
We could walk you through how we built the design system step by step. But that’s going to be a pretty detailed story — we hope the images of the designs above will speak for itself. So, we believe it’s much more interesting to zoom in on a few big challenges:
#1 Combining ‘information dense’ screens and ‘touch’ — Most of Randstad’s applications demand a lot of information on a single screen. At the same time we had to keep components big enough to make them easy to operate with touch. This meant looking for a fine balance, since one obstructs the other. Understanding constraints like this, is essential. You don’t want to design elements that turn out futile because you didn’t take context of use into account.
#2 Three brands, one design system — Brandshift is a multi-brand design system. On the one hand, we wanted it to be clear that all applications are part of the Randstad Group. On the other hand, we wanted them to have a unique Randstad, Tempo Team, or Yacht look and feel. The difference had to be subtle yet recognizable. Therefore we pointed out specific style elements (we call them Design Tokens) that differ per brand. The Design Tokens turned out to be font, background color and border radius of the buttons, and the color of the header.
#3 Accessibility - We believe it’s important that employees with visual impairments have a great experience while using the apps as well. This meant: enough color contrast, the right font size, and enough line-height. But it also meant instructing developers on HTML tags, making sure that everything can be controlled with just the keyboard, and double checking if developers used relative values instead of pixels.
“When Jeffrey (UX designer, Valsplat) joins the team, you gain an enormous amount of knowledge. The briefing was known in advance, but we got so much more. He brought in a bunch of knowledge on accessibility and front-end design — that helped a lot during this project.”
You need to sell your design system
We worked in such way that teams could use the component library from the jump. Even though it was work in progress. Did they actually do it? Not necessarily. We flipped this by catching up with teams, showing them designs, explaining our choices, facilitating workshops and by holding presentations.
Most teams need more than a library with pretty components to actually use it. Communicate clearly. Present your ideas. Build it up from a solid foundation (atomic design) and explain your building blocks.
The Storefront: where it all comes together
In the first phase (+/- 3 months) of the project we focussed on working out the interface inventory, the library, and the Stickersheet. The final 3 months, we worked on the ‘Storefront’ and writing documentation.
The Storefront is exactly what you’d guess: a place where designers, developers, and other stakeholders can ‘shop’ for components. The storefront unites code and design. Developers can easily copy code and go through the UX guidelines — in some cases there are no designers involved, so it has to be clear how to use components. Designers, in their turn, use the Storefront to collect all pieces of the puzzle to create new designs.
One of our favorite parts of the Storefront is the ‘component request’ — a built-in tool that allows designers and developers to request missing components or do suggestions to refine existing ones. The design system is a living document and should be improved constantly.
Do I need a design system?
If you ask us, the answer is always ‘yes’. To be a little more nuanced: if you can tick off the following boxes for your team or organization, you definitely need a design system:
- Many designers and developers are involved in building the product I work on
- Designers in my team are worrying about pixels again and again
- Our developers ask where to find that one icon every other week
- Our products /services have an inconsistent style
- We have plans to branch off to several products /services
- The same interactions are applied in different ways within our products /services