BITAlens

BITAlens is BITA's portfolio analytics and reporting product, built on capabilities that already existed across the platform: Analyzer, portfolio upload workflows, benchmark handling, reporting infrastructure, and branding. The work was to package those existing strengths into a focused, client-ready experience, starting with SIX Group, rather than build something new from the ground up. SIX previously outsourced this kind of analysis to third parties, since they had no dedicated in-house tool for it. As a shareholder with a real stake in BITA, this product represents close to a fifth of what justifies their investment in the company.

I worked on this alongside a PM, four developers, and two executives. A first version shipped covering two of the three planned modules, with a third still in planning.

I knew the real timeline for this project was closer to two months, though the pace expected of the team often pointed to something shorter. Earlier projects at BITA had generally come with clearer timelines, which made this one feel less settled by comparison.

The interface direction was set before I got involved: reuse the existing, data-dense interface from one of BITA's other financial platforms, with SIX's palette applied, rather than build something more visual for what is, in concept, a more management-facing product. Since I had already built a full design system for that other platform, the visual side moved quickly once that direction was set, and most of the additional time went into building a distinct brand identity for BITAlens itself.

Working within SIX's own design system added another layer. Their guidelines existed but weren't fully developed, and I had no direct line to their team to ask what could flex and what couldn't. That meant making judgment calls on their behalf, within rules that were only partly written down. That ambiguity surfaced directly around color. A late push to apply red across the interface meant the PM and I had to walk back decisions we'd already settled on, and put together a wider set of options than originally planned just to get back to a direction we could agree on.

Most of the product direction on BITAlens was set before I got involved, since it builds on an existing system rather than starting from a blank page. The moments where I had real input mostly came down to defending what the interface should look like, more than choosing the direction myself.

The first was about color. There was pressure to apply red across buttons and cards, in a way that didn't quite match SIX's own guidelines or even the logic of the platform it was built on. Red also reads as an error state in most financial interfaces, and using it broadly risked making the whole platform feel like something was going wrong, which isn't the impression a portfolio management tool should give. I pushed for staying closer to SIX's actual design system instead, and what we landed on was a neutral color for cards, since the platform's usual blue action color wasn't approved for use here. It was a compromise rather than the direction I would have picked on my own, but it kept the interface closer to SIX's identity than the original ask would have, and avoided that error-state read.

The second is less a decision I made than one I disagreed with. Reusing the existing data-dense interface, rather than building something more visual, was decided above me. Looking at it now, I think it was the wrong call. BITAlens is meant to be a more visual, management-facing product, closer to portfolio-level decision making than to deep data analysis, and a dense analytical interface doesn't quite match that purpose. Given the chance, I would have pushed for richer charts, both in Analyzer and on the home view, rather than carrying over a layout built for a different kind of user.

There was also a disagreement over how the home screen itself was organized. I believed Analyzer should appear before Data Management Center, since BITAlens is fundamentally a visualization tool and that's what should lead. Leadership wanted it the other way around, and it shipped that way. Later, SIX changed the order to match what I'd originally argued for, not because they knew my position, just because they landed on the same logic independently.

When a separate conversation about action elements, cards, buttons, and tabs, hit a wall with executives, I recognized the same argument would land better coming from someone in development than from design. I had the frontend lead make the case directly, for shipping the module with a baseline level of consistency. I knew it was the right call, but having it delivered by someone in a different role gave it more weight than it would have carried coming from me.

BITAlens shipped its first MVP about a month and a half into the project, covering the Analyzer and Data Management Center modules. Early internal reception was positive, though I don't have a specific metric to point to yet since the product is still early in its rollout with SIX.

One thing that came out of this project is that the AI-assisted approach I used to move quickly proved hard for others on the team to match, both in speed and in cost.

What I'd track once it's further along: adoption among SIX's users, the volume of reports generated through BITAlens specifically, and how much it reduces SIX's reliance on third-party analysis, which was the original problem the product set out to solve.

This project changed how I think about my own speed. I've always worked fast, but AI tools were something I'd been genuinely wary of, and that came up more than once while working on BITAlens. Using them here, under real constraints, showed me it wasn't the leap I expected it to be. What other people on the team found difficult to keep up with came naturally to me once I actually tried it, and that shifted how I think about my own ability to adapt, not just to AI specifically, but to whatever comes next that I'm initially unsure about.