Anton Osipov
PortfolioPilot
•
Consequences
Senior Product Designer
Resume
Email
PortfolioPilot
•
Consequences
Senior Product Designer
Resume
Email

Minor changes with major consequences 

A path of constant changes that changed a product and a company

When I joined the PortfolioPilot team, my initial objective was to build new features and improve existing ones.

I was the sole designer, guiding the platform and responsible for all design decisions.

Jump to screens

Don't want to read?

Jump to screens

Don't want to read?

Soon after joining, I saw I needed a second workstream to fix processes and address fundamental product issues:

  • Primary track: follows the backlog, high priority, quick results.

  • Secondary track: driven by my assessment of what needs improvement, done in spare cycles, longer-term outcomes.

What I tackled at the secondary track:

Turning chaos into a system →

Turning chaos into a system →

Designing design principles →

Designing design principles →

Shifting the team’s perspective →

Shifting the team’s perspective →

Moving from ship-and-see to test-and-learn →

Moving from ship-and-see to test-and-learn →

Raising the quality bar →

Raising the quality bar →

Turning chaos into a system

The first challenge was to structure mockups.

All mockups were in complete disarray. Some were grouped, and some weren't. Many features had several versions that needed to be sorted by which was the latest and whether it was implemented. Also, mockups were mixed with drafts.

Meanwhile, the product wasn't stabilized and changed (sometimes significantly) every week (typical for an early-stage startup).

I started by checking all mockups, comparing different versions, and reviewing the current implementation. I created a few projects:

  • Two projects for both major parts of the system

  • General project for all-system features

  • Sandboxes for personal experiments

  • Archive

The next step was to clean the mockup structure inside the files. Tile mockup organization created a lot of problems:

  • It's hard to read (every time you need to compare neighbor mockups to spot differences)

  • It tells nothing about user-flows

  • It's impossible to maintain (every change would trigger changes in multiple mockups)

I got rid of useless duplications and arranged mockups into flows. This allowed me to easily visualize even the most complicated logic.

The next step was to clean the production interface.

Designing design principles

After organizing all files and getting a bird’s-eye view of the product, it was time to define design principles. They have to be a bit controversial; otherwise they don’t simplify decision making.

Design principles:

Reuse over creation
Simplicity over transparency
Rapid iteration over planning

An example of how I applied them to update the registration flow:

  • Reuse over creation. I used existing components.
    Tradeoff: the result wasn’t as visually polished as I prefer.
    Outcome: easy to implement and ship.

  • Simplicity over transparency. I reduced verification friction.
    Tradeoff: the flow felt less predictable when some users were blocked until email verification.
    Outcome: many users bypassed verification and kept moving.

  • Rapid iteration over meticulous planning. I shipped early and iterated.
    Tradeoff: the optimal flow wasn’t in the first release.
    Outcome: fast learning and room to prove the idea.

Read more details about this case in the next chapter.

Shifting the team’s perspective

Sometimes what's obvious to a designer isn’t obvious to other stakeholders. The registration flow was one of those cases where I had to shift the team's view.

One of the first things I mentioned after trying PortfolioPilot for the first time was phone verification. It turned out that there were two reasons for having it:

  1. Filter out people outside North America.

  2. Protect the system from data scrapers.

Registration flow initial look

What I saw instead:

  1. Letting anyone in cost us nothing, but the filter created a strong barrier for real users.

  2. The scraping threat was theoretical and could be handled with simple monitoring. And our onboarding was complex enough to be a serious hurdle for automation anyway.

My explanation didn’t land, so I decided to move in the right direction step by step.

Step 1: Obvious win.

I added Google sign-in so some users could skip name and password.

Step 2: Alternate verification.

I offered a choice: phone or email verification. The goal was to test whether scraping was a real risk.

Step 3: Remove phone verification.

Data showed email was sufficient, so I eliminated phone verification.

Step 4: Verification via intermediaries.

I noticed that many users link their bank accounts during onboarding, which is a strong form of verification. So, I excluded them from additional verification.

To implement this, I moved verification after onboarding.

The solution was even more successful since people who reached verification have already committed time and effort and were more eager to continue.

As a result of simplifying the registration flow, the activation rate increased from 19% to 65%. While other changes in the registration flow were also implemented, the main improvement happened after verification rethinking at step 4.

Moving from ship-and-see to test-and-learn

After I started working at the company, I found out there was no testing culture in the company. Everything was just pushed into production. It’s not uncommon for startups and has logical reasons. That said, I still thought prototypes and tests are irreplaceable in the design process.

I had to persuade stakeholders to start using them. I made a few attempts, but it didn’t work, so I decided to change my approach and show rather than tell.

I waited for some time for the right task, and finally it appeared: parsing an investment portfolio using an LLM.

The functionality was completely new, so I created an interactive prototype in Figma and presented it to the founder. He was so inspired by the prototype that he not only agreed to the idea but also suggested testing it as a standalone functionality.

It took me seven iterations to find the right configuration of the modal that was clear to people.

I finally found the working configuration, but the main victory was the successful integration of prototypes and tests into our company workflow. A year later, our small team was constantly parallel running about 30 different A/B tests.

Raising the quality bar

Almost everything was misaligned at the start, with wrong gaps, too many styles, wrong accents, and a lack of visual hierarchy. Meanwhile, it wasn't possible to fix everything straight away because:

  • Too many small imperfections

  • Every week, some part(s) of the system changed (there is no point in fixing something that will be changed soon anyway)

  • The primary focus was on adding new or updating existing functionality

In other words, this cleaning was a long-lasting background process.

Every issue I created had a hidden purpose. I added an explanation to every problem we fixed. Meanwhile, understanding how not to do is one of the learning techniques. In other words, through explaining myself, I was also training engineers in design.

I created many cleaning tasks, but despite looking chaotic, all of them were carefully prioritized. I started with the most influential issues and moved to the least influential. Every issue was evaluated and sent to the backlog according to its importance.

Although I didn't like UI components, I knew it was too early for a proper redesign, so I made just a few minor changes to the UI kit.

When I started, the main screen of the system looked like this:

When I left, it transformed into this:

Results

As a result of my work, the platform evolved from “raw, unfinished, and experimental” to “professional and reliable,” in the words of its users. That shift allowed us to integrate payments and start generating revenue.

I delivered beyond design: I set up design processes, introduced the most useful practices, and helped shift the team’s perception of the product.

All PortfolioPilot cases

Mar 2022–Mar 2024

All PortfolioPilot cases

Mar 2022–Mar 2024