Ampero, a Portfolio Management Tool: forecasting section

Services	Platform	Industry	Date
Product Design	Tablet & Web	Fintech	2023 - 2024

In this post, I will share my experience from my previous job as a UX/UI Designer, and then Product Designer. Our design team consisted of three members, each responsible for one of the tool's main sections: Financial Data, Technical Data, and Forecasting—the latter being my assigned area.

How I Want to Tell It

I’ll explain everything in a simplified way to highlight only my role as a designer. Given the current context and timing, I believe it's important to focus on what I’m most eager to showcase. While I contributed in many ways at Ampero—product design, leading, collaborating, testing—my primary goal here is to give an overview of my core line of work.

The First Challenge

The first challenge came when I was introduced to my product manager, who also happened to be the engineering lead for the AI team. This kind of crossover is common in startups where people wear multiple hats and flexibility is key. But what truly matters? Conquering the world? No, no, no. The goal is to quickly deliver a working MVP (Minimum Viable Product) to get the product into the market, or at least to create a functioning prototype that could attract further investment.

The Streamlit project was a single-page layout consisting of an input section, a tuning panel, and an output section displaying the forecasting results.

Output section with the outcome and the forecasting results. Very ugly UI, BTW.

Fine-Tuning

The initial steps involved getting familiar with the information—what we wanted to showcase in the forecasting tool, how we wanted to present it, and how users would interact with it. Then I got to know our users. There weren’t many, as this kind of energy production tool isn’t for the general public. Our target user was someone who manages many assets or groups of assets. We weren’t aiming for users with six solar panels on their roof; we were aiming much higher.

Feedback from our users was immediate. The forecasting product already existed when I joined. My team lead, who was also the product manager and engineer, had created a page in Streamlit using Python. The page had little UX logic, but once you learned how to use it, it made sense. Despite some shortcomings, the product worked.

This made my job somewhat easier, but why? Since the product already functioned, I didn’t have to come up with new use cases. Instead, I could focus on edge cases and concentrate fully on improving the user experience. The usual friction with engineering, particularly with backend limitations (backend engineers, I love you, but sometimes I ask for "The Lord of the Rings" and you give me "Dora the Explorer"), wasn’t an issue at this stage since the backend was already well-established.

The downside? The user flow had already been defined, so I could only tweak it in terms of reducing the number of steps the user had to take. This allowed me to focus on UI design, something that isn’t always possible. The prototype used real user cases, and the input fields were constantly tested against edge cases (imagine the long words in the German language... what a way to challenge input fields!).

New Design for a simulated forecast

The forecasting tool/section I was working on was called 'Scenario Modelling.' The main objective was to allow the user to forecast assets by setting and adjusting market changes. Another use was to find buying or selling opportunities by seeking a desired balance and understanding future trends by modifying factors such as international electricity prices, changes in interest rates set by banks, inflation, and more.

We created a first page with a control panel to allow the user to have an overview of their portfolio assets. And also added and a section with possible future assets acquisitions called External assets (this could also be a marketplace of assets.)

Once the user has selected the desired assets for the simulation, they can optimize or choose the best options to adjust the scenario. This enables the user to make more informed decisions regarding asset allocation, risk management, and portfolio diversification.

Data visualization: Output results

If the user wanted to see how the algorithm performed, there was an option to view probabilities in the forecasting, which could be crucial when setting prices and evaluating the economic outlook.

Some conclusions from my experience in Ampero and the methologies of work:

The Bad:

• Color Scheme: It’s hard to break away from the established color conventions in financial dashboards (red = bad, green = good). Additionally, there aren’t many color combinations that complement this classic duo.
• Component Alignment: Agreeing on more meta-level components like the sidebar, top bar, login, settings, tone, for example, was a challenge.

The Good:

• Niche Client Base: We had direct access to a small, specific group of users, which meant we could get immediate feedback in person and even conduct workshops.
• We communicated daily with the other two designers.
• We developed a design system that we all maintained, ensuring consistency across the product.
• Just like my team lead, I wore many hats too. I could create my own tickets or those for my teammates, and I was responsible for testing. This made me part of the entire product cycle, which allowed for much faster iterations.
• The engineering team was easy to contact. We had regular calls, and they were open to embracing my changes. In fact, in the early stages, we held a one-hour call where we made frontend changes together, pushing forward a new UI in real-time.

Results:

Upcoming Topics

Future articles will cover subjects like creating and maintaining a design system, designing login pages, panels, and data visualizations for a large volume of metrics, and implementing an upload feature that integrates AI as a key UI component.

I hope you enjoyed this post. See you soon.