Content

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.

Are you designing Homer Cars?

User Centric Design: YES! – User Dictated Design: NO!

Long long ago in the bad old days of design before User-Centric Design was a thing, we completely ignored the people that would actually end up using our software. Along came people like Don Norman and companies like Apple who told us that this was ridiculous. Now we know that in order to design something that people want to use, those same people need to be involved in the design process itself.

So all power to the users! They can tell us exactly what they want, we can give them a pencil and paper and our application will be a great success…

…Apart from it won’t. It will be a Homer car.

When Homer Simpson’s brother gave him the opportunity to design the ultimate user-friendly car of the future, he packed every possible feature into his design: donut holder, optional muzzles for kids and a horn that plays La Cucaracha. https://www.youtube.com/watch?v=EHGczDHTDpo

The exact same thing (perhaps minus the donut holder) will happen to our application: Crammed with data and unnecessary features, it will be a confusing, overwhelming mush.

This is user dictated design. And it is bad. And it happens a lot.

It’s easy to understand how user dictated design happens in large organisations: As User Experience Designers we desperately need the input of the user community, so we are grateful when they are keen to get involved and we don’t want to kerb their enthusiasm when they start suggesting design ideas and even sketching screens. It’s awkward to take the pencil away from them, go back to the start and ask questions about their daily routine, goals and frustrations.

But we have to avoid user-dictated design. Right from the get-go (in kick off sessions and each user interview) we have to politely but clearly establish a productive relationship for user research: We have to explain to our users that we want to start from the beginning: we want to hear about what they need to achieve and the questions they need answered rather than the colour they want the buttons to be.

‘I need to digest our key risks across the 3 regions’: Great!

‘I want a 3D pie chart of key risks split by regions’: No thanks!

Observation sessions are vitally important in helping us understand the true needs of our users: Watching someone struggle through a complicated series of reports and spreadsheets sometimes gives us more insight than what people say they need.

Most people know that user interviews and observational research are vital ingredients for a successful product. But people and organisations are held back because too often they fail to set up the productive designer:user relationships required to do it properly.

There are a lot of Homer Cars out there.