The following article is a walk through of my internal process to solve a workflow problem through interface design.
Below, I go through how I designed a simple stock-tracking app, to help me keep track of the trades I made as I learned about stock trading.
As a hobby, I wanted to learn more about trading, and more specifically day trading.
Since I am, at core, a doer, I figured I would learn by doing like I always have, and start trading right away. So I did.
(What could possibly go wrong?)
Quickly, a simple problem arose: how do I keep track of all the different stock I bought, at what price I bought it, and how much profit would I make from the sale of that stock considering the broker fees in place?
Obviously, the trading platform I used provided an interface where it logged every trade. But there was too much unnecessary information, fees were conveniently hidden, and I could not easily view which trades were profitable and which were losses, as they were all represented as independent trades.
In essence, what I really needed was to: keep track of the gains I was making, the losses I would suffer from, and (another key variable to figure out) the broker fees associated with each trade.
And ultimately, I needed to visualize all of that data, in the most simple and intuitive way to be able to make sense with just a glance of where I stood financially, at any point in time, and to keep track of my overall progress.
Basically answering the following question: was I making money or losing money?
Initially, I started jotting down this information as plain text on my notes app. But I quickly grew tired of that: input was slow and cumbersome, data was not organized and it took too much mental effort to quickly see what was going on (am I rich yet?).
I needed a faster, better, more structured way to visualize all of this. So I started thinking...
To design a prototype —and keep it as focused and uncluttered as possible— I first needed to decide which pieces of data were most important, weighing each one along the way to determine the order in which I would present them.
By logging my trades in my notes, I had already partially answered the question. The most essential data points included:
- the ticker,
- the price at time of purchase,
- the quantity of stocks I bought,
- the price I sold the stock at.
This being a digital input, I could now take advantage of the computer's skills at math, as well as automatically log things such as time and date. Here are the remaining data points I added:
- the date it was bought on,
- the date it was sold on,
- the computed fees for the trade,
- and finally the revenue and (most important) profit I had made from the trade.
For ease of use, I later added these:
- a minimum price to sell at (automatically computed to take account of the various fees),
- a suggested price to sell at (again computed with fees in mind, but this time with a healthy margin so I could have a rough idea of what goals to reach),
Laying Things Out
Now that I had settled on the right data, I had to present it in the right way.
Even though tables are usually frowned upon in html, a simple table was, in this particular case, the perfect tool for the job: ordering all the information in their separate columns would allow me to keep a clean, organized view of my data and quickly find my way to what I was looking for, as well as enable me to compare trades, and keep track of the chronology of the trades.
I determined that trades were either open (yet to be sold) or closed (sold), and color coded them to distinguish trade "states" from one another: a bright yellow would represent open trades (and implicitly signify: quick close them!), while closed sales were again divided into two sub categories: profitable trades (enjoyable light green) and trades at a loss (a damning red).
Already, visualizing the state of my portfolio was a breeze.
Another big gain was made with the easy change to add a high contrast, blue background to every ticker: the first information the eye needs to capture in each row.
Perhaps one of the most important design decisions was to pick a mono-space font for the table, ensuring that all numbers and dates would be neatly aligned, and adding a big gain in overall readability. Here, I used the “Consolas” typeface (notice the added nicety of slashed zeros).
And even though for an app of this nature functionality is paramount, I believe that a tool that is enjoyable to use and aesthetically pleasant, is by definition a better tool, as increasing likeability in turn increases usage (and what are tools made for if not to be used?)
In that regard, the monospace font adds a nice bit of personality here, putting the user in a "genius trader crunching data" mood.
Another subtle change, making prices bold, helped quickly identify key data, further adding to readability.
As days passed and trades increased however, the whole experience became a little cluttered and overwhelming: all trades ever placed were mixed up together and though they were ordered by date, I was wasting energy having to figure out which ones were relevant.
To solve this problem and make the table more digestible, I separated trades by day, which had the added benefit of allowing me to display a particular day's profits and losses.
At this point, all my data is laid out and looking good. But it is still dummy data. I need to input real data in here!
Designing the Buy
Markets move fast. And trading can be stressful —a little less with paper money but still. So I wanted the input to be as mindless as possible, with no mistakes possible, by design.
I designed the input to require only 3 things: the ticker, the price at which the stock was bought, and the quantity (which I defaulted to 100, my average buy, to make things even faster).
Nice little detail: I coded all of the inputs in HTML as the new HTML5 [type=number], enabling cool default browser features like up/down arrows (see below), minimum/maximum values, native panes on mobile, etc...
The buying feature was now done, and at this point, the mock app was almost complete:
There was still one important thing missing though: the ability to mark a trade as “sold”.
Designing the Sell
Before anything, you should know that there is an important design consideration I glanced over until now: to simplify the underlying stock database model, overall data presentation, and the selling process to the maximum, I made the conscious assumption from the start that I would always be selling as much stock as I had initially bought.
This translates into two things, design-wise:
- One: that I could group two trades (buying and selling) into one row, and thus be able to set a single status on each row (open, sold for profit, sold at loss);
- Two: that I could move the input of the sale price directly inside the row representing the buy. All I had to do was replace the static value of the “Sold” column with an input, of either an empty value or a value set by the user.
And with a little design trickery, I even managed to make the input appear and behave like a spreadsheet: the input is made invisible, showing only a modifiable value.
Basically, this allowed me to keep the same exact design as static data, with the huge advantage of the data being fully interactive now!
At this point the app was completely usable and truly felt alive!
* One completely useless detail —functionality wise at least— I added at the end was an image of a Super Mario coin, before all profit values.
This subtle detail made the app slightly more approachable and fun, and kind of gamified the process of making money in my mind (increased usage, again!).
* At the very top, I added a ticking date and time, updated every second: this made the whole app feel more live and up-to-date!
* Last but not least: I aligned all the data to the right, so that numbers would neatly fall under each other.
Going from here, nice-to-haves could include:
- A ticker that would autocomplete (in the buy input). This could be easily added with a call to a public stocks API on input.
- Autocompleting the ticker price with live data: this would eliminate the need for the price input.
- Eliminating input all together: hooking up the interface to the broker's API would allow for trades to automatically be added and updated whenever they were sold. This is the ultimate feature.
I wanted the app to be reactive, fast, and quick to code: I had a problem, a solution in my mind, and I wanted my tool already!
Meteor works in pair with the NoSQL database MongoDB: this is where the app's data was saved.
In the end here's what the app looked like: