It would be safe to say that the internet was still in its fledgling state at the turn of the century. Aside from best of breed corporate domains, such as Amazon with collaborative filtering (and their standardization of the check-out interaction model) and Google blowing open the very definition of data mining, much of the web was relatively “dumb” in the way that it could deliver user information to databases and back to the presentation layer.
It was a much simpler time for interfaces across the board—(hash)tags weren’t used to expose similar concepts within and across domains, sites were designed with one delivery platform in mind (rather than the responsive nature of today) and dynamic, lightweight web apps as we know them today were hardly imaginable, let alone standardized in development terms.
Asynchronous displays of input/output just weren’t commonplace in the browser, so the vast majority of interactions between users and system data predominantly relied upon straight form submissions and page refreshes. While most users didn’t necessarily feel the impact of such limitations, industry domains that handled timely purchases of goods with limited inventory or changing prices felt an intrinsic need for progress.
When I joined Datek Online (2002), I imagined that these boundaries were ripe to be pushed, and I had good reason to believe so, as Datek had already revolutionized the financial industry through the release of its Streamer app, which made public a set of streaming data tools that only industry day traders had access to previously.
Internally, all streaming visualizations were handled in Java, which by definition provided asynchronous communication between the client-side & the back-end and was sturdy in doing so. The trade-off with Java, though, was that it limited the possibilities when customizing the UI to a wider set of user needs and interactions, not to mention aesthetics.
Since the the function of the Datek website was highly focused on three priorities—the execution of a trade, management of account information and marketing communication—the division of tasks between account and information on two platforms wasn’t changing anytime soon. Datek was wildly successful and management didn’t seem much of a need to rock the boat to innovate, in terms of platforms, in the day trading realm. A such, my initial day-to-day focus was centered on incremental behavioral updates to all apps within the Streamer Suite.
Shifting Focus & Opportunities
Three months after I joined, Ameritrade purchased Datek and my days became much more interesting. We had just shipped a new Streamer app called Command Center—a dashboard app that presented multiple Streamer tasks in one interface and was a centerpiece of the product suite while the merger was being discussed—but now everything was on hold as the two management teams negotiated the redundancies of both backend systems and product features.
Ameritrade, the brand, was a destination for people who didn’t know much about investing, let alone trading. Innovation wasn’t the focus, and the only “edgy” aspect of their brand was Stewart, a marketing constructed hipster created to represent Ameritrade while schooling a technically-challenged, older, potential client base on how to trade:
After six months of maintaining the product suites, we (Dan Saffer, Tom Alison and myself with the blessing of Larry Szczech, Datek’s SVP Product Strategy) made a proactive push to Ameritrade management to design a new trading platform, one that could support the day traders of Datek, the long-term investors of Ameritrade and most importantly, the unsupported sweet spot between the two—active traders.
While day traders brought in large commission-per-client ratio, the number of active traders (10-20 trades per month) dwarfed them and made them a much more valuable market segment. Everyone in management agreed; we needed a new platform, catering first and foremost to actives, yet designed in an extensible manner to support the continued focus on day trading and long-term investment.
Over the next two years, we did just that. We ran numerous usability studies to understand the major pain points for both client-bases and ran qualitative interviews to develop personas and document needs and experiential expectations.
We even flew in Cooper Design to run a workshop for my team and developers, getting them up to speed on Goal-Directed Design, while inviting both product managers and business analysts to sit in so we could all approach supporting clients using our service using a similar methodology.
All About The Interface
As part of our overall interaction design philosophy, sections such as Deposits and Withdrawals were streamlined from multiple-page form submissions to a singular interface that exposed next options based on input decisions while setting the expectation for time-to-task. These conditional interfaces weren’t revolutionary by any means, but they weren’t industry standards either. Task completion improved as a result and user complaints reduced greatly—one of the overriding success metrics in the financial industry. These aren’t simply customers; these are clients.
Active traders need to move money, but they also need to open, close and change positions with an even greater attention to detail. Ancillary sections such as research were important, but the internet provided too many free opportunities for clients to research positions for us to focus on developing an industry leading research section. Instead, we felt that focusing our efforts on the context surrounding the trade ticket had the greatest ROI.
While we recognized that the holy grail of smartphones were a few years away from being a viable platform, we did recognize through research that traders needed to have as much flexibility as possible in the research ›› trade ›› confirmation process. We began to investigate the ways we could ensure that traders could always be one click away from moving on a position.
What we came up with was Snapticket; a nifty little trade ticket with features that supported both primary and edge cases of our active trader clients:
- The ticket in the footer area of the site, making it available at all times
- The user could get live quotes in the header, or pull up their watchlist
- The form applied the previously described dynamic error checks
- A conditional design was implemented to shift the fields depending on the type of trade chosen—market trades are without a price field; trailing stops have multiple price, closing inputs, etc.
- After submitting a trade, Snapticket collapsed to expose only the header w/ streaming quotes, allowing more room to engage above the fold
- Most importantly, Snapticket could *snap* off of the window, and live as a separate, compact trade window in the user’s display. This empowered users to research online wherever they chose, yet still have immediate access to opening/closing positions
After one enters a position, an optimal task flow should take the user to a confirmation and a view of all/open orders. Well, that’s what we knew as traders ourselves, but neither legacy experiences behaved as such. We needed to make sure that every potential detail of the trade ›› confirmation ›› review positions scenario was supported.
Following a trade submission, we designed the flow so that the user was brought to the open order section of the account, where a confirmation—including day trading requirements such as a ticket number—was presented in a highly visible manner. We used this interface real estate throughout the site to communicate both synchronous and an asynchronous system messages. Again, not earth shattering today, but not many web services worked the interface as such to keep the user as informed in 2004.
Overlooked by our competition, Open Orders are immensely important to traders across a number of important scenarios. A few that we tackled head on by making the interface the end-screen of the trading process were:
- The most basic, and probably most important for all traders, is providing a clean display of whether or not new positions have actually been submitted.
- When users trade after hours and on weekends they create a stack of open orders, that can’t officially enter the market until the next opening bell. Confirming their existence and providing a mechanism to make changes is important.
- During more concise time periods—say, after submitting a limit order at a specific price near market price—a user will have a small window to make changes (price up or dow, cancel, replace, etc.). The interface needed to present all interaction affordances clearly and reduce time-to-task as much as possible.
In terms of usability, we remained consistent with our treatment of forms by only making submit buttons accessible once all necessary field were altered, thereby greatly reducing errors and improving time-to-task.
Leading up to the release, we knew we weren’t just launching a new experience; Barron’s Online Broker Review was waiting for us at the end of the road, and with public knowledge of merger flirtations in the air with a prior rating of 2.5 stars (a bottom of the online brokers rank) the pressure was mounting.
In the spring of ’05, I flew out to Palo Alto with David Whitmore, Director Strategy, to present the new platform experience to Theresa Carrey, who literally had the power to make or break a business. A quote from her eventual report:
“[…] Ameritrade, which swallowed up Bidwell & Co., Brokerage America, JB Oxford & Co. and Investex over the last year, earns four stars this year for its Apex offering. Ameritrade seriously overhauled the Website this past year, finally integrating the technology brought in with the 2002 Datek acquisition. The new site provides improved navigation, more tools and services, easier-to-find information, customization and better trading technology. […]”
Ameritrade moved into the top three of online brokers and a few months down the line, TD and Ameritrade merged.