I joined meldCX early January 2020 as a Junior Experience Engineer. Before I went on board, there were two existing Viana designers working on our product, and by then, our product was only two months old with no component library or set branding guidelines.
My team lead's first task for me was to work on Viana's initial component library in Adobe XD. Our components were built based on the React-Bootstrap Framework as a baseline, from buttons, alerts, banners, and more.
As Viana scaled and grew as a product, so did our need for more collaborators and visibility among team members — from developers, testers, and stakeholders. I took over as Viana's lead user experience designer about five months into the job.
I was on my own during this stage of Viana's design and development era as my co-designers opted for other roles and projects.
There were a couple of challenges that I had to carry on during my first three months:
Our designs were hard to keep track and update. Our stakeholders would need to bookmark multiple links just to keep up with our progress. For every new functionality, there had to be a new link. Adobe had to be downloaded before they could access our UIs and this proved to slow development down.
An evolving system on different platforms meant that our Adobe XD file was getting bigger day by day. And it was clear to us that Adobe XD wasn't cut out for our use case. There were more frustrations than joys, from losing important progress to eating up majority of our RAM, which meant we had to reduce our software consumption, quitting our browser tabs and all that stuff. Files would load for an hour, and we were losing so much time being productive.
Multiple designers working on a project with no solid design system is a recipe for trouble and confusion. As a result, users were burdened learning difficult systems and teams were not functioning efficiently. There wasn't a cohesive experience when designing for our web portal, no guidelines, no single source of truth of copywriting guidelines, and there was a lack of documentation.
When we started designing Viana, there was already an existing proof of concept portal that we had to build up on. As multiple designers came into the picture coupled with a lack of communication with front-end developers, our web portal had a mix of styles and colors making it quite convoluted.
My goal was to empower cross-functional teams perform at their best. This meant that we should be able to think like one organism and align ourselves from ideation, design, development, deployment, and testing.
So how did we go about it?
Besides building our design system, there were still quite a number of problems I had to face and it all traced back to Adobe XD. Why was our team performing inefficiently at our tasks? I consulted with a couple of mentors from outside our company and they confirmed what I had in mind all along: Adobe XD wasn't ideal for a system as big as Viana.
And so we decided to switch.
Of course that had to go through executive approval and convincing our team members from the design to the development team to adopt a new design application. After thorough research, consultations, and selling the idea to high-level executives (through back and forth emails), we finally decided to switch to Figma.
We migrated from Adobe XD to Figma using the XDtoSketch tool, which is a paid application that helped simplify the process.
Next, I focused on building a component system to make building across platforms with multiple designers a breeze.
My first order of business had to be researching on best practices from teams like IBM, Google Material Design (fun fact: our typography scale was based on this), and Atlassian. I also looked at existing SaaS products that we could emulate (Atlassian, Google, and Microsoft, were my top favorites). You could find more of them on the Design Systems repo website.
Once I was done with gathering references, I started to compile our existing components from the web portal to our design repository into one Figma page. I had to build all existing components from scratch and it was painstakingly a lot of effort as the only designer doing so. But it was necessary friction to improve our holistic experience as a design team.
So far our team has collaborated on the creation of baseline design tokens:
I focused on curating the colors and typography and our visual designer was assigned to create icons for our product.
I decided on naming conventions for icons, components, design tokens, and more. I referenced Atomic Web Design principles by Brad Frost, making sure our components would fit and scale on multiple platforms and use cases. However, our solution still needed custom components, and my general rule of thumb with components was to modify it as they see fit for their use case.
Eventually, Figma released new component features like auto-layout, variants, and interactive components which meant that we had to update our component system from time to time.
A Design Language System is incomplete without a source of truth. Our documentation tool of choice was GitBook. The next step required from us was to know who we are as designers, to fill in the gaps in our design philosophy as a team.
Viana Design Guidelines was made just for that.
Besides building a visual library for our components, we had to make our microcopy consistent across platforms. Our tone and voice had to be defined, like how we write our empty state messages, error messages, as well as something as simple as datetime conventions.
There were a lot of setbacks and inconsistencies still from the team, a lot of miscommunication and passive designing, but eventually we have learned to adopt components as part of our workflow.
Eventually, the free Figma tier was becoming a problem. There were too many outdated components to count and we couldn't add any more pages for new features. To solve that, I tried to gain buy-in from the design team to move into the Figma professional plan, and with the help of our design lead, we pitched the idea to our company executives.
After tons of work and team alignments, we were ready to get our Viana Design System V1 out to our team members to start testing it, hoping we could derive relevant results and insights.
Figma could be accessed from anywhere. Whether you were working on the apple ecosystem or a windows machine, prototypes and designs were readily accessible. If our Product Owner needed to review designs by the minute, they had direct access to our design files. Different prototype flows are accessible in one link so they could jump from one epic feature to another easily. As of writing, Figma is developing their own native mobile applications, which will help us get feedback even without having a computer nearby.
Faster feedback meant that we could have faster iterations. We could fail, dump ideas, and pivot faster.
The biggest improvement we gained from switching to Figma and having a set component library was increased workflow efficiency. As an agile startup, speed is the name of the game. We were expected to have designs ready by 2-3 days, and however possible this was for us, there were a lot of misalignment and inconsistencies within our designs. Input boxes, buttons, forms, and more were not part of a cohesive and harmonic identity.
From needing a week to present designs to stakeholders, we were able to reduce creating UI designs to 1-2 days (*depending on feature complexity). Our web portal components and design tokens were easily accessible in Figma across all project files (thanks to the professional plan).
Besides tokens, we had a reference for our microcopy. Something as simple as deciding what letter case a button or a label should have or perhaps when to use an ellipsis became an easy decision for designers.
Other improvements:
Given that it's all our first time to build a design system, there are still challenges that exist up to this day:
Viana is a growing ecosystem of products, and there will be more challenges than solutions. A good start is a good start, nevertheless, and there is only one way to go but up.
