2 weeks ago I started a 3 month contract with Babylon Health, product managing its design system. Before that, I was working as a Senior Content Designer on the GOV.UK Design System.
Starting this contract represented a number of pretty big transitions. For example, I’ve gone from:
- the public to the private sector
- a permanent employee to being self-employed
- content design to product management
- being a doer to being a decision maker
- an established organisation to a startup
- a fairly mature design system to one in its infancy (Babylon's design system is just about to launch)
- a design system serving only web to one serving multiple-platforms
I’ll admit it’s been tough at times. Taking on so many new challenges at once has brought on a bout of imposter syndrome and moments of unpleasant self-doubt.
At the same time, I’ve learned an enormous amount in a very short space of time. I’ve met some great people doing important work. I’ve been reminded of what a strong and smart support network I have. And the fact it’s been challenging has made the wins - even the small ones - all the more rewarding.
Understanding a new design system
When I began working with the GOV.UK Design System team, we were just beginning to build an alpha, and by the time I left it was well-established, widely adopted, fully-supported and receiving regular external contributions.
It’s been interesting, then, to go back to the beginning of that journey with Babylon's design system. To be asking afresh what’s really essential, and what can be added and improved iteratively as we grow it.
And the stage of the project is only one of the differences. Whereas the GOV.UK Design System only needed to serve web, Babylon's design system needs to serve iOS, Android and Web at the very least, with other platforms likely in the future.
Having always been in one of the less technical roles in the team, this makes answering questions like “how do we get things into production?”, “how might we rollout updates?” or “how would someone contribute?” challenging, and I’m not done figuring it out yet.
Another key difference is that the GOV.UK Design System was introduced at a time when the brand and the audience were fairly well established.
At Babylon, the design community has grown rapidly and will continue to do so. Product development is driven by autonomous teams, and while things are consistent to a point, a lack of centralised standards means discrepancies have crept in.
In some ways, introducing a design system into a rapidly changing organisation is easier: introducing a new system in government required a cultural shift, and our work was often met with suspicions that we’d have to work to reassure. In Babylon, change is the norm and the organisation is set up to respond quickly.
But it also means we’re trying to rationalise a moving target, and that’s complicated. If we can’t keep pace with the organisation’s growth and change, that could hamper the system’s adoption.
There’s a lot to tackle, and I’m slowly learning which GOV.UK Design System lessons will help here, and which aren’t relevant.
Leaning on others
One thing that’s been a massive help over the past couple of weeks is to really make use of my support network.
Much as we rely on design patterns to help us solve the well-trodden problems, I’ve sought guidance from those I know I have experience in dealing with the challenges I’m facing now.
My former GOV.UK Design System product managers Alice and Tim have been particularly kind and patient in helping me to navigate a couple of tricky “what do I do now?” moments.
I don’t think either of them will object to me saying that they have pretty different product management styles, and their different perspectives and strengths have been a big help to me these past couple of weeks.
I was also lucky enough to have a coaching session with Nathan Curtis who helped me to focus on what matters most given the stage the project is at right now, and the fact that I may only have 3 months in which to help.
In addition to that, I’ve also had countless words of encouragement and words of wisdom from my friends, family, peers and people I’ve worked with and, I'm pleased to report, people at Babylon.
Getting comfortable with an absence of information
It’s a strange thing, having gone from feeling I was at the top of my game and able to comfortably stretch myself beyond my role, to being somewhat back at the beginning again.
Obviously I’m not back at the beginning again. I have a wealth of knowledge and experience to help me take on this new challenge.
But in terms of the team, the organisation, the technologies, the design system and the ways of working, I’m firmly back at square one.
I’ve had to quickly get comfortable with all the things I don’t yet know, and relax into learning mode. A lot of the product managers I spoke to on the run up to accepting this role advised me to be cautious of leaping into action too early, encouraging me to first invest proper time in understanding perspectives, research and background.
For this reason, I’ve been mostly acting as observer and facilitator in any product discussions so far, doing my best to carve out space for my team to share their views and help them reach decisions, without adding my own opinion to the mix.
Making decisions
That said, there have been a couple of moments where I’ve had to make a call on something or other. One such example was whether to spend time fundamentally changing the sub-navigation on our documentation site, following concerns that our existing implementation was making it harder to view important content.
We haven’t yet launched the design system, and any changes like this are likely to delay us, so have to be thought about carefully.
My approach to decisions like this has been to:
- get as much information as I can in the time available - in this instance, I asked what drove the decision to implement the existing navigation in the first place
- gather opinions - my team have contextual knowledge and experience I don’t yet have, so it was important for me to understand whether they felt it was worth delaying things to make this change
- make a call, being transparent about my reasons and any risks - I concluded that we should change the navigation, as we were confident that the side-navigation was a better solution and I felt it preferable to avoid making significant changes to the navigation soon after launch, if we could help it
That decision was fairly straightforward, others have been more complicated. I’m trying to take each one as it comes, weighing up how disruptive each given option will be against the impact of getting it wrong.
When it gets too much, I borrow a mantra from comparison coach Lucy Sheridan and simply ask “what’s my next right move?”
Accepting my limitations
Something I struggled with last year was saying no. Whether it was an invitation to speak at a conference, an additional piece of work, or a request to help someone out.
And it was never because I was afraid of saying no, it was because I liked saying yes.
But my workload now, coupled with the time I’ve got, and the cognitive load of learning All The Things, means I’ve had to quickly get good at saying no. A lot. I just know I’m not going to do a good job unless I protect my time and energy properly.
And I’m learning that there’s something surprisingly empowering in saying “‘I’m not going take that on right now”. Something as small as reaching Friday last week and admitting my weeknotes weren’t going to happen - despite having planned to write them all week - was a good decision I wouldn’t have made last year.
Taking what I need and leaving what I don’t
I quite often do yoga at home, following online tutorials by yoga instructor Adriene Mischler. Something she regularly advises when explaining new movements is to “take what you need and leave what you don’t”—using your intuition to determine which bits of an instruction are helpful for you, and which aren’t.
And I’m learning to apply that rule at work.
Everyone I’ve met at Babylon so far has been incredibly generous in taking the time to explain the background, their role and their perspective on the work we’re doing.
I’m really grateful for this as it’s helped me significantly accelerate my learning, but there’s no way I’d be able to retain all of it.
With limited time and information, I’m quickly fine-tuning my ability to decipher what’s essential, and what I can get by without knowing.
One example was last week, when someone gave me some advice on how to start creating a roadmap. I already had a plan for this, and their suggestion was something quite different.
Although I valued their view, and they delivered it fairly unequivocally, following their advice would have derailed my whole plan. If this had happened last year, I might have let it.
But I know my intended approach is solid because it’s based on first hand experience and advice I’ve sought from people I trust, inside and outside of Babylon.
So while I’ll certainly bank their advice as something to consider in future, I’m going to follow my instincts and stick to my plan.
At the end of week 2
It’s been a challenging couple of weeks and I’ve had my fair share of self-doubt.
But even in the toughest moments, I’ve remained confident that leaving GDS and joining Babylon was the right move.
As much as I loved working on the GOV.UK Design System and still miss it, my learning had plateaued and I needed a new challenge.
It’s only been 2 weeks, but I’ve already learnt so much, about Babylon, about design systems, and about myself.
I’ve been reminded of the strength of my support network, and I’ve met some brilliant people that I hope will become part of it.
Here's to the next week!