Design System Safari at OGD

We recently visited the IT-specialists Operator Group Delft. Interaction Designer Wouter Schuur gave us a tour through their Software Development department and six frontend-enthusiasts shared their view on Design Systems. Read on to see what we learned!

A brief history

OGD was founded by five students from the Delft University of Technology in 1988; a whole different era. There was no iCloud or Dropbox with automatic backups. The five students helped organizations by making backups of their cassette tapes with important data. The office spaces of OGD were just student rooms those days. In thirty years a lot has changed: OGD has 5 office locations in the Netherlands and counts over 1100 employees.

OGD practices their passion for IT through several B2B services, divided into three specialties: Outsourcing, Software & BI and Professional Services. These specialties are categorized in the many solutions OGD brings to the table, such as application development, machine learning, and strategic IT advice.

The people

Currently the Business Unit Software & BI consist out of 80 great minds with a development background. In the near future, with the rise of new products and visions on for example Design, they hope to expand.

For a large organization as OGD, taking care of internal knowledge is a huge pillar in their culture. OGD made knowledge clusters to centralize specialized knowledge. For example, the UX&UI and the front-end clusters.

There is a lot to say about the philosophy and people of OGD. But we are on a Design System Safari. Where do they stand with their Design System? What is their current situation and what are the next steps for OGD?

Where it all began

In 2016 and 2017 OGD rebuilt their brand identity. Even though OGD has a tech-minded nature, corporate identity, as well as the communication standards, became a bigger priority.

The result: an updated employer brand.

Part of the employer brand and the corporate communications plan is the ‘purple book’ of OGD. The purple book contains rules about the tone of voice and copywriting standards. For who? Marketers and account managers; practically everyone who performs communication tasks within OGD.

Not to mention, the work on the employer brand did not stay unnoticed. OGD had found the website, which had won a prize for best recruitment campaign at Werf& Awards.

Award-winning website:

After redefining the employer brand and the communication standards, employees at OGD began to wonder: how do we make this employer brand more applicable for our developers?

The OGD Styleguide: Bootstrap 3

In July 2017 they worked towards implementing the ‘OGD Style Guide’, with fragments of code based on Bootstrap 3. Bootstrap is a commonly used HTML/CSS framework to develop UI’s fast and easily. Due to the hands-on character of OGD, it felt like a simple way to start.

The Style Guide implementation became applicable for developers. Through one click they got the opportunity to style applications (and by using Webpack as well). The main goal was to serve developers with practical guiding principles and components to align their way of work.

The Style Guide consists of three main ingredients:

  • The rules on communication, which we also saw in the employer brand.
  • Usage notes about the implementing of the OGD style when developers want to style a new project.
  • Code based on Bootstrap 3.

The style guide is made for developers, by developers.

The public website

Hubspot is the content platform of the public website of OGD. The code for the public website was developed based on the Bootstrap 2 framework. While Hubspot works with Bootstrap 2, the third and fourth version of Bootstrap is not supported by Hubspot yet.

Future plans are to transfer to Bootstrap 4 for the OGD Style Guide, so it supports several devices. How to bridge the gap between the styling of the public website and other (internal) products? A burning question to take into consideration in times of building a Style Guide and working towards a Design System.


Besides developers, Marketers have to deal with Design during their daily activities as well. Their biggest responsibility within the company is to protect the corporate identity. The resources Marketing uses for design-jobs are mainly located on Sharepoint. How to reduce this to one resource for all, without losing sight on the protection of the corporate identity?

💡 Tip: Many organizations struggle with starting off with a pilot for your Design System. Find out what the essentials are for your organization. Psst, by chance we created the ‘Design System Checklist’.

The opportunity

Software development is a group of people with a shared vision. Many developers acknowledge that OGD should start off with a Design System to help them to co-create efficiently. A fine initiative arising from the bottom-up. To get the management on board, the Business Unit Software is playing with the idea to define the different OGD personas who will be using the Design System internally. Journey mapping might also be helpful for them to clarify the user for the management.

Besides, with a majority of tech-oriented colleagues rather than design-oriented people on board, the Business Unit hopes to give Design a bigger stage.

The character of the organization breathes IT, this works on their Design approach as well. One source of truth for all the people is a challenge for OGD but would be the idealistic situation for the developers at OGD. What does that mean? Integrating one standard in the workflow of Marketing, HR, and development. Luckily, Design Systems are a great way to align people!

✍️Small note: We found that Design Systems are 80% about the act of people working together. Read more about it in our report about the State of Design Systems in the Netherlands.

3 tips from OGD to build a vision for your Design System

The front-enders gave tips on how they are making the shift from a one-sided developer perspective towards a more whole and aligned approach.

  • Don’t make it too big

The word Design System seems to be abstract. People tend to find it ‘too difficult’ or ‘too big of a challenge’. This might be a typical example of ‘developer thinking’. The advice would be to prevent getting lost in the process is to frame the term Design System through the orientation phase.

  • What is the problem you want to solve?

Make sure that you know what kind of problem you want to solve. This would be step one. Problem framing! Focus on the visuals and the tooling afterwards, so you make sure you don’t  forget about the higher goal. What is the purpose of the Design System? What are the values of the Design System? What and who is the Design System representing? Etcetera.

  • Who and what do you have in store?

Instead of focusing on creating something completely new: what knowledge and guidelines do you already have? You don’t have to start from blank, from nothing (talking about a company who is an expert in back-ing up stories, a throwback to the cassette tapes). What is already done by your people? Maybe somewhere in the archive you will find very useful data, stored by people you don’t work directly with. Not to mention, this is a way of getting all the people and all the visions on board.

✉️PS. Defining the workflow around the adding of new element to your Design System can be difficult (and to align your team). For this occasion, we have created a tool: the Process Puzzle. With the help of this puzzle, OGD made a new workflow for their team.

Wij gebruiken cookies voor de beste ervaring van de website. Tijd teveel, beklijk onze privacyverklaring