Design systems are a hot topic just now. For a few years digital products have been jumping on the design system bandwagon and here at the ³ÉÈËÂÛ̳, we are no exception. We've been busy simplifying our digital products and services scattered across different websites onto one platform called WebCore. It's all about doing fewer things better.

The User Experience and Design team at the ³ÉÈËÂÛ̳ is no stranger to design patterns and guidelines. For many years we've had our global experience language, called GEL (since 2008). Things are a little different now we have WebCore. We're no longer writing and sharing guidelines for design patterns and foundations. The key difference is: we're now building them. We're setting up frameworks for layout, colour and typography in actual code. We're building components for all the different teams across the ³ÉÈËÂÛ̳, and we're getting other teams involved with building components for everyone else too.

This doesn't just magically happen. Managing and coordinating teams across a business to adopt and improve a design system is a time-intensive activity. When working in this context, a UX designer has to use a set of skills which you might not find on your standard list of competencies for any other UX job.

With that in mind, what does your day to day look like when you're a designer in a design system? The short answer is, you could be doing a whole host of things. It's not always about creating top-notch design patterns and tokens for everyone to use (although, that is definitely part of the role). The ³ÉÈËÂÛ̳ design system is more than a set of components. It's a community of folks gathered around a common goal to unify all our websites into one service.

In order to grow and support that community, you have to use many skills. A phrase which might summarise it quite well is 'you have to wear many hats'.

Seven hats (or, skills) to consider

You're a good navigator

There can be moments when you have multiple options available in front of you and the direction to take isn't particularly clear. This often happens when collaborating with other teams on their products and experiences.

A simple goal like showing an election result or displaying the weather can be achieved in a couple of different ways. There might be opportunities for reuse, for collaboration with other teams, or the exciting prospect of starting something entirely new. Knowing which route to pick isn't always a simple task. It's often a balancing act of analysing the pros and cons, the timing of the work and resource available.

You should be confident to pick a direction and bring your colleagues along for the ride with you. Even if you might have to switch paths halfway because things don't always work out the way we expect they should. This is a great way to grow your adaptability and experience feeling comfortable in uncomfortable situations.

You've got good customer service skills

When working in a design system team, you could consider yourself an extension of the product. In the same way you write guidelines and documentation to inform people about how to use an aspect of the system, people will inevitably come to you to find out more information.

If the documents in the design system weren't written well, you wouldn't be a big fan of working with the design system. The same goes for yourself. You're the face of the product and you're unhelpful or undiplomatic it's likely that your colleagues won't be particularly thrilled.

A name we've earned over the past few years is the 'GEL police'. GEL & WebCore is hoping to change this perception – although we don't always get it 100% right. We want to enable teams across the ³ÉÈËÂÛ̳ to get their stuff done. If we're holding that up we're probably not doing our jobs as best we can. A UX designer isn't there to 'police' the design system – they should be supporting and enabling other teams to do their work.

Designers have plenty of opportunities to improve their facilitation skills with the other teams using the design system. The idea is to act more like a community support officer rather than a police officer. There to help the community of teams building top experiences, rather than judging and enforcing the rules on what folks are making.

You're pragmatic with a splash of creativity

Design systems have rules. It's what makes them efficient and simple to work with (at least that's the idea). You should understand and know how these rules govern what can and can't be done. It helps you to make decisions and be pragmatic. When you show your working and decision making process based on these rules, it helps you to demonstrate the value of a design system and persuade others to adopt a similar way of thinking.

However, there's a problem with this approach. Innovation happens when new, shiny parts to the design system are introduced, or people challenge the status quo and ask the question "why does it have to work that way?". If everything stayed the same there would be no growth. There's tension between following the rules and breaking them to create change. You have to use your pragmatism to identify what good innovation looks like and when the rule breakers aren't being helpful. Especially when you're the one breaking them.

You have to have the gift of foresight

Trying to understand the long term impact of your decisions is tricky business. Often the immediate result is clear but then it takes a little while for the other unintended consequences of your work to creep out into the open.

At the start of a design system's life, it's simple and straightforward to see a change. After a couple of years of iteration, improvements and tech/creative debt – changes become less predictable.

This is when systems thinking can help you predict the unpredictable. In essence, it's about seeing the impact of a change from different perspectives and taking a step back from what you're expecting to see. A vital skill for a designer working in the context of any system, not just design systems.

You understand you're building a product for your colleagues

When designing as part of a centralised design system team, the 'users' are your colleagues in other areas of the business. (Although, they probably wouldn't like being called that to their face.) Think of it like a party. You're the host, they're the partygoers and you're making sure everyone is having a fab time.

A design-system-designer needs to build empathy with their audience the same way you would when designing for an external product. You're not just combining a bunch of design patterns, styles and chunks of UI together. You're building a product to make your colleagues' lives better, easier and more fun.

This is where a UX Designer can flourish in a design system team. Building relationships with your colleagues, listening to their feedback and becoming a point of contact so you can understand why things aren't working is a UX designers superpower. It's a luxury which other UX designers working on 'audience facing' products don't always have.

You can understand the nature of how code works

Should a designer be able to code? A question which has always been a talking point. The general answer is 'it depends'.

There are benefits to understanding the nature of code (whilst not necessarily being able to write it) when working alongside a design system development team. For example, knowing the ins and outs of how pages are themed as the website is built is vital for informing teams about how they should set up their components. Another good example would be knowing the difference between a component with and without data so you can explain how components adapt to different types of information.

Looking at the future of the designer's role in this area, you might start seeing the position of UX Engineer, UX Developer or Design Technologist more frequently. There seems to be a specialised role emerging within the creative industry for code-savvy designers, or design-savvy coders, especially within the context of design systems. It could be a reflection of the skills desired for creative people working in systems where the design is tied so closely to the code and how it works.

You're a bit of a wordsmith

If you don't want to spend all day explaining different aspects and elements of the design system to other people, then part of the role is writing informative and digestible documentation. This doesn't have to be a dry, boring task. Often explaining the most challenging aspects of a design system can present opportunities for fun and play.

For example, we've created documentation for explaining the purpose of the four different teams building WebCore as an illustrated story about a restaurant. It still contains all the required information, but it is much more engaging and playful than a bunch of words on a screen.

Great list of skills. How can you tell if you're doing a good job?

Most of these skills don't actually provide a tangible outcome or 'something to show' at the end of a working day. This can be difficult when reflecting on your own progress and development as a UX designer.

You have to change your perception of what is success, or even work. It's fine to join a call where you help break down another teams work and support them to build a great product - even if you don't have anything to show at the end of it. Some days you won't open design applications or tools. Other days you might have the markers out sketching diagrams and ideas. It's important to remember the purpose of what you're trying to achieve and look for indicators of progress. Celebrate your own successes through others.

Could this be where UX is heading?

Thinking about one of the many possible futures over the next few years. Let's say design systems continue to rise in popularity and this isn't just part of a trend spike. There might be a point where designers only work within the context of a design systems. These skills could start to become more 'expected' than you might expect.