UX Series 04: Software as a Product and Visceral Behavior
Apr 18, 2017
Picture a checkout form for an ecommerce site. You may picture an elegant, bright, simple form. Each field is consistently spaced apart, quick to correct any mistakes you may type. And, while not beautiful, it presents itself with a certain air of professionalism. You would feel no worries entering your credit card number in the next field.
Now, how about this?
Apple’s website may have been a sight of elegance and ingenuity in the late 1990s, but after twenty years of progress, this only leaves a first impression of being the work of an amateur, somebody not fit to handle the most private of my personal information.
First impressions matter.
Software as a Product
When we think of a product oriented business, we spend a good deal of time imagining colorful and technologically stunning things to buy. But this is only a fraction of reality. Software as a service is as much of a product as your new pair of shoes.
The SDKs, libraries, and frameworks that we build are, at the end of the day, digital tools akin to a hammer or a screwdriver. If a hammer gives off the appearance of being flimsy, regardless of actual performance, it won’t sell well. If the wood handle looks brittle, we may fear riddling our hands with splinters. With a framework, we will equally judge pattern and language choice, elegance of provided examples, as well as the thoroughness of documentation.
These judgements can happen in just a few instants. A quick glance at a repository’s README file and the number of issues can make all of the difference. Just recently, a coworker of mine lamented on his first introduction to Pearl after over a decade. Just a few moments of trying to set up the language was enough to lose this user, regardless of how useful a language it may be.
Visceral behavior can best be described as our instinctual behavior. It is our fight and flight response, feelings of fear, nostalgia, and more. We struggle to control them, but they are easily guided with good design choices.
activeElement, and more. Upon first examination, this wealth of choice is overwhelming, stressful to learn, and difficult to keep straight when dealing with a decade’s worth of browser specifications. The visceral response to these problems is often flight. The user is too overwhelmed to continue and searches for a replacement.
In contrast, jQuery handles these issues quite well, making use of a pattern called the Facade Pattern, “…an object that provides a simplified interface to a larger body of code, such as a class library”. It is perfect for situations in which we are presented with a wealth of choice to achieve similar goals. jQuery uses this pattern flawlessly by providing most of the above functionality with just a single line of code.
When all else fails, hand your codebase over to a developer who is unfamiliar with your tool and see what they can build. This was finally drilled into my head when an old client stated that they were too afraid to jump into some data visualization code I wrote for them. I would continue to receive pleas for help weeks after our agency left the project. I failed to consider how new hires for their business would even begin to start working with the codebase. Despite being perfectly functional, it was too verbose and abstract to be understood without training, making it useless.
While the end result could be misconstrued as an opportunity to secure future work, I imagine there was a great deal of buyer’s remorse after the contract ended. If an engineer’s first response to a library is fear, enthusiasm for a project plummets, tanking productivity. If you’re a consultancy, this will negatively effect your reputation and chance for repeat business. If you sell licenses to your SDKs, expect every engineer to attempt to migrate off of your system.