Your new feature is clever — but does it work in real life?
There’s an old adage in software development. A developer rocks up to their client’s office, uploads their code to production, and runs into issues. They tell their concerned client: “Well, it worked perfectly on my laptop!”
The moral of the story is that your code needs to work in the environment where it will run – not just where it’s built and tested. The same principle applies beyond the technical realm. A feature that works perfectly in a design meeting with a team of experts can still fail in the real world with real users.
Failure to think ahead
A common manifestation of this oversight is when a company or regulator thinks it’s come up with something smart, but it actually makes the product less usable for the end user – in extreme cases preventing the user from doing what they want to do and reducing the product’s utility. Examples include…
The EU’s now-mandatory car eye tracking systems. The tech is designed to discourage distracted driving by chiming in when it looks like the driver isn’t paying attention to the road. However, drivers report false positives for things as common as a quick glance at the scenery. Ironically, this can cause more distraction for the driver, and they may simply mute the feature. The system clearly wasn’t tested in a way that reflects real driving conditions.
Shoehorned-in AI features. I could choose from any number of examples here, but the one that’s been irking me the most recently is Confluence, where the “rewrite with AI” button now occupies the space where the text style selector used to be. Every time I try to make a paragraph a heading, my muscle memory inadvertently triggers an AI scan of the whole page.
Sony’s decision to stop releasing PlayStation games on disc. This is a more deliberate choice, but the same principles apply. Digital-only games might work fine for someone who plays the latest releases and moves on – and being charitable for a moment, those are the players I have to assume Sony were envisioning with this change. But real users don’t think like Sony’s product designers. Gamers take pride in building their libraries, and enjoy returning to their favourite titles decades later – which won’t be possible if the servers hosting the digital download have been switched off.
Designing something that works
The lesson is that your idea needs to work in real life with real users. This applies both conceptually (it has to be something they want) and in terms of usability (it has to work for them, and not obstruct other functionality).
On the first point, a quality product is built for customers. The principles are simple: give customers what they want, and don’t take away things they like. Tough times may require compromises, but if your business is profitable and you’re making unpopular changes to chase trends, squeeze extra pennies, or constrain consumer options, you’re probably doing the wrong thing.
If you're making an unpopular change to chase trends or squeeze out extra profit, it's probably the wrong thing to do.
And when you do have a good idea, the hard part is making it work in reality. In testing, you are both operating in an optimal environment, and the user (you) is a product expert. In production, this is rarely the case. The user could be completely unfamiliar with your product (at the very least, we can assume they haven’t sat through weeks of design meetings and got to know it inside and out), or there may be uncontrollable factors in the environment that you didn’t think to design for. It just might not work that well in real life.
Just as a software engineer can’t assume their laptop mirrors the customer’s production server, you can’t assume your thinking mirrors the user’s. Take feedback – and listen. Don’t remove options people like. And scan carefully for second-order consequences that could at best make your product more frustrating to use, and at worst alienate large parts of your customer base.
