top of page
bh web image.png

Commodity Trading & Risk Management Platform

I led the design from idea through development of an enterprise-scale derivative trading and risk management platform for internal brokers and their B2B clients.

My Role

User Research


Information Architecture


Visual Design

Database Design


Blackhawk Resources


Blackhawk is a risk-management and brokerage firm that deals in the trade of metals, agriculture, and other commodities for B2B manufacturing purposes. In an effort to modernize industry standards that have been stagnant for decades, they wished to launch a combination CRM / trading tool that would help maintain their status as a leader in their field of expertise. 

Working directly with the client, I analyzed their entire workflow, identified pain points, mapped out an enhanced user-journey, and created information architecture & a responsive interface.

Business Goals

The platform was conceived to accomplish four primary goals:


Streamline workflow and optimize output to boost productivity within the firm.

Improve PNL by implementing a more accurate and automated set of tools.

Optimize customer experience on the client side in order to grow total trade volume.

Open up a new revenue stream for the firm by selling this software as a SaaS solution to other commodity brokers.







01 Stakeholder Interviews

I sat down with company leadership, as well as traders on the floor to learn about their motivations within the context of their jobs, current processes, pain points in their existing work flow, as well as the broad strokes and daily nuances in the dynamic of the business of commodity trading.

02 User Observation

I spent several days in the Blackhawk office as the traders conducted their day-to-day business to observe their processes and behaviors in order to identify pain points in the way they do business, and areas that can be improved within the scope of this new platform.

03 User Testing

At various stages in the design process, I would have traders complete tasks with prototypes of the UI while narrating their thought process around the way components were laid out, the logic of the various flows, and the clarity of the overall process. I then used this information to refine and iterate the designs until the user experience was perfected, and we were ready to begin the development phase of the project.


Though the goal of one party selling a commodity to another is theoretically simple, the existing user-flow was extremely convoluted and outdated.

Calls or emails broker, waits for response.

Calls or emails broker at fill date to execute trade

"I want to sell."

Manually fills out a contract form for internal records

Negotiates contract terms with participating parties through email or phone.

Manages contracts in a spreadsheet

Waits for trade confirmation

"I want to sell."


Checks commodity prices on a third-party exchange

Contract is created

Tracks shipment status in a spreadsheet




The product is designed to cut down on needless manual communication and administrative work. Additionally, the product replicates the various mathematical formulas and calculations used to determine risk, overage/underage, and other key indicators and metrics. 


Enters transaction parameters

Contract is created

Submits trade


"I want to sell."

"I want to sell."

Facilitates the entire process


Personas & Conceptual Diagrams

I created a 36 page PDF for use by developers and management on the client side that outlines all major concepts, personas, relationships, and other required knowledge for working with the product. The complete document can be viewed by clicking the image below.

User Groups and Corresponding Dashboards

There are six user types in the process, which are categorized into four dashboard experiences.

This user is Blackhawk; the broker and risk management professional in the process. Of the different user-types, the System Operator is the most robust, as this user has dominion over all processes and users in the system. This user can intervene on any interaction in the system, and is responsible for approving and executing hedge requests submitted by users on the client side. 

01 System Admin

This user is responsible for overseeing a network of Transactional users, who will create and submit contracts. This user also will utilize a user-management system.

02 Client Admin

03 Trader

Admin, Buyer, & Seller

The Trader is actually comprised of three different user-types; the Buyer, Vendor, and Local Admin. Together, at different points in the supply-chain, these users are responsible for creating and filling out contracts for shipments of metals.

This user is a special case. They actually have no functional privileges as far as buying, selling, inviting users, etc, but must feel like they have a certain level of control over the whole system. The dashboard is centered around visibility; the user cannot execute trades, but has executive visibility over the entire company's analytics, contracts, transactions, and user activity. Action buttons, such as 'Trade,' 'Add New,' etc. are removed.

04 Senior Management

User Capabilities

user functions.png

Database Design

Given that there are several sources of data that needed to communicate with each other via API in order for this product to function, I drew up a diagram explaining the relationships between different exchanges and entities for later use by developers. 

Group 4687.png

Design System

Group 8514.png
Group 8512.png
Group 8513.png
Group 8264.png
Group 8263.png


Group 7798.png

Trading Dashboard

Live Pricing Feed



Task Management

Recent Activity



Analytics & Reporting

Creating a Trade

Each asset type has its own specific parameters around units of measurement, terminology, and subgroups. For MVP, assets traded were limited to those on the COMEX exchange, but new assets were added later to expand the use case of the platform.


Additionally, each individual user dashboard types fulfill their own functions within the process. On-the-ground traders match up with one another to form deals. They then submit trade requests to the broker for approval. The broker's dashboard contains approval functions, as well as hedging functions specific to the way they manage their own funds.


Contracts & Transactions

A contract created between two parties to trade a commodity is comprised of multiple individual transactions. In order to link together, these transactions must meet matching parameters. This 'linking' logic is built into the UI.


Linking Transactions to Contracts

A drag-and-drop interface helps make the relationship between contracts and transactions helps enforce the modular nature of these trade types. Pictured is the tablet version of the product.


Auto-Trade & Surplus Management

Successful trading on the part of the broker results in a 'surplus' that can be traded and configured to maximize profits. Rather than manually managing this surplus, the platform uses a Limit Order system to make the most accurate calculated trades possible.

bottom of page