Helping traders win by focusing on the right trades.

As banks continue to build on the digital banking momentum, they must pay attention to design debt and cross-platform consistencies within their digital suites. This will improve user satisfaction, process efficiencies and cost to serve.

In a recent engagement with a global bank, Norman and Sons discovered significant challenges caused by a lack of interconnection between trading applications in equities.

The Challenge 

Traders in equities are under pressure to respond to important trade requests in the right way.  

Traders were using a suite of applications to obtain the data they needed to price a trade accurately. These applications looked and felt different from each other – worse still, the applications didn’t talk to each other. 

Basic example;

When pricing an RFQ for Vodafone, traders must manually enter ‘Vodafone’ in 5 applications: 

  • The Pricer
  • The Risk viewer
  • Trade & RFQ History
  • Market data
  • Lifecycle Management

What’s the problem?

With only 10-15 seconds to respond to the client’s request, it took too long to gather the data together to make an informed pricing decision. As a result, traders had to ‘go with their gut’ feel, which usually involved being very risk-averse. The bank was unable to price deals to win business aggressively.  

The Solution.

Norman and Sons sat with traders to identify the questions they needed to answer when responding to a client enquiry. We assessed which components needed to work together to provide the answer to these questions. We prototyped how desktop interoperability could allow traders to connect these disparate components to display a “trader fact pack” with just one click – preventing the need for multiple searches and filtering. 

We helped reduce unnecessary cognitive load on traders by ironing out user experience inconsistencies. The new design ensures that the most common actions are done consistently across applications, allowing traders to quickly identify the data they need – giving them more time to focus on getting the price right for the important trades.

As soon as I played with the first design prototype, I felt like a caveman using an iPhone for the first time. The positive impact on our decision-making ability has been immense.

By immersing ourselves with the traders, performing research, testing ideas before development and building an interactive prototype, we could better understand the traders’ goals and frustrations. We mapped the application needs, created a design solution and identified functional improvements which could be implemented across the suite of applications.


Trader RFQ response rates increased. Critically, the Bank increased its Hit Rate with its Tier 1 – or, most important – clients. 

More importantly, the quality of the pricing decisions increased: More trades were won in line with risk appetite, meaning traders were gaining the business that the Bank wanted.  

Traders agreed unanimously that the consistent design and user experience across the applications aids their processing of data, reduces the risk of human error, increases their rate of trade and makes their lives easier.

3 Reasons We’re Excited for FINOS 2022

What are the latest advancement in technology to streamline the Financial Desktop?

What are the latest advancement in private Blockchain technology?

For answers to these questions, look no further than ‘Open Source in Finance Forum (FINOS) 2022 in New York next month!

A conference dedicated to driving collaboration and innovation in financial services through open-source software and standards. Packed with inspirational speakers and experts across financial services and technology, we are excited to engage with the community and discuss the best ways to leverage open-source software to solve industry challenges. 

Our Chief Technology Officer ‘Seb Ben M’Barek’ will join Nicholas Kolba to showcase the latest developments on the #FINOS fully open source #FDC3 desktop container! 

Graeme and Jonny will be attending the forum with Seb this year. We look forward to seeing you there!

Here are three things that we will be watching for at FinOS 2022:

  1. Connecting OpenFin, Cosaic Finsemble and Glue42 on the Desktop.

Desktop integration technology can dramatically improve users’ experience by stitching together applications into one joined-up experience as if they were all from the same vendor. The problem is that the three leading desktop integration solutions in the market don’t integrate with each other! Aaron Haines of NatWest Capital Markets will be talking about his experience using the new FINOS FDC3 Desktop Agent Bridge. This is a game-changer if you need to integrate applications that have been developed for OpenFin, Finsemble or Glue42 on the same desktop.

  1. Introducing FDC3 Sail, “a Secure Open Source Container for an Open Source Standard”

FDC3 is an open-source standard which has been around for over five years and has attained wide industry adoption. Until now, there has been no open-source option for building FDC3-enabled platforms. The FDC3 Sail project solves this gap with a full-featured and completely open-source implementation. Seb Ben M’Barek from Norman and Sons will be joining FINOS’s Nicholas Kolba to demonstrate how easy it is to build an FDC3-enabled platform and get started on your FDC3 journey.

  1. Why Open Source Technology Is Critical to Widespread Adoption of CBDCs and Other Digital Currencies

Countries are implementing their own Central Bank Digital Currency (CBDC). There are upfront challenges in creating the framework for these countries. As adoption increases, we are seeing complexities evolve. Karen Ottoni of Hyperledger Foundation and Jennifer Peve of DTCC will detail why a multi-digital currency World can only be delivered with open-source distributed ledger technology.

At Norman & Sons, we are obsessed with UX on the Financial Desktop and have started our journey into Institutional blockchain. We are an official R3 partner and are looking forward to discussing the latest developments at FINOS this year!
To schedule some time with us while we are in New York, drop us a message.

Top Tips to Improve Project Delivery in a Remote World

‘Bees’ – World leaders in collective decision-making

It’s (almost) never a technology problem. It’s a communication problem!

As Technology consultants, we see many different ways of working, use a huge range of tools and meet all the Myers Briggs personality types.

Regardless of the project’s complexity, from a simple Risk dashboard to a complex low-latency Trading platform, I found that the reason for most delays is never about the technology itself but the poor communication between the people involved.

Since remote or hybrid working is the new normal, it’s never been more important to focus on great communication.

From my observations of what works from in-person to fully remote, here are the top 5 tips to improve project delivery with “minimum” effort:

Tip 1 – Create an ‘outstanding’ onboarding Wiki

Me:Can someone help me set up my Dev environment please?”

Everybody: 🙉

Back in the day, the answer would have been “RTFM Seb”, and that was it.

If you have never heard of the term RTFM, it simply means ‘Read The Freaking Manual.
An expression that was often used in Computer science circles to describe that the answer is easily found in the manual.

Nowadays, you’ll be lucky if there is a Manual in the first place.


In most places, although there is a Wiki to help new joiners get started, those guides are often out of date, imprecise and littered with jargon opaque to new starters.


An easy solution is to write an onboarding guide making the assumption that the reader knows absolutely nothing about the internal system and jargon. Avoid using acronyms and ambiguous terms.

Also, give the new joiner the remit to correct any mistake and clarify any ambiguity so that the next person finds it even easier to get started with the project.


  1. New joiner is getting productive faster
  2. Self-assisted, so not bothering others for trivial matters
  3. Painless experience for new joiner

Tip 2 – Create a ‘definition of done’ for your development process

Product Owner: Is this task Done?

Me: Well, it is Done but not released in Production.

Product Owner: When will it be Done, Done? 🎯


Although the shared goal is to ship a specific feature to customers, each team member is a specialist and is appraised on the completion of their specific tasks. I stopped counting the number of times a feature went back and forth from development to testing with the “It works on my machine” reason to close a ticket.


Does “Done” mean ‘I finished implementing the feature’ or does it also include Documentation, Unit tests, Integration Tests, Deployment to UAT, to Production?

Define and agree as a Team on what the definition of ‘Done’ should be. Write it down in your process section and make sure that the Team adheres to it.


  1. Stop wasting time
  2. Share a common understanding
  3. Avoid blame culture

Tip 3 – Create an Agenda for every meeting

Product Owner: Can you demo the latest release?

Me: 😱

In a very panicky way, I will type in my login details incorrectly a couple of times while on a screen share. I’ll have no script and no story to tell. After finally login in, I will discover that the environment is not working as expected. The demo comes across as uninspiring and unprofessional.


Most people find meetings a power drain. The main reason is that we join too many meetings where the objectives are not clear and attendees are ill-prepared so they run way longer than they should. (I mean you are probably reading this article while in a meeting 🙈).

Better still, ask yourself if the meeting needs to happen in the first place.


“No agenda, no attendance” is the motto at Gitlab when it comes to meetings.

I like this motto for a couple of reasons – First, you know what’s expected as an attendee and can prepare accordingly. Second, you can prevent Mindless Accept Syndrome (MAS), an involuntary reflex in which a person accepts a meeting invitation without even thinking why. To learn more about MAS, I suggest the excellent Ted Talk from David Grady.

The best way to get meetings to run efficiently is to add an agenda and set expectations for the attendees.


  1. Gather the right people in the room
  2. Give a chance for attendees to prepare
  3. Stop wasting time

Tip 4 – Record your meetings and publish them

Me: Sorry, I couldn’t make the meeting, anything I should be aware of?

Everyone: Nope, all good. 👍🏼

Product Owner (later in the week): This is not what I asked and I made it very clear during the Team meeting.

Me: 😡


We all have conflicts with life priorities and other business responsibilities, which means we can’t (and shouldn’t) make all the meetings we are invited to.


The solution here is to record every Team video call and publish them on the Team Wiki. Additionally, I strongly suggest using a transcription service like or Avoma. With the advances in machine learning, these tools are getting really accurate nowadays.


  1. More flexibility with scheduling
  2. Audit record of what has been said
  3. Repository of past conversations for absentees and new joiners

Tip 5 – Stop using ambiguous language

Me: Do you think we should write a blog post about collaboration?

Hannah: I definitely would! 😇

Me: Ehh, am I doing it, or are you doing it? 🤔

If you are not from the UK but have lived here for a while, the below will sound very familiar:

What the British sayWhat the British meanWhat others understand
Very interestingThat is clearly nonsenseThey are impressed


We live in a multi-cultural world with colleagues scattered all over the globe, the majority with another primary language and sometimes no cultural reference.


Try to use short sentences, eliminate ambiguous words, avoid adverbs and cut acronyms and jargon.

Also, try to limit the usage of idioms. (and yes, the irony of using the word idiom is not lost on me)


  1. Stop wasting time
  2. Share common understanding
  3. Set clear expectations

I’m hoping this article resonated with you and gives you some ideas on how to improve your communication.

If you want to dig deeper into the topic, I suggest reading the Effective & responsible communication guidelines from Gitlab.

Until next time…

Our Creative Director and Partner, Savvas Voudouris has been papped!

His success story has been featured in a recently publish  ‘Voria’ financial e-newspaper article.

Read the original article here.

The English-translated article is below:

Savvas Voudouris the graphic designer who excels in the heart of CITY

Together with three other partners, they created NORMAN & SONS, a consultancy which develops digital strategy, vision and applications for major investment banks.

Savvas puts a “face” to the applications of major investment banks, such as UBS, Credit Suisse and HSBC. It’s not just banking; he is currently responsible for designing a platform used by FIFA to organise major football events. Savvas adds the visual touch to many large digital initiatives to improve the user experience.

Originally from Veria, Greece, his love for design led him to found London-based NORMAN & SONS together with three other partners, Graeme Harker, Jonathan Corbett and Valeria De Luca.

NORMAN & SONS is a consulting company that designs the strategy and vision for large institutions, primarily financial but also other major industries. 

The company was created in 2016 and currently employs 40 people with a range of talents; designers, financial experts and application technicians.  Since 2018, NORMAN & SONS expanded its footprint to New York, with its business now running in Britain, Switzerland and the USA.

NORMAN & SONS have worked on a vast scope of projects from applications that help banks respond to crises and simulate the impact of market fluctuations to applications for budget and program transparency and solutions that help prioritize the most important issues in the day-to-day operations of financial sector businesses, to making it easier for users. 

Savvas Voudouris is a partner and Creative Director of the company. He plans to put a little more Greek flair and expand its presence in Greece, where NORMAN & SONS has collaborated with the insurance broker ‘Freedom’.  

From Veria at the “heart” of the City

Savvas Voudouris was born in Thessaloniki and grew up in Veria. From a young age, he loved drawing and creating. Immediately after school in 1999 he left for England, and studied design in Manchester. A few years later, in a three-month internship at Saatchi & Saatchi advertising company in Greece, he unknowingly opened a new chapter in his career, that of advertising, which took him to Spain and Italy.

His next stop, after a postgraduate program in advertising, was London, initially working for Saatchi & Saatchi, he then became an independent freelancer. From advertising he eventually returned to his great love, design, both in print and digital, he created his own company, Peel Me, inspired by Peel Street where he lived at the time. He started with small clients but moved relatively quickly to larger ones. such as Canon, Ford and British Telecom. In 2008 we has working on a large project, a digital platform for Morgan Stanley for equities, it was this entry into the financial industry where he crossed paths with his later partners of NORMAN & SONS.

In 2016 they made the decision to jointly create NORMAN & SONS, inspired by the choice of name by Donald Norman, founder of the user experience theory. From ‘Norman’ they added Sons, a word that starred the tailors of Savile Row. Given that the company was preparing to offer tailored solutions, cut and sewn to the needs of the customers, the referral to the tailors through Sons was a ‘perfect fit’.

NORMAN & SONS becomes fully immersed with its client’s projects, almost ‘living’ within the project, to see in daily practice the client’s needs, perform research and develop the strategy, vision and technical approach for a project needs.

Normans Assemble!

This week saw an afternoon of storytelling, knowledge sharing and sushi eating as our talented consultants (nicknamed ‘Normans’)  gathered from across our range of exciting projects. We run regular ‘Norman Days’ to bring our teams together, catch up on project activities, meet new Normans, gossip about the latest industry trends and ultimately put the World to right!

Hot topics of conversation from Norman’s day this week:

  • Swagger

Our tech geniuses are finding Swagger tools incredible helpful when developing API’s. It allows rapid development, quick testing and collaboration between teams.

  • Visualising Dataflows

A creative challenge one of our projects is conquering is creating an interactive interface to show backend dataflows visually. Clear data mapping can massively help future solutioning and development, we love to see some innovative, creative solutions from this team!

  • Sketch to Figma Migration 

We have numerous teams working for financial clients who are in the process or have recently completed a migration from using Sketch as a design tool to now using Figma. We love Figma and are very happy about these forward steps, however, the migration can be painful, and time-consuming, but, a problem shared is a problem halved and discussions on this topic has highlighted some great quick wins for our teams!

  • How developing spotlight-like shortcuts are helping structured financial trades

Improving user experience is what we do, and what better way than removing steps, clicks or even the use of a mouse. We are building a great new feature which will allow financial trades to be placed by typing a few quick shortcuts into a command interface. Press ‘Enter’ and the trade is placed.

How does your organisation knowledge share?

Braving the UK heatwave this week, Norman’s convened for a funfilled day of nattering, sketching and delicious food consuming! 

We run several ‘Norman Days’ throughout the year, a combination of social and working sessions with the primary aim of bonding as a team and having fun. With expert consultants of different backgrounds and skill sets working across a vast range of fintech projects in financial services, it’s great to share all our experiences regularly and learn what is working (or not) on different projects for different people. 

This time we focused on discovery across projects, understanding what our teams were doing within their projects, the project goals and who is working on what. We got creative and drew our target users to get to know them in a more rounded way. This little exercise confirmed that we have some very talented artists among the Normans but also allowed us to challenge assumptions together.

Getting an oversight of what ‘The Normans’ are up to helps us relate experiences and problems to develop better solutions.

Knowledge sharing is the ultimate form of learning, and what better way than within our organisation. 

How continuous is your research?

The presence of research in product development and continuous improvement should be as constant as social media activity. Otherwise, research becomes irrelevant and a simple tick box exercise.

Simply completing research at the start of a project just isn’t enough, and as time goes on, the needs of your users start to change – just like the trends on social media.

Be in it, to win it!

We do a lot of research continuously on all our wonderful projects, through our eyes, this is the only way to guide product design and ensure products are solving the real problems of users. It also allows us to become fully immersed in projects, connect with users and discover the challenges we can solve with a great product!

Do more research

We need shared names for things

When we work on things together we often need to agree what we call things. My daughter and I have developed a language for the most common components to help us build lego constructions as a team. We call this lego block an “eightser”. Our names for these logo blocks are just like the names in a UX “glossary” that we use in service and product design.

The importance of a “glossary” was made very real for me as I tried and failed to get a NORMAN & SONS team onboarded to a bank we’ve not worked for before. To get access to the bank’s systems I needed a secret “token”. This “token” is normally generated by an iPhone app to ensure that it’s me and only me attempting to get access. Unfortunately to set up this iPhone app I needed to have access to the bank’s systems. To get around this “catch 22” scenario I had to call the bank’s help desk to get a temporary “token”. This process was a bit more complicated because I also had a username (that that looked very much like a “token”), an initial password (that’s also looked like a “token”). What was confusing was that this “token” was called a “pass code” on the bank’s logon screen, a “token” in the documentation for new users, and something else by the bank’s automated help desk.

When we’re designing new user experiences for our clients we recommend creating a shared “glossary” of terms that everyone can agree on and that everyone is required to use, not just software designers but also the guys who write the documentation, the guys who record the automated voice messages on the help desk, support staff, everyone involved in creating the service for users.

Are your applications dated and disjointed?

Are your legacy applications powerful and rich with functionality, but looking dated and disparate? Do they compete for real estate on your users’ screens, as they switch between multiple products to complete tasks? Do users get lost between the applications risking the likelihood of mistakes, while they complain that everything’s so much easier on their mobile phones?

Every day, more organisations recognise that forcing users to navigate a multitude of disjointed applications and re-key information between them is having a direct impact on their operational costs and the quality of service they provide. Likewise, customers are forced to suffer long hold times and make repeat calls when they simply wanted to update an address, or get a wealth manager to make a portfolio change and assess the impact.

Managing, maintaining and monitoring vast numbers of applications – some of which are decades old or written in now-defunct programming languages – is a mammoth task and expensive to sustain – not to mention the increase in training costs and desktop complexity. In an attempt to regain control and improve user experiences, organisations are embarking on application consolidation projects or commission multi-app dashboards.

In an attempt to improve the experience for users, big organisations have invested millions of dollars on large-scale application consolidation projects to re-write their legacy customer-facing systems from scratch. These initiatives have largely been successful, but have required significant investment and tend to mean pausing innovation. This is often not the best approach.

An alternative approach is to use an off-the-shelf enterprise interoperability platform to integrate old and new applications on the desktop to provide a more joined-up user experience. Leveraging a pre-packaged platform to provide the core interop functionality allows your tech teams to focus on connecting your data and applications, benefiting from features and expertise that have been developed and honed with similar businesses. This approach also allows you to decommission legacy applications written in legacy technologies on a step by step basis over time.

Whichever technical solution an organisation chooses, there are still a number of challenges that must be faced. These are some of the key questions that we feel organisations should consider when embarking on an enterprise interoperability initiative:

Do we really know what our users need?

IT-driven initiatives often focus on solving the meaty, thorny technical problems. Although there is merit in proving out the technology for legacy complex programs, it often means losing sight of the most important use cases that can bring tangible value.

We often see time has not been taken to understand core user workflows and the information and functionality users need to complete their tasks efficiently and happily. It doesn’t matter how feature-rich your interop platform is, failing to invest in the user experience means failing to address user needs. This causes barriers to adoption, impacts user efficiency, and increases the development costs associated with rework and short-term fixes.

Do we have sponsorship in the firm at the right level?

Without a decisive and visionary sponsor who has both remit and authority, momentum soon stalls and time is consumed with circular discussions around minor issues. A project like this may be the first time that different development teams are asked to collaborate, but those involved likely extend wider than your application developers.

For a successful interop initiative, a senior leader must also take charge of multiple business areas, to effectively collaborate and factor resources and budgets into their planning cycle.

Do we have a governance model to ensure that users are well represented inside our firm?

Lack of leadership across individual development teams can mean duplicated development efforts, repeat components (for example, each application maintaining a separate search function) and time being wasted arguing over details. Additionally, when teams work in silos, knowledge is rarely shared.

Without strong management and a cross-project governance framework or implementation methodology it’s hard to ensure the innovations you make for one application are leveraged by other development teams responsible for the other apps that users need to use to get their jobs done.

Do we need a central UX team to ensure success?

Researching the user journeys required to achieve business goals is essential. Managing UX centrally – with a design system, component and pattern libraries, and accountability for modifications and approvals – removes individual opinion and bias from design decisions and ensures a scalable and consistent experience across all applications.

Usually, user research is confined to a discovery phase (if conducted at all) and not embedded as part of the initiative. We often see projects where IT are reluctant to engage with users, as they are fearful of scope-creep or backlash from disgruntled voices. The features or applications prioritised are driven by technical requirements and the solution drifts from what users actually require.

An obvious symptom of this is users not engaging with the new platform. Additionally, it’s common to see product teams kept at arm’s length from users, with research and feedback not relayed. This results in teams being disillusioned and detached which will also delay adoption.

Choosing a technology is just the beginning

Choosing a full-service interop platform that has been proven in similar complex organisations can mitigate some of the problems outlined above by facilitating both the orchestration of the user interface (UI) and integration of data. Finally, inbuilt soak and sanity testing, the ability to remotely debug, and the ability to handle underpowered machines through app hibernation techniques will accelerate your DevOps and QA processes during production.

However important the technology choice, it’s really just the beginning. An enterprise interoperability program is a strategic initiative that requires a long term buy in from senior management. Identify a senior sponsor capable of unifying dissimilar teams and business lines, embed robust governance and operational practices and ensure a foundation of user-centricity.

Investing in your initiative’s approach is vital for a successful and scalable interop rollout that is embraced by users and technology teams.

Did they fire the right guy?

In January 2018, an employee at Hawaii’s emergency management agency sent out a false alarm of an imminent missile attack, and was subsequently fired – but perhaps poor system design is really to blame.

Most people are likely to have seen the story about the false warning of an impending missile strike on Hawaii earlier this year that had people diving into basements, car parks and sewers to take cover.

I am sure you would have been in there with them, too, if you had received this warning text:

Fortunately, half an hour later the warning was revealed to be a mistake; someone, somewhere had pressed the wrong button. When intending to choose the “this is a drill” button, they had selected the “this is NOT a drill – everyone start panicking” button. 

“What a fool,” cried the angry mob. “Fire them immediately!” And sure enough, they did. Almost immediately, the reckless button-pusher was removed from the seat of power, meaning the citizens of Hawaii could sleep easy again.

A few days later, however, a screenshot of the button, or rather buttons, in question was published. Suddenly, it became apparent that perhaps the mob had been a bit harsh on the button-pusher:

The only difference between the test button and the send-everyone-into-the-sewers button was the word DRILL in blue text.

Fair enough, I would back myself to pick the correct option nine times out of 10, but where is the exclamation mark? Where are the skull and crossbones? Where is any sort of attempt to point out that selecting “PACOM (CDW) – STATE ONLY” is a huge deal?

In light of the new evidence, there were campaigns for the government to reinstate the unfortunate button operator, as we could all see how their mistake was easily made.

The mob turned its wrath on the designers of the tool, not the operator.

Where to point the finger of blame

So who should be fired?

Should it be the cowboy developer who carelessly built the screen as if it were their first personal website on Geocities? That would be harsh. They almost certainly were not hired on their design ability and probably never had the right training.

Okay, so it must be the user experience designer, right? Absolutely – we’ve got them! Nail that person to the wall for quite possibly the worst-executed selection mechanism ever designed; cast that designer into oblivion for blatantly bypassing the user testing phase of the design.

The only problem is that there was almost certainly no user experience designer. Why would you need a designer to make the buttons shiny and beautiful? There are no customers to attract with a beautiful interface, no data to visualise. That’s what designers do, isn’t it?

It is this misconception about what designers do and when it is important to use them that caused the Hawaii panic.

A designer would have understood that the person in charge of triggering the regular incoming missile DRILL changed regularly, and that they were likely to be doing 10 things at once while deciding which button to select.

A designer would have taken the time to understand the huge difference between a DRILL alert and a real one, and designed quite different ways of triggering them. They would have tested their designs in a realistic environment, with the people who are in charge of pushing the right button.

A designer would have made sure that the user had to explicitly confirm their action to send alert messages to thousands, perhaps with something like this:

Unfortunately, it is difficult to fire a misconception. We are after a real-life, breathing human to parade in front of the cameras, to put in the stocks. Who is it going to be?

Fire everyone involved in the misconception

I say we fire everyone who contributes to this misconception, starting with the phoney cowboys who call themselves user experience designers but who design things without involving their users in the process.

Add the bosses of companies that make a business of selling these phonies at an industrial scale, fooling naive clients into parting with their money in return for a shinier, but equally poor product at the end.

And finally, let’s add the IT managers and budget holders who like the idea of designing products in a user-centric way, but do not give designers the time or environment in which to do a good job.

Today, in your town or city, I bet there are thousands of people telling each other (and themselves) that they are “doing” user experience design when they are not.

It is these people who have led to the corruption and commoditisation of the term “user experience design”.

It is these people who have let down those project sponsors, IT managers and developers who saw the potential in user experience design, only to see it done so badly that they will not try it again.

It is these people who have therefore made the case for true human-centric design harder to make, and occurrences such as the Hawaii missile alert more common than they should be. They have to go.