Goldfish software. You’ve asked me this before

In this post, I am going to talk about an issue which gets overlooked often in tech. Specifically, products or services that ask information they have already. For want of a better metaphor, let’s call this “goldfish software”.

Banks and insurance providers are great at behaving like goldfish. In addition, the large tech companies don’t do much better here. For example, my former employer, Workday makes you fill out a lengthy form every time you apply for a job on their platform. As you can imagine, their users love to repeat themselves with lengthy forms full of redundancy.

I’m sure there are dozens of people out there who get their kicks as unpaid data clerks for large tech companies. Personally, I don’t want to spend time at a party with them, but surely they exist somewhere.

Why does software act like a goldfish?

I’ll level with you. I don’t really care why software behaves like a goldfish. However, I am interested in the ways to address this issue. Oh, and yes fellow pedants, goldfish have actually got good memories but we are this deep in so let’s stick with this stretchy metaphor.

It is understandable that things are the way they are. Large companies and legacy organisations have a lot of dependencies, tech debt, other priorities, and pressure to deliver new stuff and feed the beast. Meanwhile, it’s difficult to justify fixing things that technically work and often you need to pick your battles. That said, we ought to be better at eliminating redundancy.

Provide context when and where you can

It’s often not difficult to understand what our users are trying to achieve if we take a moment to think about it. That is to say, all it takes is for us to put ourselves into someone else’s shoes is a little imagination. Instead of focusing on the “happy path”, we need to design for where things go wrong. This is a mistake that erodes trust and pisses people off.

A real world potential goldfish

Recently, we added the capability to handle join requests in CYGNVS as part of a security measure to prevent unauthorised access. This is an approval step where admins can review new users before they get access to the platform. The requirements were fairly simple with either approve or reject sending emails to the applicant. The happy path includes a link to get in, and the unhappy path was to include a way to contact support.

Meet and go beyond software requirements

Consider the following statement sent as an email:

Your join request was declined, please contact support at

This meets the base level requirements. But, it kinda sucks.

  1. I don’t know who declined my join request
  2. I‘ve no clue as to why
  3. I can contact support which is nice, but what do I need to include in the email to avoid going back and forth playing email tennis

Comparatively, let’s take this example:

Joe Bloggs ( declined your join request to Product X’s account. “Hi Eoghan, your application was denied for some compelling reason.”

Contact support

  1. I now know Joe Bloggs has rejected me. How could you Joey!?
  2. I have additional context. I know what (Product X), and why (compelling reason)
  3. Contact support uses a mailto link to write the email for me. Yay! I don’t have to write.

Respect users and don’t goldfish them with software

This second example is pretty low cost to implement. Mail to links are as old as the hills, and work great when used in emails. Admittedly, they can behave a bit weird on web, but being able to pass parameters in is pretty magic feeling and not often done. However, I’d recommend some caution here as you are literally putting words in peoples mouths. Chris Coyier has some good advice on this.

Importantly you treat a user who’s been declined with respect and your tool does not behave like a goldfish. As a result you give support the information it needs to act on the request, and save them hunting for information from the person who is getting in contact. This makes them look good, and speeds things up for everyone. Win, win.

Useful links. Well… links at least