Client
Time
Feb. 2019 - Aug. 2019 (7 months)
Tools
Figma / Principle / Web Frontend Development
Team
Emily Gong / June Liu / Yingli Sieh / Qian Wang / Nina Yang
Role
Designer / Researcher / Tech Lead
Contribution
Designed half of the prototypes after the team brainstormed together.
Built the deliverable website and lead the development of the project website.
Involved in almost all user research and testings.
00
Summary
Problem Framing
Design an alert system to draw traders onto Liquidnet.
Liquidnet is a FinTech company that provides a dark-pool trading platform to institutional traders and asset managers. Traders' digital and physical work space is extremely busy. Liquidnet wants to design an alert system to effectively push order updates and new trading opportunities to traders, so that traders will do more trades on Liquidnet. The goal of this project is to explore best practices for designing this alert system.
Solution Overview
Design guidelines and proof-of-concept prototypes to get traders' attention, convince them to take action, and increase stickiness.
After thorough research, we concluded a set of design guidelines for Liquidnet. We presented them on a website along with the supporting research and prototypes demonstrating the guideline. We generated 4 sets of guidelines/designs answering 3 questions: How to get traders' attention? How to convince them to take action on Liquidnet? How to engage them even when they are not trading?
01
Solution
Guideline Website
We built this website to show our research findings in analogous domains, the design guidelines we concluded, the prototypes we built based on the guidelines, and the relations among them.
Prototype | Set 1: Grab Attention
Click to Fold
Click to Unfold
1. Apply large area of salient color.
We tested the effects of different combinations of color, animation, and sound at a simulated trading desk, and discovered that salient colors can best attract attention.
Before applying color
After applying color
2. Provide multiple levels of urgency to avoid alert fatigue, and provide affordance of the alert type through colors.
Providing multiple levels of urgency can help avoid getting too much attention and causing alert fatigue or cognitive blindness. Color is also used to indicate the type of the alert, so that traders can know what is happening even before reading any text. This can improve efficiency.
3. A minimized view keeps Liquidnet visible, and brings users back to Liquidnet.
Considering currently many users don't allocate screen property to Liquidnet, we designed a minimized view to ensure users can notice and access Liquidnet alerts. In the long term, this minimized view can increase exposure, thus bringing users back to Liquidnet and winning more screen property.
Prototype | Set 2: Guide Action Through Information Architecture
Prototype | Set 2: Information Hierarchy
Click to Fold
Click to Unfold
1. Progressive disclosure with the right information hierarchy convinces users to take action.
Unlike the commonly used “call to action” design, traders don’t want to see the action immediately because their decision-making process needs lots of evidence. Neither do we want to overwhelm them. So we applied progressive disclosure to show what’s the alert when it comes in, more evidence when the user expanded it, and the full justification in the larger window.
2. Grouping reduces cognitive load and helps initiate action.
The frequency of the alerts can be high based on users blotter size. Groupped alerts can help users maintain a more manageable alert stream, and guide users to take action based on the groups.
Prototype | Set 3: Support individualizatione
Click to Fold
Click to Unfold
1. Provide in-context customization besides a centralized setting dashboard.
Previously, Liquidnet’s customization settings are in a separate dashboard, and users hardly use them. To bring the settings more accessible, we designed several in-context customization method. The data generated by these interactions can also be used to build more personalized trading recommendations.
right click on the alerts to customize
prompt customization settings based on user behavior
2. Set customized alerts and share with others.
Through user research, we learned that self-defined alert is needed. Some traders prefer to scroll and click when setting, while others prefer to type as if in a command line tool. So both methods are supported in our design. Many users also requested to share the alerts with colleagues, as shown on the right below.
set customized single alert
share customized alerts
Prototype | Set 4: Increase User Engagement Besides Alerts
Prototype | Set 4: Besides Alerts
Click to Fold
Click to Unfold
Increase user engagement through tackling untended user pain points.
Through user research, we identified several untended pain points in other workflows beside executing trades, like quickly accessing specific analytics and compiling a report to share. We built corresponding prototypes and validated them.
filter information using natural language
quickly compile a report with Liquidnet material
Validation
We gained our understanding of the problem space and target users through 30 interviews and shadowings. Combined with the abundant case studies we did in different domains, we generated our design ideas. Through 3 rounds, in total 22 testings, we refined and validated our design guidelines and prototypes.
40+
Case Studies
30
Interviews and shadowings
22
Testings
DESIGN
PROCESS
My Contribution

Designed half of the prototypes after the team brainstormed together.
Built the deliverable website and lead the development of the project website.
Involved in almost all user research and testings.

02
User Research

We first did some generative research to learn about the problem space and our target users. I was actively involved in all parts.

Background Research
A domain full of risk, pressure, and jargon.

To quickly get on board with this unfamiliar domain, we utilized a wide range of resources, including friends with relevant background, online videos introducing trading knowledge (Youtube, Investopedia, etc.), movies and documentaries about traders, even games simulating the trading experience. We quickly learned lots of jargon, which helped us to communicate with our interviewees later.

resources we looked into
products we examined
Predominantly outdated design styles and data-heavy interfaces.

To learn about domain-specific design paradigms, we researched on existing products, and realized that in general, the design styles are outdated and data-heavy. Although later we found out that many users actually prefer a more modern style.

"Feature creep" is becoming a challenge for Liquidnet.

After studying the current product, we built a product model, and conducted heuristic evaluations on Liquidnet. We realized that Liquidnet has been incorporating lots of advanced analytics technologies into the system, but the product is still designed for matching. As a result, customers find Liquidnet more and more complex and hard to use.

Liquidnet's product model
Stakeholder Interview
With no direct access to our target users, we interviewed 22 stakeholders and proxy users.

Having no access to target users, we instead interviewed stakeholders and proxy users. A technique we used with extremely busy interviewees is to bring pre-made artifacts like customer journey maps for them to correct.

me interviewing a stakeholder
Trader's life: 6 busy screens, a fast-pace workflow, keep calm, and make wise decisions.

We learned about the trader’s day-to-day work, like people they work with, a typical workflow, and their digital workspace. The key user needs we identified includes: consume information rapidly, collaborate efficiently, remain rational in failures, and control risks.

Trader's life: 6 busy screens, a fast-pace workflow, keep calm, and make wise decisions.

We learned about the trader’s day-to-day work, like people they work with, a typical workflow, and their digital workspace. The key user needs we identified includes: consume information rapidly, collaborate efficiently, remain rational in failures, and control risks.

Contextual Interviews (Poker)
Learned from poker: Positive reinforcement helps them maintain a healthy and rational trading mindset.

To understand the mindset and emotions of traders, we conducted contextual interviews with online poker players, because online poker is a very similar domain to trading, and is even often used to train young traders. We reviewed our observations on a matrix, which gave us inspiration for potential solutions to the emotional problems of traders. One major insight we got is “Positive reinforcement helps maintain a healthy and rational trading mindset.”

Shadowing / Observation
"If you can make building report easier, I'll be VERY happy."

We observed the trading desk in our client’s company during the market opening, mid-day, and market closing time. While observing, we used the AEIOU framework to focus around activities (A), events (E), interactions (I), objects (O), and users (U). We discovered several pain points that was not revealed in our interviews. One trader even directly tell us "If you can make building report easier, I'll be VERY happy." Although some pain points seems not directly related to alert (like report building, more efficiently search and navigation), but we see them as great opportunities.

03
Design Research

After having a holistic understanding of the domain, users, and product, we start to focus more on the alert system design. This section talks about how we generated a set of design guidelines based on analogous domain research and “research through design” method.

I was involved in the researches and was in charge of building prototypes.

Analogous Domain Research
We learned about general design principles for alerts and best practices.

We broke down our research question in to 3: how to attracting attention? how to initiative action? and how to gain user trust on the system recommendation? We researched in the academic/design field, and also looked widely into different domains for inspiration (including retail, advertisement, emergencies, gaming, notifications, autonomous driving, etc.),

Experience Prototyping / Research Through Design
Prototypes were built to validate design principles and test acceptance of conventional ideas.

We rapidly built prototypesbased on previous research. Then we tested traders’ reactions to our concepts in a simulated trading environment. This allowed us to generate tailored design principles in the future.

Prototypes were built to validate design principles and test acceptance of conventional ideas.

We rapidly built prototypesbased on previous research. Then we tested traders’ reactions to our concepts in a simulated trading environment. This allowed us to generate tailored design principles in the future.

User testing at a simulated trading desk with traders in our only chance with target users.
simulated trading desk

We only had one chance to talk with our target users in person, and we decided to use the “research through design” approach rather than exploratory research, so that we can gain a more precise understanding of their needs and preferences. We learned a lot expected/unexpected things, like "Animation isn't as effective as we thought in terms of grabbing attention", etc.

simulated trading desk
Feedback Grid
We generated alert design guidelines after synthesizing.

For synthesizing, we used the feedback grid method and modified the 4th quadrant to better fit our research. Our feedback grid has four quadrants: “what worked”, “what should be changed”, “new ideas”, and “general behaviors”. This helped us quickly generate design guidelines from each quadrant. For instance, from quadrant 1 and 2, we concluded DOs and DON’Ts, from quadrant 3, we extracted design limits and preferences.

us working on feedback grid
Example Guidelines

A mini window can be useful

Users preferred the un-intrusive feeling and space-saving characteristics of the “Bubble” prototype, though the visual design is too different from the current Liquidnet branding.

Salient color is the most noticeable

Salient color is the most noticeable, and it’s easy to read. However, care should be exercised to avoid unintentional attention (e.g., when a less important uncolored alert comes in, the colored alerts should not move).

Hierarchical views are important

Traders are faced with an overwhelming amount of information. A hierarchical view that displays details and quick actions on hover can be less obtrusive.

View All Guidelines
04
Design

Our next step is to build prototypes that apply the principles we concluded and validate them with users. This section talks about our ideation, prototyping, and iterating process.

As one of the two designers on the team, I designed half of our prototypes after the team brainstormed together.

Walking the Wall / Brainstorming
Brainstorm and decide on design features.

We brainstormed after reviewing all our previous findings, and decided on 3 topics with multiple ideas for each, along with 3 other ideas that can solve crucial problems even when traders are not executing trades. The 3 topics are: "grab attention", "drive action", and "customization". The 3 other features are: "report building", "smart searching", and "alert configuration sharing".

"Walking the wall" and brainstorming
Some of our storyboards
Storyboarding
Storyboarding helped us validate and refine ideas in contexts.

Then we separately sketched our ideas for each topic and compiled them into a user story. Through an internal critique, we integrated our parallel designs into one set. Storyboarding not only helped us validate the ideas in the context, but also helped everyone in the team be on the same page.

Some of our storyboards
Testing
Remote testing with traders directed us the way to narrow down and improve our designs.

We tested our prototypes with traders through screen sharing. This helped us narrowed down on the designs (e.g., the floating box minimized view versus the sidebar design.), and fixed details that needed more work (e.g., missing buy/sell information on the alert cards). In general, the feedback validated the needs we identified previously.

Remote testing with traders through screenshare
View Final Design ↑
06
Reflection
Things we did correctly 😉
  • We quickly learned about the unfamiliar domain and picked suitable research methods.
  • We managed to proceed through proxy users and analogous domains when we don't have enough access to target users.
  • The design research and our "research through design" played well and greatly boosted creativity.
  • We overcame all the challenges working as a team from different backgrounds.
Things we can improve 🤔
  • Our designs are conceptual and fragmented. Given access to actual data and product, we can integrate it into the main product.
  • We couldn't do enough validation due to time and resource limits. After integration, more A/B testing can further validate the design.
  • We couldn't clarify the goal and success metrics with client in the first few months, which made us abandoned all our designs halfway through the project. We will make sure things are crystal clear next time.