Blog

In a big organization, there are a lot of moving parts across various departments and projects and when the goal is to create a single design language, keeping a consistent design can become almost impossible. My strategy for this was to develop a core design team who would be responsible for designing the individual components of our design system which could then be deployed and consumed by designers who worked within project teams. This was met with a huge amount of resistance as people seem to think that having bums in seats within projects would speed things up and deadlines would be achieved. However, the goal is to have a consistent design and building up a living style guide would provide us with a platform that all teams could understand and consume the required components in which to apply to their designs. Ultimately project teams should be more focused on other priorities like functionality, better user experiences and align all projects into the specific channels that will deliver these to the people who will use them.

In order for me to explain this over and over again, to which I have mildly had some success, I have managed to create the analogy that this core design are busy creating the system, which if I get my way, will consist of pairing up designers with developers so they can dev these components and test, break and animate them before committing them or rolling out several static designs, is call these my Lego block builders. Their responsibility is to make the Lego blocks which the Lego builders will consume to make the Lego models. There is a very generic list of components almost every project may consume from (atoms), there’s how you piece these components together (molecules) and then there’s the way they work together (organisms). The Lego builders consume this within their various projects and should they need a specific block that does not exist, it is their responsibility to identify it and bring. it to the core design team who will then work with them to create the blocks and how they work together to deliver on the projects needs, feeding back into the system for all other Lego builders to consume. I have borrowed some language from Atomic design principles, and we have probably all played with Lego, so this should be language most people can understand.

I am often told that this is not agile and this is creating silos etc. Maybe, but it’s necessary if you want to have a single look-and-feel that represents the brand consistently.  Spreading the design out across multiple teams, on multiple projects, in various buildings would simply not work. While I could move across all teams and keep alignment, the task is too great and much easier to control by giving out a set of guidelines for teams to follow. It’s a subject for another post, but living style guides and designs systems are necessary and utilised by most big organisations who want to create seamless experiences for their customers, but throwing tons of resources won’t develop this any more successfully than rather putting a core team together who work with each other to solve the visual design challenges and deploy them into the style guide and then iterate accordingly. I think the challenge is to identify the brick builders from the Lego designers who consume the bricks and make sure that there is still enough design challenges for everyone to be inspired no matter which role they are best suited. The other is getting people to understand the vision and hopefuly make them understand that in order to be consistent and speed up the design process, a small core team is the most practical solution I can think of.