NEW YORK | November 13 |Graeme Harker, Managing Partner discusses “Why Integrate Applications on the Desktop?”
We are excited to be speaking at this year’s FinTech Festival in recognition of our expertise and ongoing research into desktop interoperability.
This year’s theme is FinTech and the Future of Capital Markets Ecosystems. Emerging technology is impacting capital markets participants’ choices around market collaboration partners, transaction venues and data and the industry is leveraging these technologies to create efficiencies and competitive advantage and bring entirely new business models and revenue opportunities to light.
Graeme Harker, Managing Partner of NORMAN & SONS, will be discussing the role of desktop interoperability platforms.
“Why Integrate Applications on the Desktop?”
The number of applications deployed to financial desktops continues to grow each year. While many will be SaaS based, a typical desktop will already comprise a mix of in-house and third-party applications written at different times or procured from different vendors. Despite the adoption of automation technologies, the desktop environment remains a complex battleground between humans and the systems that were designed to support them.
In this talk, NORMAN & SONS will discuss the role of the latest generation of desktop interoperability platforms and how they can be used to simplify user journeys, reduce operational costs and monitor compliance.
Free webinar | June 25 | speakers from JP Morgan Asset Management, Norman & Sons and Glue42
– What do I need to do to deliver a joined-up user experience for users and get the critical stakeholders interested?
– Will adopting a desktop interop platform and industry standards (e.g. FINOS) save me time and money?
Join TABB Group and speakers from JP Morgan Asset Management, Norman & Sons, and Glue42 as we discuss the theory and reality behind getting your desktop transformation right the first time.
NEW YORK: We led a round-table discussion with COOs on how we use Design Thinking to help large financial organizations to innovate
Armstrong Wolfe’s Women in the COO Community leadership evenings provide the opportunity for senior women in business management to connect and to help promote the cause of leadership for women across Financial Services.
Kristie, Head of Delivery U.S. led a breakout session on innovation discussing our experience of using Design Thinking to help large financial organizations to innovate.
Innovation is often mistakenly framed as new and disruptive ideas that result in ground-breaking new products. But in truth, innovation is incremental. It requires management and processes.
Why is it so difficult to innovate in large organizations?
LONDON: NORMAN & SONS keynote speakers at the FinTech Design Summit 2019 alongside Google, Monzo and Lloyds Banking Group.
We were delighted to be asked to deliver a keynote presentation at the FinTech Design Summit in April, alongside speakers from Google, Monzo and Lloyds Banking Group.
We knew this event would be extremely popular and the venue was completely packed out with attendees.
Louise spoke about how setting a foundation of DesignOps can help banks and FinTechs achieve their product vision and encourage ongoing innovation.
The questions and conversations we had following the keynote suggested that many in-house design teams are scaling quite rapidly to meet the demands of their organisation, but are struggling to maintain coherence, communication and consistent output.
Thanks to Luke, Steve and the rest of the TechCircus crew for a great event.
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.
LONDON: DesignOps and Innovation keynote for digital leaders
Innovation is often mistakenly framed as new and disruptive ideas that result in ground-breaking new products. But in truth, innovation is incremental. It requires management and processes.
Fairly recently the term ‘DesignOps‘ was coined to cover the operational aspects of design. As well as management and processes, it includes the practices and tools that enable design teams to work more efficiently and effectively, and – ultimately – to deliver well-designed products.
In practice this may include establishing a Design System, streamlining recruitment, consolidating design tools, and embedding regular critiques and reviews.
Something so focused on process may seem contradictory to creativity and innovation – but a framework of DesignOps can accelerate innovation.
This was the topic of our recent talk to an audience of digital leaders in London:
Why is it so difficult to innovate in large organisations?
What does innovation need to thrive?
How can Design Thinking and DesignOps support innovation?
LONDON: NORMAN & SONS help CloudMargin realise their vision and deliver to customers
We worked closely with CloudMargin over the past four months to realise their vision of a new UI and UX, to support their growth as they serve some of the largest and most sophisticated financial market participants in the world.
We conducted comprehensive research to ensure that user needs and behaviours were at the centre of any innovative updates, illustrated the Vision of CloudMargin’s product owners, and set up a foundation of DesignOps to ensure the delivery teams could build new features efficiently and at scale.
The improved product experience is now being rolled out across the platform.
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.
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.
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.
