BOSS Money

BOSS Money already did a lot, and more features were coming. The website had to explain the service clearly; the app had to make sending money feel safe and straightforward. Redesigning a few screens would have made a nice portfolio image, then left the team with the same old problems.

We needed to improve the journeys that affected conversion, calm down the interface, make it more accessible, and build reusable parts for whatever came next.

We wanted more people to complete important journeys, but not by shouting louder, hiding details, or turning every screen into a promotion.

We used clearer hierarchy, fewer competing actions, accessible controls, and better timing for important information.

The website introduced BOSS Money, answered the obvious trust questions, and helped people understand why they should use it. The app handled balances, recipients, rates, fees, transfers, and all the nervous moments that come with moving real money.

We used the same type, color, controls, accessibility rules, and brand behavior across both. We did not copy layouts blindly. The website had room to explain and persuade. The app stayed focused on getting the money where it needed to go.

Money transfer already comes with plenty of complexity: country rules, payout methods, identity checks, limits, reviews, and support states. Inconsistent UI adds a completely avoidable layer on top.

Similar actions looked and behaved differently depending on where they appeared. We kept solving familiar problems again, and customers had to relearn patterns inside the same app.

We organized the work from small pieces to full journeys: foundations, controls, components, patterns, templates, and screens.

A button did not become reusable just because we put it in a library. It needed clear states, accessible behavior, sensible content rules, and enough flexibility for real product work. We built larger patterns from those same parts, so screens felt related without becoming copies of each other.

The team included two UI designers, two UX designers, and one designer covering graphic and motion. That gave us a good mix of skills, as long as the work joined up.

UX designers shaped the flows and product logic. UI designers worked on hierarchy, interaction, and reusable patterns. Graphic and motion design gave the app a recognizable voice and made movement feel deliberate. The design system connected their work, and we reviewed the product together instead of throwing files over the wall.

Everyone owned their part, but nobody vanished into a specialty and came back with something that looked unrelated to the rest of the app.

We worked on the product and the system together. Real flows exposed weak components. Fixing those components made the next flow faster to design and build.

We used the send-money journey as a serious test. Amounts, rates, recipient details, payout choices, validation, reviews, and tracking all had to remain clear across many states. If the system could handle that without becoming a mess, it could handle most of the app.

Customers got clearer hierarchy, more consistent controls, and fewer moments where the interface competed with itself. The important money-transfer journeys became easier to scan and easier to complete.

The team also got reusable foundations, components, patterns, and templates. New work started from something solid instead of another blank frame.

We used Amplitude to run A/B tests, compare versions, and see what happened in real journeys. The results told us what to keep, what to change, and which popular ideas were not actually helping.

The redesigned journeys improved conversion while the app stayed clean and accessible. We turned the good parts into patterns the team could keep using.

Product and engineering could use those patterns in the next flow, so new work started closer to the right answer. The app became more consistent for customers and less repetitive for the people building it.

A polished happy path is easy. The real test is a validation error, a transfer under review, a long translated label, or a feature the original component never expected.

Because we built the system in the product, it already knew about the messy parts. It was not a tidy library pretending the app was simpler than it really was.