Have you ever seen the LEGO documentary on Disney+? It talks about the history of LEGO and if you’ve seen it, you might be familiar with a phrase that’s said many times in this documentary: new Lego products should be part of the system.
The original LEGO designers envisioned a system, mostly based around the grid pattern and being able to snap pieces into each other. Bricks that follow this system are the classic 2×4 Lego brick, a 2×2 brick and others (like half height bricks). They envisioned that with this system, you could basically create anything you wanted.
However, as the documentary progresses, it talks about how new people came in with new ideas, and these new ideas were not necessarily part of the system. The new pieces did not fit the original system, used another system altogether or were difficult to mass-produce. They were very set-specific and didn’t play well with other sets. Consequently, they did not fit the system.
Naturally, this caused a lot of discussions within LEGO.
As a designer that is both responsible for envisioning designs that work across hundreds of screens and with a fair bit of experience in design systems, I find myself on the side of the discussion of the original LEGO designers sometimes: the new component/icon/code etc. has to fit the system.
But then, sometimes I am envisioning something entirely new; and at this point, in an early design stage, it’s not very helpful – not even to me – to see how it would fit the system. However, as you get closer to the implementation reality (also see: the three types of product designs); you inevitably have to check how whatever you are designing fits the system.
Another case could be that the implementation is not a real implementation but demoware, in which case, you might have to deal with the fact that you are implementing something in the system, which is not actually part of the system, but it might be after it’s validated. Or you might have to deal with people who now think it’s part of the system, when to you, it’s not.
As a product designer you are expected to be able navigate around all these realities, depending on which conversation you are having. This can lead to very schizophrenic conversations where on one hand, something exists in a given system (e.g. design library), yet it is not implemented in another system (e.g. front-end library) yet an expectation exists from stakeholders that it’s there. The work to bring the system together is typically undervalued by stakeholders since it’s not considered “real work” (which seems really weird to me); but if you skip that kind of work, my experience is that the end result suffers tremendously.
A weird thing that happened the past years is that, because design systems demanded so much attention, and front-end developers screamed a bit much to put attention towards these systems – something making the system the actual work, instead of the end result – design systems kind of got a bad rap by managers. I believe some people burned design systems by forgetting the reason behind them – implementing actual user and business value.
I am the first to say there is too much design systems & component talk in general, and people should focus on results, but I seem to have internalized the design system approach enough in a way that it’s obvious to me how to move things across from Figma to a front-end library.
Depending on who you are talking to it is not that obvious and it’s up to you as the designer to find a way to make the actual very explicit (in order to do A, we need B, C and D).
Then from another standpoint, as a product stakeholder, it might be worthwhile to think ahead, that if you want your idea to make it into reality, maybe it’s better if it… fits the system? But here I diverge, and I am not really talking about front-end components here, but about fitting into the universal vision of the product. But that’s maybe a topic to revisit later.
If you enjoy these product posts or something stood out to you, let me know, because I am not sure if I am rambling or making sense. In any case I enjoyed the writing of these myself.
1 Comment
Thanks for posting this. I think system fit is a good way to think about these things. For example, mac’s design is to intentionally not fit the system laid out by apparently every other OS people actually use: specifically the modifier keys are backwards, and then the functions they perform are scrambled and some are missing. It drives me up the wall. Muscle memory goes out the window and it interrupts your flow state just so it can remind you that you’re using a mac. It’s not yours (even if you payed for it) and you cant change it in any meaningful way.