Holdings and pending activity
Portfolio, balance and active orders need a clear relationship. “My Squad” brings them together in one overview.
01 Product structure
Organising features
around user tasks.
TRADAR needed to connect sporting information with financial transactions. A player could be part of a user's portfolio, the subject of a purchase offer and involved in a live match at the same time.
We examined these relationships and worked on navigation and user journeys. The project documents connect structure to practical questions: where are my holdings, how do I find a player, and what happens to an open order?
Clarifying product rules and user journeys together
The requirements map contains fundamental questions: what affects a player's value, how often is it updated, and when is trading possible? These show that UX work extended into defining the product model itself.
A player profile needed different information and actions depending on context. Sporting information, personal holdings and available offers had to fit together. Structure and the design of these states were closely linked.
Players and trading options
The player view connects sporting context with offer status. Designs account for active offers, sold-out tokens and no available offer.
02 Registration & identity
Designing for interruptions
during onboarding.
Onboarding involved account creation, personal details and identity verification through an external service. The transitions needed as much attention as the forms themselves.
Video identification makes this particularly clear. We designed preparation, permissions and recovery from a failed start so users could understand what to do next.
Separating necessary steps from avoidable friction
In my analysis, I questioned why registration already asked how users had heard about TRADAR. I also commented on password requirements and introducing key features. Our advice therefore covered which information was needed at which stage.
The requirements map separated account creation, personal details and external verification. For later checks, I asked what users should see and whether they could do anything beyond waiting. The resulting TRADAR screens explain prerequisites, identify missing permissions and offer another attempt after a failed start.
01 · PrepareExplain prerequisites
Before the video call, show the documents and technical requirements needed.
02 · PermissionsOffer the next step
If camera or microphone access is missing, the design explains why it is needed and guides users to settings.
03 · Error stateEnable another attempt
If identification cannot start, the interface explains the failure and offers a retry.
TRADAR screens around external IDnow verification. The identification provider's own interface is not shown.
03 Players & transactions
From a player offer
to a clear purchase preview.
Token quantity, euro amount, fees and payment method needed to align clearly throughout the purchase flow.
The team analysis identified a specific contradiction: the interface displayed euro amounts but expected a number of player tokens as input. The meaning of the entry was therefore unclear before checkout.
The detailed purchase preview separates these values: token quantity, unit price, fee and total each have their own row. Users can review and change the payment method before confirming. Documents and a risk notice are also included.
We designed the steps from offer through input and preview to confirmation, including limits, error cases and open-order management. This makes the connection between clear input and an informed purchase decision visible in one flow.
Showing the offer in context
The player view connects the active offer with price, availability and personal holdings. Matches and biography add sporting context.
Upper excerpt of a longer player view.
Reviewing the decision before purchase
The preview combines quantity, unit price, fees and total. Payment method, documents and risk information remain accessible before confirmation.
Original design with sample prices and fees.
04 Design system & collaboration
Recurring patterns
for detailed design.
Players, token quantities, value, order status and actions recur throughout the app. We developed reusable components and presentation patterns for them.
The component overview distinguishes open orders, market orders and orders being processed. A live card connects a player with match status and rewards; offer patterns compare price, quantity and total. Shared components needed to reflect these different meanings and states.
Design was coordinated closely with product management and development. As Principal, I held project responsibility at userdoo and supported UX and product decisions. A designer on my team was the Design Lead; we developed the work together.
Defining the MVP design scope
The project board records three choices: dark mode first, light mode after the MVP, and system typography. This defined which design variants to develop initially and which could follow later.
Planning also covered components, interaction patterns and concise specifications. This shared foundation helped us develop the growing set of flows into a coherent product and discuss them with development.
Delivery included connected flows, detailed screens, components and specifications. Implementation discussions could therefore focus on concrete states and transitions.
The full scope extended beyond these examples to account management, security, notifications, transaction history, rewards and the store.
Project responsibilities
My contribution
Principal, project responsibility, UX advice and coordination with product management and development
Tommy Haacke and team
Joint development of flows, interfaces, components and states
Product management & development
Close domain and technical coordination
Outcome
Clarifying product questions and specifying implementation.
Product management and engineering received agreed user flows, screens and specifications. Open questions about purchases, identity verification and order status were resolved down to the interaction details. The design system provided recurring components and states for further development.
User journeys developed together
Key flows from registration and portfolio to purchases and order management.
Screens & states
Interfaces for standard flows, missing prerequisites and retries.
Components & specifications
Recurring patterns supporting detailed design and coordination with development.
