Content

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.