The other day, I mulled over the problem of bad user experience resulting in more usage of products.

Half your job as a product manager is not to get excited about rising usage numbers caused by bad UX. Often delivering a great experience means less usage - people get what they came for quickly. Tough to sell as success in a market obsessed with usage minutes.

— Chris Heilmann codepo8@toot.cafe (@codepo8) July 14, 2021

And I followed up with wondering how we could get to a “happy user” metric.

We need a "happy user finished task they came for" metric, but this one is hard to measure as you are 10x more likely to get feedback from people who had a bad experience.

— Chris Heilmann codepo8@toot.cafe (@codepo8) July 14, 2021

When measuring the success of software products, data is king. When I moved from DevRel to program management, my world got a lot more dashboards and charts. I found myself spending more time looking at user feedback. I learned about asking questions to find the real issue that caused dismay in users instead of adding a feature satisfying their request. I started feeling despair looking at the noise to signal ratio you get in feedback channels. And I started to question our razor-sharp focus on numbers and continuous growth.

We love growth and numbers. It is pretty depressing how much we see growth as the only thing that matters. Users, download numbers, sessions, minutes of usage – all have to go up from version to version – or you failed.

This makes sense when you grow and when the funding of your product is dependent on user numbers. It is the main thing that empty products like social platforms have. You need users to get content and engagement. You always need to get more to be able to tell advertisers that you have so and so many users. I remember working on app stores in another company and wanted to bang my head on the table. People measure the success of a store by the number of apps, not by their quality. At one time I met with a company offering to create 500 apps a week for a certain price. That way our app store can look bigger than the others. You’ve seen apps like these: “paint a cat”, “paint a dog”…

The big issue is that our fairytale success stories in software are the fast growing platforms millions of people use. Are you as successful as Facebook? Are you growing as fast as TikTok? Do you have as many active users as MySpace? Oh, wait…

Not all products are there to always grow. Some products are specialised, and you don’t even expect people to use them all the time. Many of the things I work on in the developer tooling space are things you only use when there is a certain problem. The happy path for the user is simple. Open the tool, use it to find the problem to fix, close the tool and forget about it until the next time.

No growth there, but something more important: helpfulness to the user. If the tool does not only allow you to track down a problem, but also gives you valid advice how to fix it, even better. I love when a tool educates me about a problem. I am happier, and I even learned how to avoid the issue in the future. Which means I don’t need to use the tool any time soon any longer.

As the tool creator, who has to show continuous growth, this is a problem. The only way to increase usage numbers is to ensure the problem happens more often. And that is beyond the reach of the tool creator.

The question then is, how do you measure the success of those? And even more interesting – how do you defend a drop in numbers when you fixed an issue?

The other day we encountered the issue that a highly used product also got a lot of feedback. Negative feedback, telling us that people don’t know what it is and why it is there and that they want to get rid of it. This is something you want to dive into. Unhappy user feedback is high priority, especially when your product confuses the users. People put effort in to tell you about the problem, you should reward them for that.

As it turns out, there was a simple way to accidentally hit the keyboard shortcut to open the product. For power users keyboard shortcuts are amazing. That’s why developer focused tools have dozens of them. For normal folk, they can appear as witchcraft.

The solution was to add an extra step the first time the keyboard shortcut happens. We show information telling you what will happen now, what product you will open and if that is what you wanted. We offer to never to do that again for people who triggered it by accident and never to show the message again for others.

We didn’t come up with this super clever way of dealing with this ourselves. We did user research and tested various ways to work around the problem.

This will cause a dip in our usage numbers for sure, but it also means that all we lose is accidental, unhappy users. Which is great. But what if I worked elsewhere and the next bonus or funding for my product is dependent on more users each month?

The interesting thing here is that we have proof that those users were not happy getting there. So we can point to the feedback data and show the drop off in negative feedback as a win of happy users. We can only do that as we have an easy to reach and use feedback mechanism in our tool. And this is where far too many products fail, in my book. If you don’t ask your users how they like what you do and allow them to complain about problems, you can’t find issues like these.

We need a new metric of happy users. But I am still at a loss how to get to that one. One thing I know though is that chasing more users or interactions for the sake of growth doesn’t make better products.

A few days ago I posted a graph I found some time ago that jokingly explained the benefits of subtitles in movies and tweeted about it.

Good #a11y features are beneficial for lots of people. pic.twitter.com/2RMnTzseey

— Chris Heilmann codepo8@toot.cafe (@codepo8) June 28, 2021

The tweet went wild and so far has 35 answers, 290 retweets, 1,500 likes and 150,000 impressions. I love that the answers are all about people’s experiences with subtitles and why they choose to turn them on. These range from selfish reasons like being able to only pay half attention to the movie, to people trying to get linguistic nuances and utterly sweet things like being able to watch something without waking up a baby.

Personally, I am a huge fan of captions and subtitles. First of all, I learned English using them. Growing up in Germany, TV is dubbed and you normally don’t get the option to have subtitles. Growing up in the 80s also meant that there was no interactive TV, so all you got was what was on offer. Weirdly enough, one show that wasn’t dubbed was Monty Python’s Flying Circus, which instead came with German subtitles. This was great, as I could listen to the original audio and learn the meaning at the same time. Even more importantly, I learned about pronunciation of the words, not only their meaning. We learn the phonetics of a language by repetition and if you get a native speaker as the source, that’s an excellent start.

As this was a state channel (all of them were back then) they offered subtitles as an accessibility feature, and it was paid for by the taxes we pay to get access to TV and radio. They were meant to help people who are hard of hearing but were a great way for me to get started learning my first foreign language.

And this is what accessibility features should be in my book: necessary for some, but also beneficial to all. Now, with captions and subtitles, we have a problem. Good ones are expensive, and they seem to be a massive overhead for videos we provide.

However, we also live in amazing times where video platforms create transcripts of videos for us. On YouTube, for example, you only need to define the language of the video and some machine learning product will create a transcript for you. Even when you don’t add alternative text to images, many platforms like Twitter and Facebook will create some automatically generated description added as an “image may contain:” alt attribute.

The problem with those is that they are often full of misunderstandings and not necessarily well structured. The good news is though that most platforms also allow you to export automatically generated transcripts and edit them. Most video hosting platforms also have in-built editors that allow you to verify and tweak the transcript to fix these issues. It is still quite some work to do that, but really worth the effort.

Using these features has a few benefits.

• You can add the transcript not only to the video player but also as a text to the document. This allows visitors to search the video and find what they are looking for. As most video players allow you to jump to a certain time stamp you can link different keywords to certain times and thus allow people to only watch what they need rather than having to scrub through or watch the whole video.
• Some video players even offer a transcript search that makes the video as searchable as an text document.
• Having a transcript also allows people to use their browsers to translate it to their language and thus at least get an idea what you are talking about.
• Search engines can index the transcript and make your web product show up in search results even when people didn’t search for videos.

This kind of thinking is what I try to apply to any accessibility work that I do. We need to make our work accessible anyways, so we may as well try to find ways to make everybody benefit from it. Simpler language, easier interfaces, not overloading the user with lots of information or not using lots of animation means all our visitors have a quicker way to consume what we offer. Accessibility to me means hard-core usability. You make it work for extreme cases and thus make it better for everybody. And by thinking like that, accessibility work isn’t a chore or something we need to do to be legally compliant, but it is a quality feature of our products.

If you want to learn more about how I approach accessibility and how you can test for and fix the most obvious issues using only the browser you already have, you can check out my Tools for Improving Product Accessibility class on Skillshare.

Last week my former colleague Si Jobling interviewed me for his Make life work podcast about working from home, in different time zones and how to optimise your workflow.

This also tied in nicely with Tools and Tips to Optimize Your Workflow as a Developer class and I shared how this one got prepared and recorded.

It was great fun talking to Si again and catching up on the parts where our career crossed – working for Yahoo UK.

I got a cold email asking me to write a blog post about “Seven things you can’t do in React” for exposure on a “leading technology blog”. I sent them my proposal, wish me luck…

1. Boil the perfect egg
2. Connect to your inner child
3. Reach that itchy part on your back
4. Compose a sonnet to woo the ladies
5. Make your dad proud for once
6. Worship Imhotep and bask in his glory
7. Appreciate the Song Thrush’s mating cry

Often you will be part of meetings where people show demos of what your product could look like in the future. These are brain-storming, visionary meetings that can have great outcomes. The idea is to not think in boundaries but in benefits for your users and customers. The longer you work in a certain company and the higher you climb on the career ladder, the more of these meetings will be yours to attend and to organise. I am currently a Principal Program Manager. This means my gaze should be a few years down the line. I’m expected to lead the company to a bright future and anticipate needs of future customers.

This is great. It is wonderful when your employer realises that your experience is an asset. Even better when the company expects your pace of work to slow down as you get older and you’re not supposed to “hustle” but reflect and guide instead.

But there is one problem.

Every inspirational, blue-sky, brainstorming meeting or demo session has a person that keeps disrupting the flow. A battle-hardened, highly experienced developer with lots of memories of how things failed in the past. A person who a lot of people look up to and whose input counts as important. The even bigger problem is that this grumpy old person lives inside my head.

When you’ve been working for a long time in a certain market you accumulated a lot of information. You learn things at first, you take some on as positive and discard others. You see things fail, and you often don’t see any effort to analyse why they failed. Then you blame the part of the failed project you controlled – the technology. And this can lead to a bias where you discard anything remotely similar as failure in the making.

It is a problem when your knowledge and experience becomes a barrier. You know what worked in the past and of course this is the thing to do. All these newfangled things seem flaky and overly complex. They also expect users to embrace technology in a much faster pace than you remember them to do. Hot new interface ideas or content strategies feel like things you heard many times and never added up to any success.

It is important to understand that this is a destructive way of thinking. That’s why I keep telling the old man in my head to shut up and listen instead.

There are a few things that help me with that.

• We tend to see the past in extremes. We either remember good experiences as excellent or bad experiences as abysmal. We even block quite a few out and the longer in the past something was the more unreliable our feeling about it is.
• I’ve seen technology change over and over again. I’ve seen things succeed I considered pointless and things I was all for fail to gain any public interest.
• I’ve often been part of experimental technologies that were too early in the process. Computers weren’t fast enough, people didn’t have the devices or connectivity needed. And just when I discarded them as a learning experience the market moved on and – with a few tweaks – they became a success.
• I’ve learned from failures. I accumulated some knowledge on the way and learned what not to do. Who am I to not allow younger colleagues to get the same insights?
• We live in a wasteful market. A huge part of our market is a series of short-term successes that fade into oblivion to be replaced by the next hyped product. This appears wasteful, but for years I realised it is not worth complaining about this. It is what it is – burning money is part of an ever growing economy. This can soon reach a tipping point, but that is not a reason to be stingy upfront. This isn’t only about money, it is also about code, work time and short-lived products. Some will fail, and that is OK. You can’t win it all.

It is tough to let go and start thinking in a “what if not everything is shit” way. It is fun though to plan ahead and describe a future product your users deserve. A product that focuses on outcome and functionality, unencumbered by your experiences. It is OK to dream without your experiences being a party pooper. A vision that inspires younger people to get creative and have their own experiences. It is their job to deliver this vision, after all. They will be a lot better at finding technical solutions that get them there than you would. As the solutions you cherish and love worked for you, but may not be as useful as you think they are now.

I’m happy to muzzle the grumpy old man in my head, and I hope that will prevent the people who work with me to ever having to deal with him.