OPTIONLOGY • HANDED OFF
ROLE
Product Designer
TIMELINE
Mar 2024 - May 2024
TEAM
1 PM
2 Engineers
1 Designer (Me)
SKILLS
Product Design
User Research
Prototyping
TL;DR
Non-technical traders often struggle to build automated trading strategies without writing code. I designed Optionlogy’s no-code trading interface around a visual, block-based workflow, allowing users to connect market data, indicators, conditions, timers, and actions to create trading strategies. The goal was to make automated trading more approachable for people without programming experience. As an MVP project, validated impact metrics were not established.
Context
Optionlogy is a fintech startup that builds tools for options and algorithmic trading. It helps traders analyze the market, create trading strategies, and automate those strategies without having to code. I worked there as a Product Designer, where I designed a no-code strategy builder that made complex trading logic easier for non-technical users to understand and build.
Overview
When I joined Optionlogy, the goal was to build a no-code strategy builder for retail traders. I initially thought the challenge was making algorithmic trading easier to use.
After exploring existing products and talking to traders, I realized the bigger problem was that existing builders made it difficult to express the strategies traders already had in mind.
So instead of designing another visual rule builder, I focused on understanding how traders actually think about strategies.
Problem
I studied platforms such as Tradetron, Streak, StockMock, Option Alpha, Algotest, and Capitalise.ai. Each product struggled in different ways. Some had limitations with nested logic, some made trade management difficult, while others became harder to use as strategies grew.
Limited strategy flexibility
Existing tools struggled to support complex or nested trading logic.
Difficult trade management
Managing adjustments, protection, and multiple conditions became complicated.
Complexity grows quickly
Simple strategies were manageable, but interfaces became harder to use as strategies grew.
Poor mental model
Most tools were built around system logic rather than how traders naturally think about strategies.
Research
I stopped studying products and started studying strategies.
I analyzed 30 complex trading strategies to identify the patterns behind them. Despite differences in strategy and terminology, most followed a similar execution flow:
Entry → Adjustment → Exit
Each part answered two basic questions:
When should something happen?
What should happen?
This became the foundation for designing the builder around the trader's mental model rather than around technical building blocks.
Design
Instead of asking traders to think in code or technical rules, I organized the builder around four questions:
What are you trading?
When do you enter?
How do you manage the trade?
When do you exit?
Traders first defined the context of their strategy, including the asset, symbol, timeframe, capital, and broker. This information was configured once and reused throughout the builder.
TRADE SETUP
The Entry section brought together when a trade should open, what order should be placed, and how the position should be protected. The experience guided traders through these decisions without exposing every possible option at once.
TRADE ENTRY
Advanced features such as trailing stops, scaling, and time-based rules were kept optional. Simple strategies could stay simple while more complex strategies could grow when needed.
TRADE MANAGEMENT
The Exit section reused relevant protection rules from the entry setup while allowing traders to add additional exit conditions. This reduced duplicate configuration and kept the strategy easier to understand.
TRADE EXIT
As traders built their strategy, the product generated a plain-English summary of the rules. This gave them a simple way to check whether the strategy matched what they intended to create.
STRATEGY SUMMARY
Validation
We tested the interaction model before building it.
Together with the Product Manager, I created a high-fidelity prototype and tested the complete strategy-building workflow with five experienced options traders.
The participants understood the interaction model and felt it addressed limitations they had experienced with existing no-code platforms. The sessions helped validate the product direction before development.
Scope
We focused the MVP on the strategy builder.
The original vision included strategy building, backtesting, paper trading, and live deployment. We intentionally focused the MVP on the strategy builder so we could validate the core experience first.
Backtesting, deployment, AI-assisted strategy generation, and a visual strategy editor were planned for later iterations.
The strategy builder entered development and became the foundation for the backend architecture. I later left Optionlogy to move to the US for higher studies, and the company shut down before the MVP could be completed and launched.
Learnings
Start with the mental model, not the interface.
This project taught me that simplifying a complex product doesn't always mean removing complexity. It means organizing that complexity around how people already understand the problem.
By studying real trading strategies before designing the interface, I was able to build around the trader's mental model rather than asking traders to learn a new one.