I Thought I Knew this Tank: A Story About Software, Goldfish, Ego and Expertise

Two goldfish are dropped into a new tank.
One turns to the other and asks, “Do you know how to fire the cannon on this thing?”

That single gag captures the moment when what you expected collapses and the script is flipped.

It has similarities with what users experience when a software transformation is forced on them – when they’re first dropped into the new tank.

Stick around and I’ll share a story about how one software tool made me feel like a total goldfish (not the battle-hardened military strategist I thought I was)!

.

Misdirected Assumptions

I’ve noticed that there are two common mis-perceptions about expertise with complex software solutions:

1. The project team assume that because the fish are dropped into a tank, it must be something they already understand
2. The SMEF (Subject Matter Expert Fish) that has years of experience with one tank thinks they’re an expert with all other tanks

My “goldfish experience” proved that familiarity with one kind of tank doesn’t automatically transfer to another kind of tank.

Even when you’re experienced, a new platform often:

• Has terminology that sounds right (more or less)
• Looks familiar on the surface (menus, dashboards, buttons)
• Uses concepts you already know (data, workflows, inputs and outputs)
• Lives in a domain you’ve worked in before and “should” be familiar with

But the user experience is actually entirely different – as different as a fish tank is to a battle tank:

You may have complete context of what needs to be done, but not:

• Where the controls actually are (how to steer the tank)
• What logic and/or assumptions the tool makes (whether it has a cannon)
• What actions are safe versus destructive (whether you’re actually firing the cannon at the right target)
• How small mistakes cascade into big problems (when you accidentally hit the fire button when the barrel was pointing in the wrong direction)

Until you learn the specifics of driving this tank, you end up asking questions that sound ridiculous to outsiders who think you’re the expert:

• “What do I actually click to make all the logic work in this solution?”
• “How must I structure the data?”
• “Why does this behave so differently from every other tool I’ve used?”
• “What’s do I have to avoid doing so that I don’t break this?”

Just like the fish:

• They’re not stupid
• They’re not inexperienced
• They just need to get up to speed with this new tank

The deeper point for us as designers is this:
How do we eliminate the learning curve?

Let’s start with the reasons behind the long learning curve:

.

Reason 1 – Legacy Experience Doesn’t Map Cleanly to Other Platforms

Each system’s experience is deeply contextual.

Legacy systems operate in specific sequences, signals, logic and constraints.

Alternate platforms often reuse the same words while implementing entirely different logic underneath and user interfaces up front.

This creates a dangerous form of confidence. Engineers recognise the domain and assume transferability, only to discover that the script has been flipped.

.

Reason 2 – New Tools Turn Experts Into Beginners Again

There’s an emotional cost to losing fluency. Having to ask junior colleagues how to do the most basic of tasks with the new solutions is embarrassing.

Senior engineers and architects are used to moving with confidence, reading systems instinctively, and knowing exactly what to do next.

Unfortunately, each new system requires a new “apprenticeship.”

Confidence drops before competence returns, and that transition is rarely acknowledged in transformation plans.

.

Reason 3 – Familiarity and Abstraction Mechanisms Mask Hidden Logic and/or Risk

Modern OSS platforms often reduce complex workflows into simple interactions.

To improve efficiency, a single click in one solution can abstract / replace a chain of checks, validations, and approvals in an alternate system.

For SMEFs, this can be unsettling.

User interfaces that look familiar enough and encourage speed… but…

Unfortunately, I’ve experienced all too often that situation where you take two configuration steps forward and three steps back – when the decision you made earlier has unintended consequences further down the track.

Localised tenure is essential for understanding all of the steps – backwards and forwards – that are possible with any given solution.

There’s been many a time when I’ve only learnt where the cannon is pointing after it’s been fired (in the wrong direction).

.

Reason 4 – Software Transformations Consistently Underestimate Learning Curves

Most complex software transformations (such as the OSS/BSS tools we specialise in for large network operator clients), only plan for the most basic levels of onboarding, nothing approaching mastery.

Training focuses on feature walkthroughs and happy paths, assuming experienced users will automagically find a way to fill in the gaps themselves.

In reality, almost all users need to do a longer “apprenticeship,” not only a two-day training course just before go-live of a new system.

Experts need sandpit environments. A space to explore safely, to understand failure modes, and to build intuition.

When delivery timelines ignore apprenticeships, sandpits and “play-time,” teams either avoid using the tool’s full power or learn through incidents in production environments.

.

Reason 5 – “Intuitive” Software Design Should Accelerate Experts, Not Just Beginners

When designing sophisticated software solutions, we can’t just eliminate all complexity.

Good user interface (UI) design should reduce the cognitive load of most standard users without eliminating the more nuanced requirements of power users. It’s what I refer to as lowering the intuition age.

Regardless of whether the user is a novice or an expert, all users should be able to progress quickly from safe exploration to confident control.

Now I know you’ve been waiting patiently. Time to share my goldfish experience.

In the first 15 years of my OSS/BSS career, there was one particular domain that was common to most projects. It was a functional area where I felt quite at ease, having used a variety of different vendor solutions.

I knew the use-cases / workflows. I knew the data sets. I knew how to build complex data models to handle all sorts of different network types and topologies. I knew how to get creative to solve problems the designers would’ve never imagined their solutions being used for.

Can you hear the ego balloon inflating, one breath at a time?

Now imagine the sputtering hiss as the balloon tears free, flailing chaotically around the room, emptying itself in a single, humiliating rush. That was me when I moved across to work with a new vendor in the same domain.

Unfortunately, I spent at least six months using that vendor’s software before I felt even mildly competent with it. Holy guacamole! That’s awful. To be honest, I actually felt like a fraud.

And if I were asked to use that same product again today, it would probably take a further six months to get back up to speed.

I’d still be driving it around like a fish tank, not firing on all cannons!

To protect my fragile ego, I like to think that my goldfish experience was mostly due to a really unintuitive solution design.

Now, I was expected to be a power user of that software, not a standard user, but the following questions remain the same:

If you’re a product manager, have you ever tried measuring the intuition age of your OSS?
Have you ever considered benchmarking it (or an equivalent usability metric) and seeing what you could do to improve it for your OSS products?
Can a 7 year old figure it out or does it require a double-PhD with 6 months of hands-on experience to easily navigate it?

Both of my children were adept at navigating their way around our iPad (for all sorts of different use-cases) by the age of three.

If we were able to do the same for our other forms of software, there would surely be no goldfish moments right?

Oh, and if you ever need a goldfish audit done on your OSS/BSS…