Design System for Remitbae

A design system for a fintech startup

Remitbae had a ton of design debt and an overall lack of design direction when I was onboarded. This happened because all the existing parts were designed at different times by different designers having different context. There was no unifying design philosophy or principles to guide them. as a result components were not in sync with each other in terms of UI & UX.

Although what exactly is Remitbae? It's an all in one platform for money transfers, currency exchange and more but for b2b. A white label product focused for money exchanges initially based in Qatar.

Issues faced

The platform started to feel like pages of different systems put together in one. It was extremely difficult to design pages, features or products because of no underlying specified design principles, a lot of time was wasted in debating and implementing design decisions. User experience also suffered because of lack of predictability and consistency.

Design and business goal

• Drive consistency in platform which would result in better user experience.
• The lower the cognitive load, the faster the execution time which results in more customers being handled which is good for business.

One major design constraint I had to take into account was reducing learnability. Exchange staff is accustomed to relatively older UI and patterns. If there was to be major reinvention in design and everything was changed from ground up would mean making them learn again. They'll need to relearn how to use the platform, and this might result in loss of business transactions and users. So it was important for us to have a fair balance between the market standard and the new design language so that the user's predictability doesn't go for a toss.

What should we build first?

I was adamant on starting from scratch altogether. There has been only insignificant progress from engineering side. But the real question was how will I build the design system first without knowing how the interface will turn out? But also, how do we make the interface when we don't even have a defined design system.

Endless debates and opinions were tossed around the table on whether the UI element looks good or a too-nice-to-say-it-sucks so 'can-be-better'.

This led me to do a bit of research on how other orgs make & maintain design systems.

We're not designing pages, We're designing systems of components. - Stephen Hay

It became clear that moving directly to pages to develop a design system was not probably the best idea. The answer lied in building both of them parallely and making changes to them simultaneously.

Then we changed our approach a bit. We started using those atoms and molecules simultaneously to see if they worked well in real pages. For example, I experimented with different levels of H2, subheadings, segmentations and breadcrumbs to finalize page headers. It helped us validate whether those components worked or not. If components didn't work, we made changes at the atomic level again.

Molecules gave us some building blocks to work with, and we were then able to combine them together to form organisms. We could then finally see the interface beginning to take shape.

Templates consist mostly of groups of organisms stitched together to form pages. It's here where we start to see the design coming together and see the layout in action.