There’s a wonderful piece of software that I use as part of the production process for WB-40 called Descript. It allows me to edit audio through a transcript and also can do clever things like “de-umming” our recordings. But there is one part of the user experience that I am finding increasingly frustrating.

I use the tool once a week. Descript obviously have a release cadence (the regularity of when they issue updates to their software) of at least once per week. The net result is that every damn time I start up the software it tells me it wants to restart to install an update.

Every time I start the app, I wait about 3-4 minutes for it to update itself. A minor but extremely regular inconvenience.

This is a perfect example of where the needs of the development team are not taking into account the user’s needs. Striving for a “better” product is making the product demonstrably worse from a user experience perspective.

This can manifest in other places in other ways. The regularity by which an application is used by a user should factor massively into the way in which a release cadence is designed. Shipping code all the time might be great for the development team wanting to hit metrics, but what about the poor user?

For example, imagine a system like an HR performance review platform provided as a product. It will be used in intensive bursts maybe twice or four times a year. The people developing the platform might well think that the constant release of new incremental improvements week by week is a good idea.

But for any particular user, the net result is that every time they use the system each quarter- or half-year they are confronted by the massed cumulative change of lots of incremental stuff. It’s not like anyone likes using these kinds of systems at the best of times…

Software development is a complex socio-technical process. The means by which software is developed can have a direct impact on the experience for users as much as the functionality that is created by the developers. Yet our exploration of user needs rarely strays outside of the things that are built.

If you really want to understand how your users experience your products, though, the way that you are building them might have more impact than you realise. And probably not in a good way.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.