Mancini Tan

1. Determine component, patterns guidelines, documentation, process

2. Be the decision maker if the team cannot come to an agreement

3. Spearhead momentum and rally buy-ins for Akira

Back in 2021, I first joined Ninja Van and realized that design and implementation is disconnected. What this means is that: what is handed off in design vs what is actually built is not the same.

Receiving buy-ins and support — Presented insights and showcased product migration results to wider organisation, including senior leadership. This was Team Akira's first step to showcase the need, and fronted the initiative to secure resources needed.

Team Akira aims to have a unified design system relevant to entire Ninja Van product range and to provide a single source of truth for both developers and designers wth acccessible guidelines, best practices and resources.

Before Akira — This was the set up before Akira came to be. Multiple legacy libraries floating around, and teams not communicating with each other which one is supposed to be used because lack of governance.

With Akira — This is the set up Akira enforces. Splitting into 2 versions: one for Mobile, one for Cursor. Decision making on which Design System to use becomes directly traceable, as it is always completely dependent on what framework the product will be, or is currently built on.

Building the foundation — Components needed to be built in code, and not just live in a design file. We worked closely with a developer to review implementation.

Product migration — A Design System is not a Design System if it isn't being used in products. To do this, we approached product migration one at a time, working closely with Designers within each verticals to either redesign and plan overhaul of existing products, or to build a completely brand new product together, using Akira.

Looking at challenges as opportunities — I’d be lying if I were to say that the process wasn’t a rollercoaster ride, to say the least. There was constant changes happening beyond my control (contributors resigning, business priorities shifting, timelines changing, pushback from teams, etc) but I find that when I started framing these the challenges as an opportunity, i learned two big things from this experience: 1) don’t be afraid to pushback on leadership to get what is needed for the team 2) It’s normal to be frustrated when there are many moving parts, but keep focused on actionables for progress.

Long term wins — When I first took up this initiative, nobody believed that I’d be able to do anything different than previous attempts. But that didn’t stop me from taking it on and driving it — It was nerve wrecking at first but I learned a lot from this experience, like the fact that anyone who wants to drive an initiative needs thick skin. I yapped about the design system to anyone who wants to listen, promoted it during demo-days, and booked 1-on-1s with the cofounder to get support. At the end, because I was so brazen, the initiative did get the development resource needed to start it off. And this experience taught me to not be afraid to go after the long term wins even if it means presenting an unpopular opinion and to not be afraid to influence change and convince that change to others.

Mancini Tan

1. Determine component, patterns guidelines, documentation, process

2. Be the decision maker if the team cannot come to an agreement

3. Spearhead momentum and rally buy-ins for Akira

Back in 2021, I first joined Ninja Van and realized that design and implementation is disconnected. What this means is that: what is handed off in design vs what is actually built is not the same.

Receiving buy-ins and support — Presented insights and showcased product migration results to wider organisation, including senior leadership. This was Team Akira's first step to showcase the need, and fronted the initiative to secure resources needed.

Team Akira aims to have a unified design system relevant to entire Ninja Van product range and to provide a single source of truth for both developers and designers wth acccessible guidelines, best practices and resources.

Before Akira — This was the set up before Akira came to be. Multiple legacy libraries floating around, and teams not communicating with each other which one is supposed to be used because lack of governance.

With Akira — This is the set up Akira enforces. Splitting into 2 versions: one for Mobile, one for Cursor. Decision making on which Design System to use becomes directly traceable, as it is always completely dependent on what framework the product will be, or is currently built on.

Building the foundation — Components needed to be built in code, and not just live in a design file. We worked closely with a developer to review implementation.

Product migration — A Design System is not a Design System if it isn't being used in products. To do this, we approached product migration one at a time, working closely with Designers within each verticals to either redesign and plan overhaul of existing products, or to build a completely brand new product together, using Akira.

Looking at challenges as opportunities — I’d be lying if I were to say that the process wasn’t a rollercoaster ride, to say the least. There was constant changes happening beyond my control (contributors resigning, business priorities shifting, timelines changing, pushback from teams, etc) but I find that when I started framing these the challenges as an opportunity, i learned two big things from this experience: 1) don’t be afraid to pushback on leadership to get what is needed for the team 2) It’s normal to be frustrated when there are many moving parts, but keep focused on actionables for progress.

Long term wins — When I first took up this initiative, nobody believed that I’d be able to do anything different than previous attempts. But that didn’t stop me from taking it on and driving it — It was nerve wrecking at first but I learned a lot from this experience, like the fact that anyone who wants to drive an initiative needs thick skin. I yapped about the design system to anyone who wants to listen, promoted it during demo-days, and booked 1-on-1s with the cofounder to get support. At the end, because I was so brazen, the initiative did get the development resource needed to start it off. And this experience taught me to not be afraid to go after the long term wins even if it means presenting an unpopular opinion and to not be afraid to influence change and convince that change to others.