I have been building software since I was 10. I started making games in QBasic and loved every part of the process, from architecting my database and logic structures, to designing my user interfaces. My first applications were text-based MUD (multi-user dungeons) where users would wander around rooms described textually with only text controls. It was like an interactive choose-your-own-adventure book right on your screen. I enjoyed experimenting with pixel art and text transformations to give the appearance of animation.
Ten years later I had moved past games into making business applications in the Microsoft universe. I wanted to organize the troves of the data and information that businesses captured and locked away in legacy databases. As a financial and HR compliance auditor who was often asking questions to reluctant, over-worked managers, I realized that many of the answers I looked for were already there in the data. So I made it my goal to extract that data into a single user interface that could be shared with all the decision-makers. I called that project “Happy President”.
There was a distinct transformation that happened between these two stages of my life. I discovered the usefulness of software, and made a decision: I wanted to build useful software. Thought I took pride in building flexible database models, clean code classes, and efficient user interfaces, I was most committed to the benefits of the software itself. I stated my goals right in the name: “Happy President”. The president was happy, not because he loved clicking around my clever user interface, but because he was able to see dimensions of his business he never realized before. As a financial auditor, it was my goal to find and deter theft, and my software helped reveal patterns that could potentially save my employer hundreds of thousands of dollars per year.
Over the years I have worked with and employed thousands of workers from a diverse set of backgrounds in the software industry. At the ground level in the office when we are preparing the software, attitudes are always practical. Some of us take more pride in our work than others, and I often see the rise of excitement when difficult technical or design challenges are solved. But at the end of the day, we all seem to know that we are building a piece of software to achieve a human objective. However, something often happens when the product is publicized: the creation itself is celebrated, and the objective it achieves forgotten.
I do not see this everywhere, but I see its effects in most of the popular apps and websites. Some might say it is the difference between craftsmanship and pragmatism. A Rolls Royce is a wonder of craftsmanship, and every detail reveals the ingenuity of the creator and his creation. A building designed by a world-renowned architect has value far beyond its ability to provide shelter and space for its occupants. These are examples of craftsmanship creating value that inspires and enriches the communities that produce and consume them. But will software ever produce this kind of value?
I do not think it will. Software is a commodity. It only has value insofar as it helps users make decisions and achieve objectives. Software is, for all intents and purposes, purely a practical creation. And as such, when I find myself working with teams of people gushing over this and that app, feature, or a UI, I cannot help but think they have missed the point. We do not build things that people treasure or covet. Our software does not convey status. Software in all its forms, is purely functional. And highly disposable. There is both open source and proprietary software to address virtually every single human and organizational need.
We build pipes that facilitate the achievement of human objectives. That is what we do as software creators. I suppose we could chalk it up to marketing and hype, but I think it honestly goes deeper than that. How many apps employ are “gamified”? Perhaps this gimmick worked 10 years ago, but who really cares about arbitrary game-like points given in a business productivity app? Why does Trello still insist on selling “power-ups” like I am Super Mario. Has their customer polling really revealed that gamification engages their customer base enough to justify the investment? G
In this blog titled Is Gamification the Only Way for Apps to Survive? (WayBack snapshot) the author opens with the following:
With more and more mobile apps conquering the market, it becomes harder for app developers to stand out among competitors. Nowadays, people, especially millennials and generation Z, tend to get bored quite easily. Therefore, only something exciting and challenging can keep them constantly engaged.
This sounds like the strategy of a drug dealer, rather than a software developer. I understand that there are large, important categories of software where this strategy serves a purpose. At Prospus, we have built and integrated many such gaming mechanisms into client sites and apps. However, we have removed many more at great cost to the client because they failed to impact the success of the app. But it seems that all clients nowadays want badges, points, and level-ups built into their apps. Remember, gamification is complex and costly to not only ideate, architect, and integrate, but also to measure, assess, and analyze. It requires continuous automated and human monitoring to see if it is impacting user engagement levels. And if it is not, then it is getting in the way and likely causing disengagement. And detaching a gaming system if it fails, is also costly and potentially disruptive, depending on its depth of integration.
I have a hypothesis: People do not like using software insofar as it helps them achieve their objectives.
If those user objectives are distraction, titillation, or entertainment, then gamify away. But if the user objectives are practical, then steer away from it. And gamification is not the only example of developers forgetting that they are building pipes and not works of art. Gratuitous user interfaces with an excess of animations, colors, and white space also distract from the goal. Every extra button or layer of navigation — no matter how cute — adds to the overall decision fatigue of the user. And every new piece of information and color contributes to the user’s overall decision fatigue. Even aesthetic choices can create new information an user has to process. Every time we add a logo, we contribute to that overall fatigue.
I propose the Utilitarian Model of Software Development. It applies to practical software, and it has one principle: be useful, and nothing more.
If we build out practical software solutions with this one principle in mind, then our users will tolerate it and we should see more success. But the KPI we aspire to is tolerance, not excitement. We do not seek to engage without delivering value; that will lead to intolerance over time because it eats away at the energy the user has allotted to the solution. If an user finds that 10% of their collective energy is going toward accumulating badges rather than achieving their objectives, how will they react when they finally address it? As users always do: intolerantly.
