Eight months ago I did not know what IRR meant. I am not exaggerating. When I joined VALK in November 2019, my entire professional experience was consumer apps, security software interfaces, and e-commerce flows at Spacecode agency in Moscow. The most "financial" thing I had ever designed was a payment confirmation screen. And now I was Lead Product Designer at company building infrastructure for institutional private capital markets. Asset tokenization. Deal origination pipelines. Cap table management. Data rooms. I did not understand single word of this. The first weeks were uncomfortable I remember sitting in my apartment in Saint Petersburg, first week at VALK, reading the product brief and opening maybe fifteen browser tabs to understand what I was reading. IRR, internal rate of return. Cap table, capitalization table, document that shows equity ownership. Data room, secure virtual space for sensitive documents during due diligence. Deal origination, the process of sourcing investment deals. Every term connected to five more terms I did not know. At Spacecode I worked on Kaspersky Enterprise products. That was also technical, also B2B, but at least I understood what antivirus does. I understood the concept of threat, of protection, of alert. I could sit with users and have real conversation about their problems. With VALK, I was starting from zero. Complete zero. The CEO, I will not use his name here, but he is patient man, answered many questions from me in those early weeks. Some of these questions were probably embarrassing. "What exactly happens after investor signs term sheet?" "Why does asset manager need separate view from fund administrator?" "What is difference between debt and equity from user perspective?" Basic questions. The kind any financial professional would consider obvious. But he answered all of them. And this, I realize now, was important for the product. The disadvantage is real I want to be honest: not knowing the domain made my first months slower and more difficult. When I was designing dashboard for asset performance, I did not know which metrics are most important to fund manager. I did not know natural hierarchy of information in financial report. I had to learn this the same time I was trying to design it, which is not good situation. You cannot make confident decisions about information architecture when you are still learning what the information means. There were moments when I would present something to the team and they would tell me I had misunderstood completely what the screen needed to do. Not the visual design, the logic. The user flow. Because I had wrong mental model of the process. At Spacecode, even when I worked on new project, I usually had enough domain knowledge to start designing quickly. Banking app? I use banking app. Security dashboard? I understand security. The VALK work required different approach, a design process that was slower, more research-heavy, more dependent on conversations with people who actually understood what was happening. For company that needed to move fast, this was not ideal. But the disadvantage also works in reverse Here is the thing I did not expect. Enterprise financial software has very strong conventions. People who work in finance for many years have very specific expectations about how things should look, expectations that come from Bloomberg terminals, from Excel, from legacy software that has not changed its interface in fifteen years. The "standard" for financial data display is often terrible by modern UX standards. Dense tables, small type, no visual hierarchy, no clear primary actions. And the users defend this. They are comfortable with it. It is familiar. When I first saw the existing approach to asset overview screens, common in this space, my reaction was: this is too much information, user cannot see what is important, there is no clear entry point. But experienced financial software designer might look at same screen and think: yes, this is how financial dashboard looks. I did not have this conditioning. So I questioned everything. I kept asking "why does this need to be here?" and "what is user trying to decide when they look at this?" Sometimes the answer was: it is there because Bloomberg shows it like this. Which is not good reason for design decision. Sometimes I was wrong. The convention existed for real reason, financial users genuinely need high data density, they genuinely scan information differently from consumer app users, they genuinely need specific metrics visible at all times because their workflow depends on it. I learned which conventions I should respect. But sometimes the convention was just habit. Inherited from older software. And because I did not know I was supposed to follow it, I did not follow it. The asset overview problem Let me give specific example. One of the core screens in VALK platform is the asset overview, where investor or asset manager sees performance of specific investment. When I first designed this screen, I tried to understand: what decision does user make when they look at this? After many conversations, the answer was: they are checking if asset is performing as expected, and if not, where the problem is. This is monitoring task, not analysis task. They are not doing deep research here, they are checking status and deciding if they need to investigate further. So I designed the screen around that task. Clear status at top, is asset performing above, at, or below target? Then the key metrics that answer "why": current value, IRR versus target IRR, distribution history, recent activity. Not everything. Only the information relevant to that specific decision. This felt obvious to me as UX designer. Of course you design around the task. When we showed it to early users, several of them asked where the additional data was. They were used to screens that showed everything all the time, because the software they came from did not make hierarchy decisions for them. They were used to finding information themselves in dense table. We had conversation about this. What we found was interesting: users who had less experience with legacy financial software preferred our approach immediately. Users who came from traditional institutional background needed more time to trust that the data they needed was accessible, just not all visible at same time. Both groups eventually worked well with the design. But the resistance came from people whose expectations were shaped by old conventions. And I had designed something better, partly because I did not know about those conventions. Learning to read financial reports After few months, I realized I needed to actually understand finance better if I was going to keep designing for it. Not to become financial expert. But to have enough knowledge to make faster decisions and ask better questions. I started reading financial reports, actual reports, the kind that asset managers produce. Not reading them as expert, but reading them as designer: what information is here? How is it organized? What does reader need to find quickly? What is buried that should not be buried? This was actually very useful exercise. Financial reports have some good organizational logic in them, evolved over many years of users needing specific information. But they also have enormous amount of information that is legally required but not practically useful in daily workflow. Understanding which was which helped me design dashboards that pulled out the actionable information. I also started to understand the rhythm of financial work. Fund administrators check certain things at end of month. Asset managers have different focus during fundraising period versus asset management period. Investors have different questions at different stages of investment lifecycle. Design that does not understand these rhythms will feel wrong even if it looks right. This knowledge came slowly. I am still learning. But now, eight months in, I can have real conversations about product decisions without needing to translate everything first. What living here has to do with it I am writing this from my apartment in Alanya, Turkey. I moved here in August after spending several months in Russia. Alanya is small coastal city, not the kind of place most software workers would choose for remote work, but it has good internet, very low cost of living, and it is quiet. The cost of living part matters more than it sounds. When you are not stressed about money, you can afford to take time to learn things properly. I spent time in these eight months reading about finance, asking questions, going slowly on things I did not understand; because I was not in situation where I needed to rush past the difficulty to pay my bills. I think this gave me better foundation for the work than if I had forced myself to design fast from day one without understanding what I was designing. There is something to be said for having space to learn your domain. The question I keep asking One habit I developed from being outsider to finance is that I ask this question constantly: what is the actual decision the user is making right now? Not what information they have. Not what they are looking at. What decision are they making, and what do they need to make it well? This sounds simple but it cuts through a lot of complexity in enterprise product design. Financial software is full of screens that show information without being organized around decisions. The information is there, all of it, but the user has to do mental work to connect it to their task. When you know the domain deeply, you sometimes stop noticing this problem. You adapt. You learn to find what you need in the dense interface. When you do not know the domain, the friction stays visible longer, you cannot ignore it by adapting, because you do not know enough to adapt. So you have to fix it. I do not think domain ignorance is asset that stays valuable forever. At some point, not knowing things just means you make bad decisions and have to go back. The window of useful ignorance is probably the first year, long enough to design genuinely, short enough that you are still learning fast. I am trying to use this window well. Ask the questions that will sound stupid in a year. Design without knowing what I am "supposed" to design. And meanwhile, keep reading those financial reports.

Building 7 Apps at Once With ADHD Nearly Broke My Solo Founder Brain

castkit: CLI Demo Videos From One Command

Portfolio

Learning Finance by Designing It

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Accessible Data Visualization in Fintech: Why It Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

The Noonification: How the Liver Transplant System Changed Forever (11/25/2023)

Accessible Data Visualization in Fintech: Why It Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

The Noonification: How the Liver Transplant System Changed Forever (11/25/2023)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps