Putting it all together
- Typical flows
We are replacing a flash-based single-window app with html-based web app. It will feel more like a website, within a scrolling window but will remain functional like an app.
We are replacing a fluid window style interface with a fixed workspace, where elements have positions that are not configurable.
Rather than allowing elements to be positioned and scaled anywhere or anysize, items are laid out according to rigid grid structure. Text across the whole screen conforms to a consistent baseline.
We are replacing an interface that allows many layers to be arranged on top of each other with a workspace that has a single flat background and a single floating layer for functional elements.
Where lots of information is presented, especially in tables we will prioritise on the 20% of information 80% of people need, the rest will be hidden but available with a click.
Search and trade
In this simple flow, a user is 1 presented with the platform and uses the search box 2 to find a specific market where they open a ticket 3 directly from a price in the smart search results.
Next the user completes the ticket 4 resulting in a digital contract note confirmation and go to a chart on the market page 5 and after a period of time the trade is profitably closed 6 resulting in a confirmation contract note. 7
News and trade
In this simple flow, a user is 1 reading news headlines, and selects a story 2 which is linked to a number of 3 markets.
The user can open a ticket directly from the short list of markets 4 confirm and begin monitoring 5 without leaving the story or reconfiguring the platform.
Charts and trade
This charting flow outlines a user looking at a realtime chart 1 and opens a trade-on-chart ticket 2 which takes the current view and overlays stop/limit levels 3 alongside the regular ticket details.
This user can complete the trade 4 with the usual confirmation and is returned to the chart view with added trade indicators 5 on it.
In this mobile flow, a user has 1 already opened a position, most likely on a desktop platform. They may remotely monitor the open positions 2 or have an alert set to notify them of price positions 3 where the main mobile action is to close a position 4 resulting in a confirmation ticket 5
Basic trade flow principles
- Search box available at all times
- Smart search results to help find most relevant results and trade quickly
- Direct access to simple deal ticket
- Provide all the information on a market in one place
- Open a chart from a ticket or an open position
- Monitor and close, or be alerted if auto-closed from stops
It's fixed to the top of the page, in the header and visible all the time.
Scrolling down a longer page should keep the header locked to the top of the screen.
Before we have matched user input, we should use a large popover to provide inspiration to people looking for an opportunity. This might be calendar events, big movers, news or a user's previous searches.
We try to match user input as quickly and accurately as possible, so that means cross-referencing market names with alternate names, symbols, common mistakes and typos.
When we have a match we should swap out the broad inspiration with more specific details of events, news, pricing. Try to answer the user's need immediately.
Wherever there is a price there is an opportunity to trade. As in IFE, prices should be presented in pairs and be actionable into a deal ticket.
Deal tickets should do the hard work for the user.
Launch tickets from:
- Economic calendar
- Trade history
This means calculating meaningful values automatically: margin already used, remaining margin available and margin required, quantities to trade that fit this, actual profit/loss amounts that would the result of a stop of limit order and some indication of the real market value of the trade. Where meaningful, present values in the user's currency.
We are keen to test alternative tickets, especially possible designs that use the risk/margin as an active controller (rather than as a passive output).
For the simple ticket used by most people (80%) it should have clear access to the small number of options most used (20%).
Less widely used options should be made available on more specialised tickets or set as a user option for their account.
All the information
Where a link to a market is presented, either from news, search results or a watchlist there should be a single consistent destination.
This destination should pull together all the information previously in different windows: chart, price, ticket, news, trade history, pricing and contractual details.
Watchlists are collections of markets, either curated by us or a user. Their only function is to monitor and act on prices and should be presented as simply as possible. Data shows most users don't have many, and not many items on each. There are outliers, but we should concentrate on this core set.
Users should be able to add any market to a watchlist from a search, a product info page, a news story or other list of markets. Users should be able to create new watchlists, rename and delete existing ones, and remove items from them.
Monitor and close
We know most of our users act on market prices and close trades manually, rather than using orders, stops and limits.
As such, we provide monitoring at all times as an integral part of the layout. Position is consistent and it is only obscured when performing a search (ie. briefly).
While we would like to encourage more strategic behaviour in trading, this will remain a key user need and should be accomodated.
The price buttons sit on either the background layer or the floated layer. If they are on the background, they have a big diffuse shadow. When used on a floated layer the shadow is much smaller.
The effect of this should be a consistent layer above all the elements that price buttons appear.
They should equally be functional – clicking on a price pair should open a deal ticket, with the default direction relating to the button clicked. On a single static price, eg. an order, the ticket should open to ammend that order.
Within distinct units (eg. a Table or a Ticket) a consistent baseline must be applied rigourously to all elements, and ideally applied across the entire platform.
If in doubt, Open Sans regular. Bigger sizes use Light, smaller sizes can go to Semi-Bold and Bold is good for tiny labels on tables etc.
Keeping icons to a minimum, labels should do most of the heavy lifting to communicate what a link or button is.
some all of the icons used within the prototype to date:
On some of the panels and tickets we introduce a 45º striped texture. The roots of this are the printed deal tickets from 1918 and stock certificates we discovered in research.
This can be rendered in a number of colours depending on context - eg. the search popover is quite vibrant and colourful and has different coloured stripes for each of the main sections.
It works nicely shrunk right down, especially on retina mobile and desktop screens.
Using columns means we can turn many platform views directly into mobile views, as long scrolling pages. Other elements like the deal ticket should be worked on to fit on a single screen. A third type of element, the wide table, should work with collapsable table rows following our 80/20 use/info principle.
Collection of mobile format screens here: