~ 8min. read
Awesome, Buzzvil is getting a brand new design system. Yay ~
But we can’t ignore how time consuming building a system can be.
Is a design system really worth all the hassle? And, can a startup get any advantage from it?
Yes, and yes. It definitely can.
To understand what’s at stake, let’s have a closer look at the problems we are trying to solve.
We, at Buzzvil, are building scalable services for multiple partners. We are young (and beautiful) but we also have to build complex products that have to be permanently maintained and constantly developed.
That’s our first and main problem: answering our business needs.
How can we organize our design to cover our diverse and growing needs with a modest team?
The products we have to fully take charge vary.
Two in-house apps, a white labeled app coming up soon and a bunch of SDK and API to manage (not counting all the necessary marketing work that comes on top of it, or even mentioning the dashboard to manage and operate all that.)
It starts to sound like a pretty big product line already.
Systems are all about connecting things together, allowing these “things” to be reused at different places. That’s what we’ve been doing, factorizing our design assets into reusable components. Easy peasy.
Technical debt also applies to design. We don’t spend time doing things twice, saving up time to think more.
This was our starting point. A major problem, solved thanks to the construction of a system. We started working on this about 8 months ago and on the way, different issues were solved through our system. Here are the main insights
We are small company that dreams big. Big enough to have clients all over the world. Being a global company is definitely awesome, but it makes you realize that your design needs to fit people with different cultural backgrounds and various levels of appreciation and understanding toward technology and aesthetics.
Fortunately, we aren’t the only ones in this situation. Designers who once tackled the same problem like ours created a standard that was flexible enough to fit any product, also known as a System.
That’s our second problem, being understood by anyone:
How can we design scalable global products that fit a wide spectrum of people?
Complex problems usually require simple solutions.
Ironically, if you have experience designing products, you will agree that making things simple.. is pretty complex.
When designing an application, we carry a visual semantic. It is a form of language that is expected to be understood by people using our service.
By reducing the complexity of that language we expect it to be understood by more people.
Minimalism in design comes from this mindset. Simplicity is key.
By keeping things simple, more people will understand what you want to express.
But what does simplicity has to do with a systematic approach?
Principles. Working with a systemic approach means setting principles and procedures in order to organize our workflow around some common grounds and values.
In our case and to answer our business requirements, minimalism is one of our key principles to fit the diverse markets we are in and to be manageable to a small design team.
As mentioned earlier on standards, our team started from Google Material Design and built our own components and principles from there so we wouldn’t have to start from scratch.
There were a few solid reasons why we started building our own system this way.
First of all, Material is an incredible design language that constantly evolves. And second, Material is already widely spread, reused, and refined by billions of users throughout Android OS and major apps that follow Material Design. By revolving our design system around Material would mean that our users would be presented with something that’s already familiar to them.
Buzzvil internally manages Slidejoy and HoneyScreen as our two in-house clients. Our product scope also handles what we refer to as Buzz Product line. It includes BuzzScreen, BuzzStore, BuzzOfferwall, etc. This product line is brand-less, as the products have to be integrated with our partners throughout the white labelled app and other SDK and API. And of course, each of these partners have to express their brand identity throughout our services.
This leads to our third problem: meeting various brand needs.
How can we manage multiple brands across our different services?
To this dilemma, we needed an answer that supports third party brand integration in order to fit each of our partner’s needs.
A lot of theories and practical examples are out there as systems are spreading across IT companies, but I found Daniel Eden’s approach most suitable for our needs.
Eden has an interesting way to organize and structure a design system. Everything starts by separating your design assets into 2 layers, pattern and expression.
The pattern layer
Patterns are our asset’s layout. They give exact specifications on how our components should be executed. Patterns are carrying components made of sub-components and so on. They are expressionless, they don’t carry any message whatsoever. Components are reusable within a service and even across our entire scope.
A great system factorizes components to an optimal amount, getting rid of similar ones across our entire design scope, the goal here is to make our life simpler.
The expression layer
The expression layer carries a message and is the root level of our components. In other words, they aren’t composed by any other sub-components.
We generally refer to them as Atoms.
This is where our branding, our tone of voice is contained. Expression layers are colors, text strings, icons and illustrations, photos and videos. They express a message and are ruled by a specific brand guideline, independent from our UI structure.
Now you probably start to understand how scalable this approach is. By identifying everything and thanks to awesome tools such as Sketch, it is now possible to connect pattern and expression layers with ease.
System’s weakness is on how flexible they are. Balancing between a too rigid or to soft structure isn’t an easy thing. Cutting it into these two chunks made things much easier for us. Blocks just like expression aren’t always from designer’s responsibility as blocks will most likely be integrated by developers and expressions are gonna be handled by marketers to set the brand’s tone of voice. These two chunks will need different types of communication as you won’t translate the same message to a developer or a marketer.
The difficulty of reaching a great design is to connect the different stakeholders over one clearly identified Design concept.
Patterns need to follow devs guidelines while expressions need to be flexible enough for a brand to be loud and clear or a content to be properly displayed. And in the middle of all this, our work is to connect the dots to make sure that in the end, everything is cognitively affordable to people.
In Daniel Eden’s article mentioned earlier, another layer called concept is mentioned. This is how we communicate things to our different stakeholders and where our design is evaluated.
This is our fourth and last problem, our design needs.
How do we communicate and evaluate our design concepts?
Concepts tell a story. A concept is about communicating an abstract idea by any possible mean. This is where designers must make a difference which is why we have been working on a system: to save up resources in order to be able to spend the necessary time on visualizing/materialize ideas over concepts.
To rephrase Eden’s words,
if the expression layer is our alphabet, the pattern layer our words and sentences, then the concept layer is our story.
Building an alphabet and a dictionary are foundations to work on what matters the most: the story we are gonna tell to people.
The quality of our foundations affects the clarity of our message while the quality of our story affects the overall experience of our products.
But then, how can we tell if a design is good?
Concepts are made of assumptions that are based on theoretical and practical research. Empathy cannot be easily controlled in advance and testing things out is definitely a great way to judge either your design answers its purpose or not. And to objectively judge something, metrics are key.
In our system, each concept carries a set of metrics that will tell us after testing if our assumptions were right. Just like the entire system, metrics aren’t written in stone. Things are flexible, and can always be adjusted after the first tests. If the results aren’t as expected after a few loops, it means that our concept wasn’t right and needs to be fixed. We assume that our core components are pretty robust and won’t be the main cause of a poor test result, but their assemblage might be in cause.
Another way to say it: your words are all orthographically correct but your sentence isn’t properly constructed and what you need to do is to switch words around to make the grammar right. If that doesn’t work either, it probably means that your entire concept needs to be thought over as the message isn’t answering people’s expectations.
Having a design system is a great way to deliver a design. Yet, we can’t expect everyone around us to think and work like designers. But what we can definitely do is informing them and eventually allowing everyone access our resources to build up rough concepts from pre made blocks. This sounds like a promising experiment we can try.
Although great ideas come from every mind, designers have the necessary tools to easily express these ideas, whereas our co-workers don’t.
Sharing our assets is a way to help not just our co-workers but anyone communicate on an idea.
Sharing our early concepts, principles and design culture is for everyone to understand our process and to understand how sharing ideas is never a useless thing. In the end, a single concept could resonate in a different way to someone else, bringing up new leads.