Projecting human quirks on to software

Modern software is often quirky and hard to use. Users and usability professionals have high expectations, and often product developers blame the technology for a poor experience.

P2P

In the software development industry, we often put the onus on the technology, using a Software-to-Customer model.

But, if, as a developer, you think of the Customer as a person, the Developer as a person, and the Software or delivery mechanism as something that a developer created, then you can drop the middleman and reframe this as a human trade, Person-to-Person, or P2P.

Shifting the blame

This is an important differentiation. When we refer to digital products and services in the third person, we can shift any blame from ourselves, projecting our very human issues onto their cold binary exteriors.

Developer quirkSoftware quirk
I’m under pressure, tired and irrationalIt’s buggy
I’m saving time by cutting cornersIt’s limited
I’m using frameworks to build things quicklyIt’s slow and bloated
I’m working long hours but am well paidIt’s too expensive

If we could see past our blinding egos for a second, we might see that we created this beast. We, or people like us, created the finished product and the frameworks it relies on and the coding languages themselves. We created their capabilities and their limitations and quirks.

Taking ownership

Moving the focus from the software, back to the people who created it can be very empowering. Because if we broke it, then logically we can also fix it.

It can also be quite embarrassing. Many’s the client who has scolded their developer: Stupid developer! Why is it broken?? The inference is that the software is inferior because you are. But the developer is only a cog in a machine and is affected by many other (human) factors too.

Nevertheless, in our P2P relationships, if the person at the other end can’t work with the software that we’ve provided, then we should not be afraid to look them in the eye and say, yes, we broke that and yes we can fix it.

Or maybe, we don’t want to change. If not, it’s still on us.

Breaking the cycle of suffering

Which leads us to human suffering. That old chestnut.

Too often, the person at the other end of the software takes on the role of martyr, blaming themselves for usability issues.

Developer quirkSoftware quirkUser quirk
I’m under pressure, tired and irrationalIt’s buggyI’m exhausted, I’m not smart enough to figure this out
I’m saving time by cutting cornersIt’s limitedI’ll use something else
I’m using frameworks to build things quicklyIt’s slow and bloatedI’ll buy a new phone
I’m working long hours but am well paidIt’s too expensiveI’ll work more hours to afford it

There’s a running theme here. The person suffering at one end is very similar to the person suffering at the other end. And when you factor in that the developers of software are often also the users of it, it all becomes very self-fulfilling.

I think this says a lot about our situation right now, and about our potential. Maybe we feel obliged to maintain the status quo and to keep running on this mad hamster wheel. But ignoring the forces at work won’t bring us happiness, unlike the hamster.

Things could be immensely better than they are right now. We just need to take ownership.

What Web Accessibility is – and what it isn’t

Happy Global Accessibility Awareness Day everyone!

In honour of all the people struggling to do basic things on the internet, let’s define what Web Accessibility is – and what it isn’t.

1. Accessibility is not just a ‘nice-to-have’

Accessibility is not a ‘nice-to-have’ that you can do in ‘phase 2’.

Accessibility is as fundamental to your site being successful as SEO. Your customers need to be able to get from the top of the funnel to the bottom. For that to happen you need to remove any barriers that stand in their way.

That’s Accessibility.

2. Accessibility is not just for ‘disabled’ people

Accessibility is not just for those who are legally deaf or blind, dealing with brain damage or confined to a wheelchair.

Accessibility is also for you as you age, for you when you hurt yourself, for you when you’re having a hectic day, and for you when you’re out and about and using your mobile with all your faculties. Accessibility is not for ‘other people’, it’s for all of us and it’s for you.

That’s Accessibility.

3. Accessibility is not just about HTML codes

Accessibility is not just about slapping some ARIA roles and attributes into your code and running it through a validator.

Accessibility is about showing as much love to retired users running free AT (Assistive Technology) on ageing desktops at the public library, as to those running the latest version of JAWS on the latest version of IE on their brand new tablets. And it’s about realising that those people are real people, like you, and not annoying standards or automated software algorithms.

That’s Accessibility.

4. Accessibility is not just about adding plugins

Accessibility is not about making your users work harder by overloading them with accessibility ‘features’. It’s about you working harder, so your users can consume your product/service/content with minimum effort, before getting on with their lives.

That’s Accessibility.

5. Accessibility is not just other people’s problem

Accessibility is your problem. If you aren’t writing your code yourself, then you need to be voting with your money and your feet for software that is coded responsibly, and goes way beyond feel-good marketing messages.

That’s Accessibility.

 

This is a repost from my LinkedIn account.