28th May 2020

Reactive Trader^®‘s Experience Design Evolution

How a demo platform has evolved and is used by the Experience Design team at Adaptive

With the latest release of Reactive Trader^®, we felt it was time to talk a little about how we work on and maintain it from a design point of view.

Reactive Trader^® was designed as a demo platform to showcase the skills and know-how of the business and the experience of the individuals that work within it. What began as an Open-source development showcase has now evolved into a test bed for all of Adaptive’s practices to experiment on.

As an Experience design team it has allowed us to try out some new behind the scenes design infrastructure and see how this could help with new client engagements in the future. This article will give you a little insight into the work we’ve been doing here and on how we work within the Adaptive Experience Design practice.

The history of the experience and it’s updates

The very first version of Reactive Trader^® was never about ground breaking experience design: it was about creating a professional Foreign Exchange interface that was super performant showing a simple click and trade workflow. It followed a familiar industry-wide layout of floating currency tiles above a simple blotter capturing executed or rejected trade requests.

From here we made small updates such as showing a positions component, playing with infographics and experimenting with simple responsive design behaviours. This then evolved to thinking more about a mobile experience and the use of touch devices. What moves where? Is there a limited experience on mobile? These are often things we need to solve on client projects and although a responsive site can be seen on a mobile, it’s a very different experience with different reasons for it to exist there. It helped us to realise we need to ask questions around why this should be on a mobile in the first place, what would be the realistic client scenario we are catering for?

We have experimented with the visual style, looking at a futuristic look and feel. We also played around with an amended workflow using the new Crypto markets and how order entry could be added that works both on desktop and mobile.

Having realised there are many possible directions and many ways to implement all of these changes the single most useful thing we could do was actually look at how we can continue to control, scale and implement these changes on the platform.

Just as the underlying code and technologies change and evolve so should the front end experience. So we started our biggest ‘background’ change and that was to set up, test and run a design system on the platform.

Setting Up A Design System

If you haven’t heard about design systems before then I would strongly recommend some light reading in this area. It formed the basis of one of our FinJS talks a while back but essentially it is the key to building any enterprise level platform or eco-system of digital products. But what does it allow you to do?

In summary, it provides the following;

Structure to your visual implementation and behavioural patterns.
Guidance on how to scale and add new elements and functionality.
Gives flexibility to change direction quickly and in a consistent manner.
A design eco-system for one or many designers and developers to work from.
The ability to design and deliver at speed.

It allows you to do all of the above by breaking your UI into small reusable elements. There are various naming conventions and methods of doing this but we feel sticking to the original Atomic design system is the best approach.

What does our design system look like?

You can view a live version of our style guide here. The Atomic design principles have 4 levels of complexity;

Atoms.
The simplest and smallest level. Consists of buttons, input fields etc.
Molecules.
A combination of at least two or more atoms. A collection of titles and input fields to create a section for a form.
Organisms.
A combination of molecules and atoms together to form a functional element. The actual ticket entry form with sections and submit buttons etc.
Templates.
Reusable layouts of content which combine atoms, molecules and organisms. Headers, footers, grid system layout.

Here is a snippet of how our currency tile breaks down into some of the elements above.

Each colour used in the UI also maps back to a single colour from our UI palette. This provides us with the ability to completely re-skin an entire UI or set of UI’s by amending a single colour palette. What’s important is we can do this in our design environment as well as in the live build. So we’ve mimicked the development behaviours in our design infrastructure.

This basically means re-skinning is super simple to test and then implement. We’ve designed a light and dark theme to showcase this in the UI.

The power of a design system

However the real power of a well structured design system is how it can continue to aid other projects or features. For example as a team we have two separate projects running related to the Adaptive demonstration platforms.

Reactive Trader^®, this is where all of the FX related interface elements sit, including workflows, responsive behaviours and more.
Interop Launcher, this project holds workflows and details about the OpenFin delivered desktop launcher. Shown below.

The design system itself however exists as it’s own standalone project that spans and makes itself available to both projects. We reference it as the Adaptive Theme project and with the use of Abstract (a design management tool) we can easily link and build a relationship between these projects and the single theme project.

This allows us to theme both projects using the colour references we have already defined, pull in and use atoms, molecules, organisms and templates that already exist and essentially leverage all the hard work already carried out for a different purpose here for a completely different scenario.

It is now also much easier to separate responsibilities within the Experience Design team and so is possible for us to scale our team’s involvement in a controlled and structured manner. We can have someone maintain the core design system while others work on specific features or workflows in the respective projects.

Our designer developer hand-off process also benefits from this structure. The design system atomic naming and colour references are largely one for one in code so we ensure we are talking the same language in design as we are in development. One team member can liaise directly with the developer responsible for maintaining the UI component library while another works with a developer on implementing new workflows.

We get really excited about the power of this structure and how it enables us to focus on delivering new workflows quicker yet still give us the power to change any and everything simply no matter the scale of the project.

In summary

We’ve created a scalable environment for the Adaptive ecosystem to evolve in. Our design system infrastructure is now being heavily utilised as we design and implement desktop strategy showcases across multiple delivery mechanisms (OpenFin, Glue42, Finsemble, PWA).

We can share this system with multiple UX designers and ensure they are able to add new features in a controlled, consistent and ‘as designed’ manner.

Having our own in house development platform, although quite a bit simpler than the typical client platforms we work on, is allowing us to enter client engagements from a more informed view. We are now not only able to deliver business value experience workflows but also provide guidance and expertise on setting up your design infrastructure so that future initiatives can benefit from previous work and fit into a global design strategy.

What’s coming next?

We want to continue experimenting and are looking to summarise, on an experience level, how the Adaptive ecosystem translates across other delivery systems such as Glue42, Finsemble and PWA moving from web to desktop experiences. We want to see how these differing delivery mechanisms can be leveraged on the front end and what positive changes they open up to the experience. You can view our current implementations in this space here but we will be publishing some findings very shortly.