BITAcore 2.0
Redesigning a financial index management platform for institutional clients, shaped by a continuous cycle of client demos rather than one big launch.
BITAcore is a platform for creating and managing financial indices, products used to build investment strategies for institutional clients.
During this period, three major clients came on board: SIX Group, BNP Paribas, and Market Vectors. The redesign and that growth weren't simply cause and effect. New modules were built to meet what these clients specifically needed, and as they used the platform, their feedback confirmed problems we already suspected and surfaced others we hadn't seen. We showed them progress roughly every three weeks. That recurring rhythm, more than any single redesign moment, is what actually shaped the product over the following seven months. One new module alone was tied to a contract worth 500,000 euros with one of these clients, and missing that would have meant cutting part of the team within a year or two.
I worked alongside a Product Manager and a development team of seven, three on backend and four on frontend, reporting into BITA's leadership. As the only designer, I owned every part of the process, from the initial audit to the detailed interaction work on each module, while final direction was usually decided jointly with the PM and leadership.
Timelines on this project could shift overnight. Two modules that were originally scoped for two to three weeks of work ended up compressed to a single week, and in one case to three days, after a client demo was scheduled with little notice. It meant designing in a way that could adapt quickly without losing quality.
The product also had very little design infrastructure to build on. There was no real design system in place, just a handful of components in a library that needed real attention, and several existing patterns had grown without much logic behind them over time. Color was the clearest example of how technical and political pressure could collide. Brand values were tightly held at a leadership level, with limited room to adjust them, even where accessibility data pointed to a change, and even after two of the new large clients raised it directly. Management held the line on the palette regardless. I worked around it first by adjusting spacing and reusing background tones that already existed in the system, which solved part of the legibility issue without touching the core colors. With those same clients still weighing whether to stay, that opened the door to a smaller color correction afterward, which the frontend team and I made ourselves rather than reopening the original argument. The accessibility issue resolved, the clients stayed, and nobody above us ever had to relitigate a decision they'd already made.
Being the only designer on a fast-moving product also meant managing demand carefully. As work picked up, requests from other parts of the business started competing for the same time as the core platform work, and leadership eventually helped set clearer boundaries so the platform stayed the priority. On the product side itself, there was always another module ready to move into, so the work kept a steady pace even when one piece needed more time to land.
Index Inception: tabs over infinite scroll.
The original brief called for an infinite scroll layout for this module, where users would fill in each section as they scrolled down continuously. I pushed back, worried the amount of information would feel overwhelming in one long flow. A conversation with a colleague gave me the structure I needed. He described the Inception tasks as distinct blocks of work, and that framing led me to split the module into three tabs grouped by what users were actually doing: loading and reviewing metadata, adjusting parameters and versions, and configuring rules, currency, and dissemination options.
The team and leadership were evenly split on which approach was better, so since we had time, we ran an A/B test instead of deciding by opinion. Tabs won clearly. In the original infinite scroll version, people stopped completing tasks the further they had to scroll.
Filtering Methodology: fixing the summary panel properly.
This module's summary panel had a legibility problem since its first version, but it was never prioritized, since the number of filters and stats in play was small enough that it didn't feel urgent. When the module came up for a full modernization, I had a choice. I could patch the panel conservatively and stay close to the original look, or rebuild it properly. I chose the rebuild. It also meant prioritizing this module over Index Builder, which was originally scheduled to ship at the same time, since Index Builder needed fewer changes and wasn't as urgent.
The new version added contrast for legibility, icons so users could see at a glance which filters were active and how many, collapsible detail sections, the ability to remove filters straight from the list, and a panel that could collapse entirely to free up space. The legibility issue was real, and it was only going to get worse as filter complexity grew.
A logic for buttons that never had one.
Before this, button color in the product was basically arbitrary, white or blue, placed case by case with no real rule behind it. I set a simple system: white for negative or destructive actions, blue for positive or confirming ones, and blue buttons placed consistently on the right, so blue also meant the way forward.
There's no hard number behind this one, but the shift was clear to see. People stopped pausing to check which button did what. In financial software, where actions like deleting an index or confirming a rebalance carry real weight, that kind of predictability matters.
Keeping a pop-up pattern that wasn't perfect.
In a few flows, selecting specific items within a module relied on pop-ups, which added extra clicks and didn't feel as visually unified as the rest of the system. I could have pushed for a cleaner pattern, but the added friction didn't show up in how clients actually used the product, and there was no real evidence it was costing anything. Spending design and political capital fixing something that wasn't actually a problem didn't seem worth it, so I left it as it was and put that energy into modules that needed it more.
Bringing the frontend lead into PM conversations.
For most of the project, frontend only heard about design decisions after they'd already been made in meetings with the PM. I changed that and brought the frontend lead into those conversations directly, so changes were visible as they happened instead of landing after the fact. It paid off later when the color situation came up. Frontend already understood the constraints and the reasoning behind earlier decisions well enough to help work out the spacing and palette fix without needing a separate round of explanation first.
Beyond the numbers, two things changed that weren't the direct goal of the project. The color fix kept two large clients who had been weighing whether to stay, and putting an actual design system in place for the first time noticeably reduced how much frontend had to redo or guess at on their own. I also spent a fair amount of time working closely with a newer, fairly junior PM, who picked up a lot of how product and design work together just from being in the room for it.
For a while, the whole team, myself included, was fairly fixated on reducing clicks wherever we could, the pop-up pattern being one example I almost rebuilt for that reason alone. What I learned working on a product like this is that the click-reduction instinct comes from a different kind of software entirely. BITAcore is built for complex operations that already take users tens of minutes to work through, sometimes with a colleague sitting next to them while they plan a strategy out loud. Half a second saved on a click doesn't register in that context the way it would in a quick consumer app. The textbook answer is still correct in theory, but I check it against a simpler question now: does the benefit of a change actually match what it costs to build. If it doesn't, the textbook answer isn't worth chasing.
Interested in working together?
I'm currently open to new opportunities in fintech and data-driven product design.
