Scaling a design system from a side project to a bigger initiative
How would you navigate the following situation?
- Design system started as a personal passion project by a designer
- Only one internal designer and plenty of development-heavy teams
- Teams spread across several countries
- Agile service development preferred
I was recently asked for advice for a situation like this. That short exchange touched on so many enticing and tough topics that I knew there’d be more to explore if I’d work a bit more on it by writing.
When it’s really just you driving the work
I’ll start with a couple “no extras” scenarios. In these, the design system really is driven by one person — someone who may have other responsibilities on their plate as well. Sooner or later, that workload is going to be too much. Either the work or the person suffers. Most likely it’s both.
If you’ve already started reaching out to various teams about the design system or have even gone through the first launches, the growing workload may be a positive sign. It’s picking up momentum. Now, you can say that the design system has reached a point where it can’t be scaled without re-thinking the resourcing.
If you find you’re being constantly pulled to other projects, discuss with your manager on how you do your best work. The overall situation may not (yet) allow for you to work full-time on the design system… but if there are simply too few designers to go around, the weight shouldn’t be carried by you alone. Finding a new weekly schedule may help.
And finally, if you see the need for a design system but don’t know where to start… Start with standardising your own work. Establish an UI library that’s efficient enough so you can produce more prototypes with less time. Or do the same amount of iterations as now but spend more time validating those ideas. Or to prepare less stuff for handovers and reviews and having more fruitful discussions during these.
It may not be a design language universally acknowledged within your company. It may not be a design system that facilitates easy access to the latest assets across teams. And it most likely will need to go through several major iterations to become one. But it should provide you with practice, a “one person/team showcase”, and eventually, some extra time to spend.
For the rest of this post, I’ll focus on ways to spend that extra time.
Rooting down a design system with pilot projects
The good news is that there is no shortage of developers. A design system that only covers assets for designers isn’t going to have the same kind of impact as an end-to-end system has. After all, it’s not the design system site or library that your customers are interacting with — it’s your company’s live products and services.
The following may also be true:
- Teams are encouraged to pick their preferred tools and technologies
- Little to no centralised guidance and checks
While there are many benefits to this approach, it means you’ll have a bit more work cut out for you — or for a tech lead that may or may not be available to figure out some answers to these with you: Which technologies would need to be supported eventually? Is there such a thing as a framework agnostic source for your company? Which tools are team members most comfortable using? If teams aren’t able to have “off-the-shelf” styles and components but would be expected to build similar ones (in addition to existing backlog items), won’t they feel tempted to just keep going with whatever they already have?
Rather than aiming for “one system to rule them all” in one go, start with pilot projects. And work with what’s already there:
- Identify the customer journeys that have the most glaring discrepancies and pain-points for customers (and business)
- Seek out the teams that are working on these
- Ask what kind of libraries and evaluation criteria they’re already using
- Work with them to identify what kind of recurring tasks they’d like to have a designers’ input on
- Ask product owners (and/or other relevant representatives) what seems to be slowing down their team’s work most to see if there’d be anything a design system could help with
Working with the existing organisation culture
Based on the short description, I’d assume that design maturity within the organisation (reflected by staffing) is low. This may also mean that there’s…
- Less experience leading and supporting designer’s work
- Lower investment priority for design
- Thinking of design as prettying things up
Hence, less people will identify with design as something that plays a part in their day-to-day work. Depending on their work background, design related processes may be either familiar or completely foreign to them.
There’s no need to hide your “designership”. Be proud of your work and talents. Raising design awareness in small but persistent could very well be part of your job description. But treat the existing culture with the same respect and curiosity you’d like others to treat yours.
Giants like IBM and Ericsson have established vibrant design communities over the past years. Small-to-medium enterprises may not have as massive resources to drive change programs like this (though, I’d like to know what those initiatives were in proportion to the business in question). But every company has existing long-term goals. Showcasing that a design system would be beneficial in reaching those existing initiatives strengthens the arguments in favour of it.
Finally, outsourcing may well be a legit strategy for your company. As an agency representative, I’d still like that the money you invest in us would be well spent. Proving that we have an unique perspective or taking on spearhead projects so you can see what they could grow into may well be part of our business… but if all of us start from scratch, trying to woo our respective project stakeholders, I suspect we’ll be eating away at those budgets we first worked to secure to run a stable collaboration with you.
Having sufficient resources for it — including time and people
Normally, I’d expect to have at least a two person team for a design system. It’s hard work to establish high quality, well organised, flexible enough standard assets — and to ensure they become a natural part of everyday work across teams.
I‘d also allocate about a third of the design system curators’ time for communication and community building. After all, a design system without proper feedback loops is not a design system. And any initiative that’s going to impact the way things are done but is not communicated well is going to appear either as secretive, irrelevant, or badly managed.
While I’m happy to join an organisation as an external consultant to root down a design system, the lack of internal design resources would worry me. A part of my work would be to find the right people to establish a sustainable enough budget for the design system — be it staffed internally, externally, or with a hybrid team.
I’d also recommend having an internal product owner for the design system, both to give the design system a certain acknowledged position, as well as to have a person present in those alignment and steering sessions which product team members and external employees aren’t typically part of.
To any in-house designer keen to establish a design system within their organisation, I’ll recommend talking with their leads and managers:
- What kind of opportunities you — and they — have identified
- How your time and input could best be used
- What kind of support you’d need to take this forward
I’d also seek out those who are typically overseeing freelancer and agency work:
- To ask them about their kick-off and review practices
- To identify what it would take to make an existing style library more easily available for external suppliers and partners
- To see if any regular, external contributors may be willing to take part in some feedback and sparring sessions
Eventually, you’ll be faced with a more or less direct question of “who authorised this?” — or “unfortunately, we don’t have the time for that”. Without proper backing as an official initiative, you’ll have less people to support you (or play the leading role) in these negotiations.
Finally, I suspect being located in various countries is a lesser issue (if any) for collaboration. Teams that sit side-by-side each day and attend shared meetings may contribute little to each others’ work. Time allocation and finding shared rituals that work tend to matter more.
Set a scope to it
Being clear about the scope you’re aiming for is essential. It’ll carry you beyond the messy middle when unforeseen challenges kick in. It’ll also allow you to say no to all those other enticing directions:
- Building all assets from scratch to fit the particular needs of your teams vs. testing a sufficient number of existing, open-source libraries to see which would be the best fit for your company’s needs for the next year or two
- Offering a plug-and-play UI library (or mini site) to serve as a shared reference vs. offering developed, pre-tested “live” components that are mature enough to not undergo breaking changes every few months
- Covering a very comprehensive set of assets vs. limited set of most used, basic assets and styles only vs. focusing on the more complex, re-usable modules (e.g. forms, sign-in, navigation, …)
- Hosting weekly, open collaboration sessions and working closely with other design system champions vs. opening a dedicated design system channel where you post regular updates and invite others to share their thoughts vs. tapping into whatever existing peer-to-peer sessions are available to you vs. doing all of these
- Do first-hand validation with end users and/or within live service vs. rely on existing knowledge gathered by various teams vs. do both
- Reviewing each and every contribution before making it part of an official design system release vs. providing a platform and simple enough rules for everyone to share and use components created by others (without turning into a veritable jungle over time)
- etc.
It’s OK to be in an exploratory stage every once in a while to see if the direction is still right. It’s OK to create visions that are so ambitious you feel a bit embarrassed to admit to them. But if there are no achievable milestones, you’ll feel like you‘re falling short all of the time. There’ll be more pressure (real or imagined) to charge onwards without sufficient iteration along the way.
Yes — it’s a lot of foot work. It takes time and practice to find the right arguments that resonate with the various stakeholders you’ll need on your side. It may even feel like a setback, if e.g. all you want is to see those beautiful assets go on to live in amazing solutions. But to make it happen (beyond projects of your own) and to retain a semblance of work-life balance, you’ll need to rely on the help of others.
After all, you definitely want to create a “pull”, not a “push” kind of situation for your design system.
Hi there. For the past few years, I’ve been working on several design system initiatives. I’ve also helped curate a book called “Hack the (Design) System”. It’s always great to work with a wider range of talented people driving design systems in their respective organisations. My design system dream team would consist of a product owner, UX copywriter, designers and developers, varying contributors on an as-needed basis, as well as a steering group who’d be able to support us.
If you’d like to learn more, feel free to either reach out to me or your local Idean studio.
