Designing Olea Before the Brand Existed
A three-portal trade finance platform designed from the ground up, with a system built to absorb a future brand.
OVERVIEW
When I joined Olea, the product roadmap was already moving, but the brand foundation was not. There was no logo, no palette, no visual direction, and no clear timeline for when those decisions would arrive. At the same time, the platform needed to support three role-based portals across investor, supplier, and internal operations experiences, with progress reviewed in two-week milestone cycles by senior stakeholders from both founding partners.
The safest option might have seemed to be waiting for the brand. I made the opposite call.
Waiting was not a neutral choice. The investor and supplier portals were Olea’s external face, and they needed the most detailed design, stakeholder review, and testing. Delaying them until the brand arrived would have pushed product risk downstream and compressed the time available for validation. Instead, I proposed a system-first approach: design a credible institutional default immediately, separate product structure from visual identity, and make the future brand a theme layer rather than a screen-by-screen redesign.
This required close alignment with engineering. The main concern was that a future brand shift could create heavy rework if colours were hard-coded across the product. Because Figma variables did not exist at the time, we created a shared thematic naming reference, effectively a manual token system, so design and engineering could map colours semantically rather than treating each screen as a one-off implementation.
Two months later, the brand arrived. Because the system had been built around business components, semantic styles, and themeable front-end mapping, we were able to adapt the customer-facing portals into full light and dark variants without structural redesign.
CHALLENGE
The problem Olea exists to solve is concrete and human. A supplier in an Asian manufacturing corridor waits weeks for financing approval and loses the working-capital window exactly when it matters most. Meanwhile, an institutional investor evaluating that same deal can’t tell at a glance whether it’s worth the risk. Standard Chartered and Linklogis co-founded Olea to close that gap: a fully digital, blockchain-enabled platform connecting institutional capital with supply-chain enterprises, serving Asia’s manufacturing corridors first, with expansion into the Middle East and Africa.
Olea’s product challenge was not simply that it had three portals. The deeper challenge was sequencing: deciding what could move before the brand existed, and what had to stay flexible enough to change later.
Three risks shaped the work.
- First, there was brand uncertainty. Without a logo, palette, or visual language, every interface decision had to be justified from the product’s function and the credibility expected of a fintech platform.
- Second, there was user-role complexity. Institutional investors needed dense, high-confidence data to evaluate opportunities and monitor risk. Suppliers needed guided, low-friction workflows that reduced ambiguity during financing and repayment. Internal operations teams needed secure tools to manage the connections between both sides.
- Third, there was an engineering risk. If the design system used fixed colours or screen-specific styling, the future brand could trigger rework across hundreds of screens. To make early design safe, the system had to be flexible not only in Figma but also in how engineering would implement it.
APPROACH
I treated the missing brand as a system architecture problem, not a visual design gap.
- Separate structure from identity.
- The first decision was to define what should remain stable regardless of brand: layout logic, component behaviour, information hierarchy, workflow states, and role-based interaction patterns. Visual identity would sit on top of that foundation as a themeable layer.
- This allowed the team to evaluate product structure before the formal brand identity arrived, while keeping the future brand transition technically manageable.
- To avoid turning the missing brand into a blocker, I explored several credible visual directions and aligned with stakeholders on an interim institutional look. The goal was not to define the brand early, but to create a shared product baseline that design and engineering could move forward with safely.
- Use thematic naming as a manual token system
- Because Figma variables were not available at the time, we created our own naming logic for themeable colour use. Instead of handing engineers fixed hex values scattered across screens, we maintained a shared reference document using thematic names for semantic use cases: background surfaces, primary actions, warning states, success states, borders, text hierarchy, and data-status treatments.
- This gave engineering a stable implementation contract. They did not have to infer colour logic from individual mockups, and we did not have to redesign every screen when the brand palette changed.
- Build business components, not just UI components
- I chose a business-component-based system over a conventional style-first design system. Olea’s components needed to carry trade finance logic, not just visual consistency. Dashboard modules, trade-card patterns, approval flows, status indicators, and data tables were designed as reusable product behaviours with visual styling layered on top.
- This made the system useful across portals while still allowing each user type to feel distinct.
- Scope the portals by risk
- I prioritized the Investor and Supplier portals because they were Olea’s external face and required the most careful design review. The Internal portal was more operationally complex and screen-heavy, so I scoped it against an established internal design system to avoid blocking customer-facing delivery.
- That decision kept the highest-visibility experiences moving while giving engineering a proven foundation where volume and complexity were highest.
Solution
The final solution was a three-portal platform supported by a theme-ready product system.
Rather than treating each portal as a separate design track, I structured the experience around shared business components that could adapt across investor, supplier, and internal workflows. These included trade cards, dashboard modules, approval states, data tables, status indicators, filtering patterns, and role-specific navigation structures.
The system separated product behaviour from visual expression. Core components carried workflow logic, while the visual layer remained flexible through semantic colour naming and shared design-to-engineering references.
This allowed the team to move forward with production-ready portal designs before the brand was finalized, while keeping the system ready to absorb the future visual identity through theming instead of structural redesign.
Impact
The clearest impact was not a classic before-and-after product metric, because this was a zero-to-one build. The impact was risk reduction.
Before the system was in place, the team faced a tradeoff: wait for the brand and delay external product validation, or move ahead and risk major rework later. After the system was in place, we could move ahead safely.
When the brand arrived two months into the project, the customer-facing portals were already in active development. Because visual identity lived in semantic styles, reusable components, and a shared theme mapping with engineering, the shift became a controlled re-theming effort rather than a structural redesign.
The project delivered:
- A full light and dark branded variant for the Investor and Supplier portals without structural rework.
- 600+ high-fidelity screens across three portals under two-week milestone cycles.
- Approximately 80% of UI built from reusable business components.
- A shared design-to-engineering language for themeable colour use before Figma variables existed.
- Production-ready external portal experiences that gave stakeholders a concrete product direction before the brand foundation was finalized.
Reflection
This project taught me that moving fast under ambiguity does not mean accepting fragile work. The key is deciding which parts of the system should be stable and which parts should remain replaceable.
If I ran the project again, I would pressure-test the design-to-engineering theme contract even earlier. I would select a small set of representative screens in week one, apply a hypothetical brand palette, and confirm that both the Figma system and front-end implementation could re-theme globally.
The strongest design decision in this project was not a screen. It was the system architecture that let the team keep moving before all inputs were available.
