Stock Scorecards

A case study in designing a complex web application

A tool for organizing and tracking your portfolio that would be integral in increasing retention for every Motley Fool service.

The Outcome: Motley Fool Scorecards
The BasicsCompany
The Motley Fool
1 Year
1 Product Manager
1 Product Designer & UX/Front-end Engineer (me)
2 Front-end Coders
4 Back-end Coders
Representatives from Product, Editorial and Investing.
Product Strategy
Product Design
Front-End Coding
Product Design: Illustrator, Photoshop, Visio
Front-End Coding: HTML, SCSS/CSS, Bourbon framework, AngularJS
Product Management: Agile, Google Docs, Trello, Slack

The Challenge

Every week The Motley Fool is recommending new stocks to buy or sell (or hold), but it was unclear how actively members were following the investing advice. The business wanted clarity if members were indeed purchasing the stocks that the company was recommending in its newsletter and online service, and which ones, and how soon after recommending.

The health of the investing advice business was directly connected to members taking action in a timely manner on the stocks recommendations, but the Fool did not have insight into if or how closely members portfolios match the advice provided.

Members had to track their stocks in their brokerages or on their own means through spreadsheets or other services. The Fool wanted to provide a tool so users could track their portfolios and in return could in aggregate (leveraging anonymous user data) validate that the advice being presented was being heard and acted on by the members.

My Contribution

I collaborated on the project strategy to understand the needs of the users and the business and designed the UX and the UI of this new application from the ground up.

I led the team of designers and front-end developers to deliver the production-ready code that is live today.

I also collaborated with the key stakeholders from Product, Investing, Tech and Marketing to socialize the value of the new tool and advocate for it to be as a featured tool integrated into every Motley Fool premium service.

The Approach

User Research: What Members Want

Motley Fool had a Watchlist tool that was not longer supported but not decommissioned. The UI was unusable but the data was salvageable to be folded into the new application. I came onto the team as the lead UX Designer and UI Engineer and started by reaching out to core users of the Watchlist tool to get a baseline of what features were key, which were lacking and which were table-stakes for not just watching but full-on tracking their portfolio performance going forward.

The user research uncovered that members would be more likely to go directly to their brokerages for tracking. That was going to be hard to compete with. However most Motley Fool users had accounts across multiple brokerages. It seemed inefficient on their part, but provided an opportunity. Brokerages only displayed what was in their brokerage. Would it be possible to display and calculate the performance of a user’s complete portfolio?

User Research: What Members Have

Many of the most experienced investors balked. They had their own offline tracking approach they would prefer to maintain but would use the new application if it provided customizing and could make it easier to manage the data.

There were limited resources for tracking investments, especially across multiple brokerages. Many members took on the onerous task of tracked by hand in their own spreadsheets.

One of the Motley Fool’s primary tenants is that the individual investor can beat the market. So while they may have a list of all their stocks and how they are performing individually, it’s a daily chore to get Excel to compare against a benchmark like the S&P 500. A competitive analysis report we complied illustrated that it was indeed surprisingly rare to find performance versus benchmark for individual positions. We petitioned that the stakeholders make this a tent-pole of the application.

User Experience Design: Standalone yet integrated

As the architecture of the application started to take shape it became clear that we had the opportunity to build a tool that could be all-encompassing.

The fundamental elements of the tool were to pull in stock performance data, calculate a member’s portfolio performance. However, the robust library of APIs available at the Fool meant pulling in latest news and trade alert recommendations was only a few lines of code away. With all of these elements integrated, it provided a powerful new destination that could be integrated as a sub-section to the Motley Fool website, it’s own product or a mobile application.

The stakeholders opted we set sail in the direction of a sub-section of the Motley Fool website. This actually expedited the production of the Scorecards tool. Inputs for adding a stock to the Scorecards system were integrated into the current Fool sites to plug into the outdated Watchlist tool. With a little light re-routing and UI label adjustments the stock tables, hover-state displaying stock details, articles and news suddenly were all able to input into the formerly Watchlist now Scorecards database.

Add to Scorecard columns were added to stock tables and Watch on Scorecards buttons were added to info pop-ups all across the Motley Fool’s premium services

The primary output mechanism beyond the site itself had to be email. I knew we had recently retired a daily stock news update and that there was an opening for a new daily recap that was focused just on the stocks a user was following. The back-end developers on the team believed they could build the necessary harvester that would take the user, query their stocks, query and new content related to those stocks and assemble it in a format suitable for email. I helped refactor an email interface, and suddenly we were able to provide the Scorecard experience in an Inbox.

The Motley Fool Scorecard daily email alerts if investing advice was published on any stock the member currently owns or is watching.

User Interface Design: A Flexible Application

The interface focused around customization. The members were provided the ability to import their Scorecards from a brokerage, a CSV or one at a time using the features re-routed across the sites.

The front page (after onboarding and importing) was a dashboard displaying overall performance vs benchmark prominently followed by a list of top movers for today and top news and advice related to those stocks. Also the dashboard linked to each of the users individual Scorecards.

User testing showed us that not only do members have multiple brokerages, but that they would like to reflect that in the Scorecards tool. On each Scorecard display, the user could see the stocks in that particular portfolio. We also could roll all the portfolios up into an All Scorecards view.

Being that we were trying to get buy-in and support for the new tool, there was hardly a feature-request we didn’t implement, like setting a table and card view, provide a robust list of data points to find the ones that matter most for this particular tab view of the stock scorecard, and offering unlimited tabs to create a myriad of views and columns and data points to match everyone’s possible version of how they view their data when investing.

Customizing the columns of the Overall view of All Scorecards collected together in the Scorecards tool.

The Unexpected

Unexpected Struggles

Not everything went according to plan.

  • The first major issue was that despite whether users were up for the convenience of broker-sync or found the security concerning, the tech required was just daunting. The ability to successfully sync up with the provider we had (that was in the midst of being bought-out) proved prohibitively challenged to do effectively and the effort had to be shelved.
  • Another unexpected complexity was that two audiences began to emerge and they didn’t like each other. There was a beginner user, new to investing, and interested in convenience and simplicity within the application, and then there was the advanced user, looking for building a bespoke and complexity view of their stocks and requiring lots of bells and whistles. These two were at odds and eventually led to reactively splitting the application between Simple and Advanced Views
  • Another limitation outside our control was getting back refined enough historical data to be able to automatically adjust for the nuances of investing such a dividends, splits, mergers, and the like. These features were table-stakes for the Advanced user and we were unable to provide them in a seamless way.
  • Finally, one of the longer-term challenges was that the original architects saw the way to future-proof this new application was to leverage the new Angular codebase: Angular 1. Unfortunately the upgrade from Angular 1 to Angular 2 was historically complicated and left the service pinned to a code version that quickly lost support both worldwide and internally. This led to less and less ability to maintain and grow the application.

Unexpected Successes

There were some great unintended wins

  • The front-end interface framework and component library leveraged for this project, Bourbon, became the primary design pattern library that was scaled and cultivated and maintained for years to follow.
  • Three of the interns brought on to work on this project were moved to full-time Fool developers and then into leadership positions at the company
  • The Scorecards application was highly engaging. The dashboard quickly became of the the top five pages for every premium service .
  • The new Scorecard email quickly achieved and maintains the distinction of the highest open rate for any Fool email.

The Results

The Motley Fool Scorecards application launched not as a standalone or as a mobile app, but as an integrated part of the premium service experience to about half a million members. The integration tools led to the addition of over 17,000 stocks into the Scorecard database, providing insight (in aggregate) into how frequently members are taking The Motley Fool’s investing advice.

Next Steps

Not everything can make it into the release. Here were items on the roadmap for improving and evolving the Scorecard application.

  1. Make the Broker Sync work. It wasn’t the right time, but the more users engaged manually with entering the data the clearer it has become this feature needs to be tried again.
  2. Automate dividend and split adjustments. Similarly, the amount of upkeep put on the user to maintain the dividend and split adjustments is overwhelming. This should be provided to make the system automated and convenient.
  3. Develop methodology to request new stocks in the system. If a member owns a stock not in the library of stocks, they are unable to add it. There is not a means to request new stocks.
  4. Add performance data to Scorecard emails. The Scorecard emails provide a detailed list of relevant articles for the stocks you watch, but doesn’t pull in closing price or a member’s total in the stock. That plus benchmark performance would help provide context as to the priority of reading updates on each stock.
  5. Provide Scorecard Analysis. At the end of the day, the Scorecard system still requires the member to make sense of the data provided. Providing analytics on what this means and how well the member is performing could lead them to understanding what to do next.
  6. Convert to a mobile app. The Scorecard tool is a web-based application and robustly complete and contained. It was never transferred to an App Store based app despite that it is so well suited to be a standalone application.


A few key learnings that I took away from this project

  • Having a feedback loop with the user is vital. The back-and-forth as the site is being designed and built out to understand what features matters, which do not, which are being executed in a usable way is essential.
  • Working fast with the latest hotness can make maintenance a nightmare. Two big framework risks were taken with this project. While the Bourbon framework lasted and became core code for years, the Angular code became an albatross for the tech department making even the smallest bug fixes a burden to complete.
  • Collaboration is key. Engaging early and often with the representatives of Product, Marketing, Investing and DevOps was required communication to get everyone on the same page to produce such a new and complex application.

Product Design and Development Lead at The Motley Fool writing mostly about design and front-end development. Thx for reading.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store