Building a design system with limited resources
The birth of our first design system
When I joined Iken as the first in-house designer, I became frustrated by the lack of consistency in Iken’s products after just a few months. It became apparent that something was missing.
I ended up doing a lot of technical tasks and spending too much time thinking about how the current design will impact usage in the future if specific changes are needed. As a result, I kept doing temporary patches for specific User Stories that won’t last long, and it became a race between sprint deadlines and creating sustainable design components. At the same time, looking at the trajectory of the company’s growth, I could see that the current system was not scalable if we were to develop more products and deal with more issues. At this point, there were many possible projects in the pipeline already, yes, it’s exciting but if (when is probably more apt) those projects come to be developed, I would have had trouble managing all the work and potential overheads.
So, I started documenting every component and asset we’ve ever had and put them together in one place. I picked Zeroheight as our go-to platform for our design system because it allowed me to quickly put together something that is useful for QA department and Developers.
How
Everyone knows that building a design system can be expensive, labour intensive, and it takes a long time to build one from the scratch, and worst of all, not all stakeholders will understand the value of a design system. Especially when you’re a small or medium-sized company. Heck, if I were a manager with no design knowledge, I would’ve definitely been sceptical as well.
It’s one of the main challenges for designers that we come across in a professional world: Convincing stakeholders that our design brings value or an investment that is valuable for the future. Thankfully at Iken, I was given a high level of autonomy and trust in projects.
Obviously, expectations needed to be managed. Forget Shopify’s Polaris, Atlassian’s Design System, Google’s Material, Microsoft’s Fluent, or Salesforce’s Lightning. Big companies can afford to build a sophisticated and insanely detailed design system because they have the resources and capacity to do so. But what about start-up SAAS companies or medium-sized companies with the budget, time, and labour being not plentiful?
As a designer, time management and accountability are essential. I understood that design systems should be treated just like products, think MVP first, and scale up as the product grows more mature and complex.
Process
- In Iken, we adhere to the WCAG AA standard for accessibility. So I made sure all my design components, colour, typography, and motions are tested against the WCAG AA standard. I really enjoyed designing and planning components within WCAG AA standard constraints because it forced me to learn more about accessibility in more depth. I ensured that everyone contributed by taking notes from QA testers and developers.
- We already had an existing brand guideline, so I took my time not to redesign it all to the bone. I wanted to respect our brand guidelines and make it a part of the design system, not a tool to go against it. The same thought applied to components and design rules (at that time, not many and not documented) that already existed. I examined the components and picked the ones that needed more work and selected the ones that didn’t need to be redesigned. The core value of a good design system is to democratise design for the company, it is something that works for everyone, and makes everyone listened and respected.
- Have a clear method to build. I personally followed Brad Frost’s “Atomic Design” (oldie but goodie). I found this the easiest method to follow. Atomic design is atoms, molecules, organisms, templates, and pages concurrently working together to create effective interface design systems.
- There are a plethora of design system aspects you have to take into account before building one yourself, so I made sure I read up on all good design systems and learned from them. Check this link to see a curated list of design systems, check out this list as well. I tried not to get complacent with the knowledge I had, there are always more things to learn from others.
- I took out my notebook and I started jotting down my priorities in terms of component usage. I asked myself two main questions during this iteration: What components will be used the most? and what are the existing components I inherited from the previous design?. Standard components such as buttons, input fields, icons, modals, or tooltips made the cut to be on top priority components. Once I got a good list of essential components, I focused on those first. At this stage, I also fixed all design issues I inherited from the previous design, so the design system wouldn’t have inherited any issues that are embedded in them. I took my time at this stage. I kept reminding myself that I wanted a design system that works and useful for everybody as well as sustainable. I did this process in my spare time, mainly when I had extra time while waiting for feedback, lunchtime, or just half an hour to an hour before I clocked off for the day.
- As I did my usual user cases, design sprints, research, etc, when I came across something that might be useful as additional components, I wrote it down immediately in my list so I didn’t forget. When I had the time, again, as mentioned above, I spared some time in between projects to accomplish my set list of goals. I made sure this process didn’t affect the flow of our sprints.
- At this point, I think it had taken around 7 months to get the first design system MVP launched. I knew it wasn’t perfect, it’s still not perfect now but I know it’s enough to help me and others in building products and testing, it will help as consistent documentation at the very least. I applied the new design slowly in our version 2.0 products carefully.
Take away
I think it’s paramount to remember that building something that is out of the scope by stakeholders is always daunting and hard. But understand that if done right, this will pay off and others will see how you envisaged it to be.
If you’re building the design system in a small team or as a sole designer, it’s not going to perfect, and that’s okay. Design systems are supposed to grow and change over time depending on trends, users, and other many variables. There is no finish line. It’s a continuous journey to improve user experience. Don’t get precious about your design.
You just have to start somewhere.
The benefits of having a good design system are:
- Focus my attention elsewhere that’s more important. Particularly, when you’re working in an agile setting, having a comprehensive, structured, organised components, and sets of consistent design patterns would help to speed up the delivery process in sprints. I spend less time doing mechanical tasks and I’m able to focus on research, prototypes, etc.
- Time and cost-efficient. Let’s be honest, not having a good system can cause extra money, most likely to hire new designers to compensate for the overwhelming extra tasks, or the alternative is to hire a design agency which can be more costly. Having a clear design system allows designers, QA testers, and developers to not waste time on repetitive work and queries, and meetings. We can focus our time on delivering results faster.
- Consistent design and experience. Having reusable components, uniformed assets, the same set of design principles across all platforms allow our products to have a consistent look and feel, interaction becomes more intuitive, the learning curve to understand the interface is lower for new users. In general, the user experience becomes much better.
- Collaboration is better. Having a single source of truth for everyone helps all team members to be on the same page. Not just us in design, development, and QA department but marketing, support, and sales can take advantage of this too.
A good design system is an investment for your products to scale up in a consistent and controlled manner. What I learnt from this process was: If you manage your time right, even with tight resources you can still find the time to make something useful. It’s not without challenges and it’s not just for your company but you would be saving yourself a lot of time and stress in the future as well.
