Design Systems and Product Velocity

2018-05-08

One of the biggest improvements we made to the way we worked at BridgeU was in how we approached our design system. This post documents the phases we went through and what I learned.

In summary, I was drawn to the juicy complexity and hotness of design systems but that they were a huge time sink and distraction from making high value design changes. Assuming the same product and business contexts, I'd rely on a UI kit like Bootstrap and only extend it for domain-specific components.


I joined BridgeU in late 2014. The UI was done with Bootstrap and a few custom Material-like customisations. We talked a little bit at the time about leaning more heavily on Material – continuing with customisations here and there - but we didn't deploy anything like a Material UI framework.

I'd used Bootstrap and Foundation for several years and I must admit I didn't really want to continue using them. I felt they were basic tools and that I wanted to graduate to something more sophisticated which my designer friends outside the company would be impressed by. I wanted to be working on something that would give me a sense of self-efficacy to learn. I later learned that this was a highly deleterious attitude.


I feel like this is a whole topic in itself and something I haven't read much about. If I could go back 5 years this would be the thing I would try to teach my junior self. Your priority as a designer is to deliver value – to the business, customer, user, you colleagues, whatever – as soon as possible. If you focus on cool and hot projects, showing off your capabilities, you might look good in the short-term but I believe delivering real value quickly is what will set you apart in the long run.

I guess the problem is that it takes a long time to calibrate value when you start working in a new business. How the hell are you supposed to know what's valuable to your customer if you barely have time and opportunity to interact with them? I think I could've done better with this in the past simply by having more himility and listening to my colleagues more, the ones who did interact closely with customers. I doubt this is a rare bias in people who do our jobs though. There's a Jobsian arrogance that is encouraged – 'you know what the customer wants better'.

I'm sure some of you will be saying to yourself "it's bloody true! They have no idea!" And perhaps you're in some super hip consumer tech startup which is actually creating new user behaviour. But I was in a B2B company where 1 or a few buyers decide what is needed for their entire organisation, and we received that decision in a metaphorical checklist format. Individual user experience is signficantly less of a factor than it is in a consumer product. Although on a level you probably do know what the user wants better than they do, you're not building for an individual user – you're building for a organisation. Individual user experience just doesn't bubble up to the buyer's decision to a degree significant enough to swing it.


In fairness, my viewpoint was that 'most Bootstrap sites look the same'. But I also recognised that there were plenty of companies who deployed Bootstrap well, and made it their own. Slack looks dated now but at the time they had created something impressive with Bootstrap.

People often say 'software changes are cheap' and that 'software is flexible', but it certainly doesn't feel like it when you're on a team building a product over the long-term. Bootstrap was in on day one and within a month it was clear that it was never coming out, save for a total rewrite.

At some point I actively suggested that we rely more heavily on Material - on the guidelines and on how we structure the design of our major components. I suggested that we actively refer to the guidelines when there's a disagreement about how a component should work/be designed. I also suggested that we start to build more major components based on their specs, to outsource boilerplate decisions. We were a tiny team with a lot to do and it felt like we were making a lot of decisions about tweaking individual components that we didn't need to be. It felt like letting Material handle that was a good way to go.

I think the first of these decisions was sensible. We were able to move much quicker and establish some good practices by pushing against the constraints of Material. For example, the Material Design Guidelines has a beautiful section about copywriting. It provided a great set of rules to work against when we were writing, for example, toast messages.

The second decision was sound too, but built on an unstable foundation. Obviously you want to outsource boilerplate decisions about the design of components but in doing so we took on an enormous amount of code to maintain, let alone the

We built out a topbar and a left navigation which looked great but took a long time. What strikes me in hindsight was how over-designed this was. Incredible. We literally could've just dropped a Bootstrap navbar component in there and been done with it. The left-nav is a slightly different story because Bootstrap didn't – and still doesn't – have a dedicated component for this. But still – we could've just dropped in a simple nav.

As time went on my friends Sam and Gonçalo – 2 excellent engineers – pushed me harder and harder about snowflake components. In design feasibility reviews they'd ask "why are we creating this component in a slightly different way this time?" and "this is good, but could we just do it with Bootstrap?"


Difficulty of startups – I was early mid-weight, but there were a lot of things that I needed to make decisions about for the first time.


I spent quite a bit of time building out my own component systems.


In hindsight I feel dumb to have thought about my tools this way because I saw first-hand how much inefficiency it creates.

It's pretty tired and cliché, but unless the people who use your product are people who create software, they probably aren't going to care less about the tech you use. Granted, this is slightly less true for the UI framework you use – software consumers are becoming increasingly sensitive to how good your app looks.


Copyright 2019 Jay Bowles Product Development Ltd.