EMS Vertical Trading Ticket
The Problem
As a part of FactSet EMS, the ticket is how traders enter their trade and execution details. The original ticket was designed as a multi-row, horizontal form. This was based on pre-acquisition Portware tickets and general assumptions across the industry on how tickets should look. However, serval issues arose after we deployed our first iteration.
As we expand to more asset classes we have to add more rows of fields, adding complexity.
There is no information hierarchy, and users have complained when they have to adjust or update tickets.
I knew vertical forms are considered a better option based on third-party research.
Broker-supplied algorithmic trading layouts were confusing, adjusted the ticket, and we were relying on broker-defined layouts in their supplied XML files.
The basic ticket violates best practices for forms.
The ticket and broker algo details can make the ticket large and complex.
The breakdown
I brought up my concerns and some early ideas in our sprint retro meetings, but without real data I had a hard time convincing stakeholders and product team members. I worked with our UX researcher on the project to put the issue to our users. We reached out to 21 users and tested them over the course of a week with our released ticket and a Figma prototype.
Our findings supported moving to a vertical ticket when it comes to speed, errors, and satisfaction. However, we also received feedback regarding the layout of our algorithmic fields, the header in the ticket, and what fields are needed by the user in what cases.
Testing confirmed our assumptions & provided hard data. User satisfaction was exaggerated when they were shown the vertical ticket first in testing.
The Solution
I updated our ticket with a new breakout of the algorithmic section so only the first, and most common fields would be shown to the user initially. I also updated the header and broke out the ticket into several variants so the user doesn’t see inactive fields if they can’t edit them.
The data along with the new design was presented to our agile team and added to our backlog to be built out in the following sprint.
The vertical ticket grouped fields, simplified algo details, and improved the header.
The route ticket removed certain read only fields and updated the header.
The wave ticket for routing multiple securities removed particular fields, added wave-specific ones, and updated the header to focus on wave details.
The Results
We deployed the ticket to users and received good feedback from users and stakeholders. Furthermore, the header style became a standard we started to using elsewhere in the EMS product.
We did a follow up study with seven users and had positive feedback along with more usability tweaks which we addressed in future sprints. We are currently looking into allowing users to customize the ticket, but I think more research will be needed first.