Problem Statement
Not every business has capabilities and skilled resources to create their data solutions through Bounche, and thus, still rely on Bounche team to create the solution. Furthermore, their focus is on to solve their problems efficiently, not finding the tool/platform to help them solve the problem. We learned and observed that traction to solve specific use case is higher than creating a universal platform for businesses to do it on their own. However, we found that companies might have different problems, even in the fraud landscape, their problems might be differ.
Atomic Design System
We adopts Brad Frost's concept of Atomic Design System, a methodology introduced by Brad Frost in 2016, is based on the idea that every design system can be defined as a series of building blocks that coexist.
Hence the name, Niels Bohr. a nod to the Denmark physicist, Niels bohr, who was one of the key pioneers of quantum mechanics--which contributed to atomic theory.
Source: Frost (2016). Atomic Design System
Design Process
Our design team has 3 phases of design creation : early work, mid-stage, and late-stage. In late-stage phase, we atomize the components and infuse it to design system. This way, we can know essential atoms, molecules, and the organism, and easily can discuss it further with front-end engineers and product team.
Step 1: Set-Up Foundation
Of course, to build everything, we need a foundations. Typography, colors, shadows, icons, sizings, etc. allows designers and front-end to have a baseline and basic reference that is scalable to any features.
​
The impact of this foundation is quite grand. Designers can design quickly with abundant foundations, while front-ends saved the tokens and re-use it.
Step 2: Specific Design Observation
At that time we have an ongoing project that became our base reference as our first trial to apply this Heisenberg; model performance.
We pay attention to its components and list down the "atomic" parts.
Step 3: Atomize It!
We have the list, so it's time to atomize the components. This is the trickiest part, because we have to align one another to make sure that the part could be configured by the engineers, and we have to set the guidelines.
Step 4: Documentation
​
After a thorough discussion and decisions, we "take notes" these rules and guidelines as one single source of truth that can be referred by engineers and product team.
​
The output is not an UI Kit (yet). But an extensive rules of how to configure, use, a particular component / use case. This way, we can avoid falling to the same pitfall: a constrained collaboration where engineers refers to UI Kit only and cannot process a new component quickly.
Niels Bohr For Designers
Sure, one single source of truth is enough for teams. But designers need something to quickens their pace in designing. Hence, Heisenberg for Designers: extensive UI Kits as a part of design system.
Reflection And Impact So Far
For Designers:
-
Extensive foundations allow designers to have abundant explorations in design
-
Fluid and configurable setup for design and code structure allow designers to detach-and-play, no more worrying about strict components
-
Separated UI Kit library and shared docs guides with Web. So we have expectations on what to refer, what not to refer: better communication.
For Engineers
-
Configurable components made the development more flexible, allowing to adjust the current components.
-
Minimum 3rd party dependencies and faster in debugging.
-
Code standards, sense of ownership and easier in communication.