Design walkthrough.

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.

Workflow Problem

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?

Initial Solution

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...

Prototyping

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:

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:

For ease of use, I later added these:

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:

Before/after:

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!

This neat trick coupled with Javascript framework Meteor.js's reactive technology, allowed me to automatically update the status (and color) of a row, whenever the value of the “sold” input changed!

At this point the app was completely usable and truly felt alive!

Finishing touches

* 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!

I decided to keep the default Javascript format: I liked the precision of it.

* Last but not least: I aligned all the data to the right, so that numbers would neatly fall under each other.

Future features

Going from here, nice-to-haves could include:

Technology

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!

So I decided to build the app using Meteor.js, an awesome Javascript framework which is basically the fastest tool I've ever used for prototyping and which includes built in reactivity (makes my app a delight to use!)

Meteor works in pair with the NoSQL database MongoDB: this is where the app's data was saved.

Final result

In the end here's what the app looked like: