Creating a practical design solution for startups! Part-I
3 years back I started my journey as a Graphics Illustrator and then slowly took over learning about the UX of building SaaS software. PushOwl started as a small app servicing a few hundred merchants to now power more than ~25K businesses.
If you are a designer handling everything at a startup or researching how to manage the design files and their components at your company, this blog is for you. :)
Being a product designer at a startup means you have a list of things to do:
- Stay in touch with your users to understand how they are using your product
- Make sure that the design handovers are done correctly with the devs so that the outcome is as expected
And while juggling between these everyday tasks we often forget to pay attention to one of the most important but underrated parts of our design process. Maintaining the components library of our design files.
18, 19 or 20px?
Have you ever found yourself having a conversation like this with your fellow designers in your team?
If yes, you are not alone! :P
This is how often we found ourselves discussing smaller details like spacing.
Repeat the same for colours, names, components, font sizes, layer names, everything. Often times we create duplicate components just because we couldn’t find the master component for the older one.
Imagine searching for components out of this mess? You would be like I would create a new component instead of “it's ok.”
This process just makes your work tougher. You end up with numerous and duplicate components for the same purpose. Each with components having different spacing, without any names. Or worse, with randomly named components based on ad-hoc needs, and then not able to recall what the component stood for.
Here is an example of how it looked for us at PushOwl👇🏻
The metric tracking game
This isn't even where it's all done yet. It gets tougher when you want to track the performance of different UI elements and you are not able to find the right tokens to search for. I’ll show you one such example below
See our component name? That’s because we never consistently named our components to keep tracking in mind. We often get so engrossed in designing that we forget to address the minute yet crucial details of designing and creating the files. The result? We end up blaming the devs for not naming it right. But, the truth is, devs just followed the process that we, the designers, set.
Let’s fix it, but! From where?
We all know what we want to achieve — a streamlined design process — but it isn’t as straightforward a solution as we’d like to believe.
As we started researching what everyone in the industry is doing to fix this issue among their teams, most designers swore by a “design system” as the perfect solution.
So, we tried to find out what this design system was and how to set it up.
Most people assume that a design system is for companies like Google, Airbnb, Microsoft, etc. This is mainly because the impact of a design system is very clearly observed and noticed at a larger scale compared to a 1 or 2 designers team in a startup. But, that doesn’t mean startups shouldn’t adopt one.
A design system is a living document that speaks about how a product's visual language is shaped and translated into real front end code. And be it a small team of 2 or a team of 20 everyone gets benefited from this. Just the use case becomes a little bit more focused on a small team.
As a small team, you don't need everything that these brands and their design systems have in them. You can pick out what is beneficial to your product and plan out your custom design system.
Wondering how to set it up? We’ve created a framework for you. 🎉
Fix the basics
Every product is based on some core elements. Once you’ve set that, then, 60% of the battle has been won. These are
1. Colors
Just defining more colours isn’t enough. These have different use cases. What colour to use for titles? What for body text? For hyperlinks? For CTAs?
Pro tip: Prepare a list of places where you will be using different colours to create a visual hierarchy. Test them out before finalizing your colours and their different use cases. You should ideally generate each colour combination to have a contrast ratio of 4.5:1 for normal text and a 3:1 ratio for large text2. Fonts
Fonts take most of the visual space in any product design. Chose them wisely! It’s always best to have a discussion between the dev and design team to decide whether to go with system default fonts like — Seogue UI for Microsoft, SF Pro for mac, etc., or pick a custom font that better matches the overarching visual identity.
The advantages of using system fonts outweigh custom ones:
- Reduces the load of deciding what font to load for fall back fonts
- Devs have one less script to run within their code
- Since these are system defaults, you don’t have to spend time over its research
But this also means your platform will appear different on different platforms because of varied fonts. Plus, while designing, how do you decide which platform to pick as default?
If you are someone who is specific about their font selection and branding, you would want to go ahead with your selected font. This means your platform will have a consistent appearance. This also means you need to keep a constant track of how the platform looks on each platform and break anywhere because of the font not able to render correctly and define the fallback font for the same.
Our pick goes with a custom font. The current set of fonts aren't very heavy to load on modern-day web-based platforms. there are tons of places where you can find great fonts. One being fonts.google.com.
Define your scale. What will be the size of your largest font vs the smallest font? where will it be used? Again! somebody has already done the job for you. you need to find the right one and plug it into your design process. These scales, sizes are tested and well researched about. so they won't fail you if picked correctly. :)
3. Spacing
A px here and there might sound nothing, but it can visually create discomfort for a person seeing it. A consistent scale ensures that the content is easy to read, and the user finds the content they are looking for.
We picked material design spacing guidelines. Why? It works for our requirements and takes smaller spacing plus larger spacing problems pretty smoothly. Test it with your components, design screens, and then decide. They have done the hard work already. You just need to identify what’s working for you.
4. Naming component
One of the most ignored parts in designing the products or completing the designs is naming the components correctly so that they are easily found, and there is a common language shared between the dev and the design team.
Hey! But how do you find the correct way to name the components, elements are?
Simple answer talk to your developers, researchers, and data analysts in the team first to understand what language they use while addressing those elements — for example, some prefer calling a CTA a button. How do you find what’s correct? Talk to people.
In our case, when we spoke to our developers and other team members to realize every developer uses a framework/ CSS library to translate the UI designs. This helps them in faster work and less hassle of making things from scratch. Tailwind CSS library is one such library that a lot of developers are preferring, which means most of them are well aware of the terminologies used in these CSS libraries. Instead of finding the naming conventions ourselves, why not again use something that is already existing. You can check out the library here.
So much hard work, but what’s the result?
We may not be able to fix all the issues, but we have addressed some of our team’s major ones and I can say it will help your team too. Listing some of them down
Consistency
With things in place now, the platform and the designs look more consistent, the brand and product have started to appear more complete than ever before. The gap between the dev and design has reduced drastically. What we create on Figma is how we see it on the final code.
It was there before as well (our devs are superheroes🦸🏻♂️) but now with smoother handoffs and less confusion.
We got your back, the dev team.
Working closely with the dev team enabled us to start thinking like a developer and not just a designer. While designing, it is as important to be aware of what tech is capable of serving. I don’t say stop innovating, but I would encourage discussing, sharing ideas, and thoughts more frequently with the dev folks in your team, to understanding how you can better work together.
This collaboration helped us know that instead of using groups if we use the auto-layout feature in Figma, the CSS generated is much more useful for them than the other way round.
We speak the same language.
In the past, one stakeholder would say button, and another would call it a CTA. We have agreed on common terminologies to address various elements, components, features, and actions to keep ourselves in sync and create less confusion for each other while talking.
Everyone is a Designer!
While working on this project, we realized that everyone is a designer; everyone has an idea they want to bring to life. A team member shouldn’t have to wait for a designer to help them create a POC for a feature/product idea. Instead, they should unleash the designer inside them, get their work done easily, and move faster.
This project has given much-needed power to the team. No one has to wait for us to suggest a small change or try out a feature variation. They can just easily drag a few components, create a layout, and tadaaaa! The POC is ready for discussion.
This process isn’t something that can be achieved within a week or two. It takes months to get things right.
While most of the information is available on the internet, you need to do your own research, test it through your designs and processes, and check if it works for your team. Our design system and our process for it may not work for you. This is why trial and error is very important when setting up your design system.
Have a great day! :)
