Context
My company provides technical service for the Financial & Bank industry in the US. So our products are distinct and have to follow the Pixel Perfect principle. When I first joined, there were 7 Vietnam designers and 1 VP of Product Innovation & Design in the US. We work directly with the US BA and our VP via mail. At that time, my company had built 5, 7 products, and 3 versions of the Design System (DS). In probation time, my KPI was:
Understanding and becoming familiar with DS
Understanding and becoming familiar with our working process
Handling current product well
In my opinion, our DS has a good structure with proper components and rules. In Vietnam, besides my company, there are only a few companies building DS like that.
Summary:
Our main design tool: Sketch
Platform: web app, portal
Management tool (team & DS): Abstract
Prototype: Invision
Document management and build DLS live: DSM of Invision
Because my company highly focuses on the pixel-perfect principle, all departments (BA, dev, QA…) have to follow DS. However, back then, DS was written and presented exclusively for the Design team, so I undertook the task to re-write DS documents in order to publish for other departments. I also became the Lead of the Design System. The duty is to manage the current DS and builds a new DS.
In current DS
Initially, DS was written in Jquery, then changed to React language. Therefore, the development team took much time to re-build, and at the same time developed other products. Moreover, due to those changes, some component's behaviors were changed too, I had to update those behaviors, but also transferred DS for the development team, and reviewed their output. We created a scrum team that runs sprints every week to check progress. It is necessary because DS had been using many products, if we had not worked closely, maybe the output did not match with the product team's requirements and design criteria.
Besides that, during design and development, our design team also had many new needs that I needed to update in DS.
Moreover, because of being the increase of products, and designers (about 30 designers). I also undertook to train for new-comers and supported DS knowledge for our team. So that we could make sure be consistent in products.
My lesson learn
After working and living with DS, some lessons are learned:
A new-comer finds it difficult to learn and use DS because of its complicated and big
Initially, we follow the atomic design, but we did not have much experience, the DS structure was divided into multi-level, so it is hard to find a component quickly
The definition of DS is too detailed, creating too many components, which are not much reused.
The consistency is very important, but somehow, it forces the designer in the framework and limits
The naming for components between the design and development team is a bit different
My results
Based on those lesson learned, at the next DS building, I improved many things:
Of course, initially, we need to define color, typography, icon, shadow, and some core components. Then working on with button, dropdown, input…
To decrease unnecessary effort, I worked closely with the development team to review and took references from their Kendo library.
There were 4 designers in charge of the project with me. Each member undertook a component, and sync, cross-check together at the end of the day. We also had a scrum team to run this project.
After one year working here, I learned much knowledge about DS, about the pros and cons of it to prepare for my new product in the future.
2020
