4 Keys to Building Software With Soul

User experience matters. Great functionality wrapped in a poor experience is useless.

When Steve Jobs passed away, fans of Apple and all of its offerings reacted as though they had lost a member of their own family. You could not turn on the news or glance at social media without seeing countless public displays of mourning. The interesting thing though, is the overwhelming majority of these people whose despair was so real and so evident had never met the man.

Why did they care so much?

Why did everyone care so much about a man that they had never met? Corollary to that, why do you see many less Apple bumper stickers now than you did ten years ago? In answering that, I thoroughly recommend watching some of the documentaries out there on Netflix and otherwise regarding Steve Jobs. Man in the Machine is quite good, but there are others and all are worth watching. One thing you’ll notice as you dig into the topic are opinions that Steve Jobs was not as beloved amongst those that knew him closely as he was amongst the Apple fanbase. There are plenty of stories out there. I don’t want to recap things that I wasn’t present for second-hand, as plenty of other people have.

But why society cry for this man’s death?

What Apple created under his watch had so much soul and so much elegance to it that people formed what they felt were tangible bonds with the products that they paid top dollar for. He formed these bonds by achieving a level of understanding of the art of user experience that I’m not even sure Don Norman — author of the Design of Everyday Things which is widely considered the user experience bible — can claim. Unboxing an iPod felt like you were part of a special club. The devices just seemed to work, and always seemed to somehow know what you were trying to do, as if the designers had thought of every single person and every single possibility.

We all use software. Whether it’s the dashboard on your car, the email app on your phone, or the enterprise system you use at work, software is everywhere. The vast majority of software is clunky and hard to use, but very functional. Very rarely will you encounter a product that works so well that it inspires true positive emotion. The fact is, people want the software to get them where they’re going without too much thought or effort, and if you boil everything down to that simple fact, the decisions on how to structure the software start making themselves.

(1) Users Aren’t to Blame

User blaming is effectively blaming the victim of bad design. If a user does something that you consider unintelligent, it’s important to remember that the user should not be expected to be an expert and should not be expected to be a software engineer. Software is a tool, it’s made to improve the quality of life in some way, shape, or form. It’s not meant to be an academic experience – users should not require PHDs in your product.

Software engineers are notorious for blaming the user. In the past, I was the worst offender of it. “Well why did they do that?” I would lament.

They did that because your software didn’t stop them or warn them of the consequences. It’s not something to get defensive about, it’s just something to fix. Bad design should be treated like any other software defect. That starts with the admission that if people can’t figure out how to appropriately use your software, that is your fault. Having good documentation is helpful, but what’s much better is a self-documenting user interface that doesn’t require the user to take so many extra minutes reading documentation. It’s important to have good, detailed documentation, as long as you understand that nobody really wants to read it. It’s just the best option they have for solving their current problem – similar to the manual that arrives with your new toaster.

Don Norman frequently tells a story regarding 3 Mile Island. The idea is that the control room in the nuclear facility was about as complicated as it could possibly be. When it’s so difficult to quickly gather critical information from your user interface, it’s surprising that a disaster hadn’t happened sooner. All of the information can be readily available, but it has to be in a format that a human being could reasonably be expected to operate with. Luckily, when most of us are designing interfaces there aren’t lives on the line, but if you design your product with the mindset that usability and approachability is life-and-death then the improved experience will resonate with your users.

(2) Reduce, Reuse, Recycle

The main problem with the vast majority of software packages is the learning curve. This makes complete sense, as those developing the product work with it every day and therefore build up strong muscle memory regarding the basic flow and operations within. In this sense, it’s important to remember that every person using your product will have used it for the first time at one point. As the old saying goes, you most certainly do not get a second chance at a first impression.

Consistency in experience is key. A product developed without standards will inevitably become very hard to use. It’s not an if, it’s a when. The most important standard that can be imposed is limiting the overall number of design elements present in the product. One person or small team should be responsible for the design of these overarching elements, and those building the product should be restricted to using only those elements. Engineers should be encouraged to make suggestions or requests, but should never make executive choices without approval. It’s a challenge to do this without stifling creativity, however if done correctly a balance of innovation and usability can be struck.

Too many software products with great functionality suffer because there is no consistency from area to area. This is typical when every engineer is making differing decisions about how to solve the similar problems. Taking an example software product, one form may have tabs across the top and buttons on the bottom left, while another may have tabs down the left and buttons across the top. Differing fonts, colors, input sizes, behaviors of buttons, etc. All of this makes for a very disjointed user experience.

At work (Deacom), we have a very controlled set of objects. Every entry field in the system is the same size and has the same behavior. Every function, from formulation to order entry, has the same flow. Every editing form has the same standard buttons and functionality — same with every on-screen report. Even though we have almost 1,000 forms / screens in the system, users (internal and external) know what to expect no matter where they land in the system and developers know what to expect when they’re building it.

(3) Key Performance Indicators (KPIs)

Value needs to be placed on every single detail of a product in order to drive the type of experience that can take the success of a product to the next level. It’s easy to cut costs on things like Research & Development and Quality Assurance up front, but when those decisions are made, the people making those decisions are setting a ceiling for success. If you want to reach anything close to iPod / iPhone levels of adoration, however, a higher level of effort, engagement, and yes — cost, is required. Take some time to use your product. Really use it, and ask yourself measurable questions every step of the way. Additionally, put your product in front of some people who have never used it and ask them the same questions. The answers to these questions will form your usability KPIs.

Some of the questions I ask are:

  • How many interactions did that process take to navigate?
  • How many seconds did it take to load or execute?
  • What percentage of the interactive objects present can you describe the purpose of?
  • Scale of 1 to 10 — Does this look objectively good?

Take the time to ask these and other, more tailored questions of your product while also asking them of other products you use. Look for industry trends. Figure out what you like and don’t like in everything you use. Use those measurements and observations to determine clear goals, on a monthly or quarterly basis, to iterate towards a better product.

(4) Encourage Feedback

With any service, and software is no different, customer feedback should be encouraged. Organizations that repress or don’t prioritize proper feedback loops with their users will fail to recognize critical shortcomings and ultimately be surpassed by their competition. We live in a Yelp day and age, where reputations and stories are available at a keystroke. It’s critical to address negative customer experiences before they end up as negative stories that can ruin your reputation.

Responding to feedback can be difficult because it doesn’t always fit in with where the product is currently going; however, it’s important to understand what the customer is trying to do something that is important to them and to keep an open mind regarding potential solutions to the problem. Many of the best ideas that arise when designing a product originate from grass roots customer experience stories rather than traditional R&D.

If the feedback is a simple misunderstanding, the ability to communicate this clearly back to the user is key. It can’t stop there, however. If a customer misunderstood how to use the product, there is a root cause in the design of the product that must be addressed, otherwise this flaw will continue to spawn additional bad feedback in the future. Bad feedback that can easily be considered sunk labor cost and sunk opportunity cost alike.

I’m not sure if or when a product will captivate people the way the iOS devices in the 2000s did. Tesla has had a pretty strong following at times in recent years. I’m personally a huge fan of some of the things happening at Microsoft currently under Satya Nadella. Who knows? When the audience of a product is so bought in that they openly mourn when its creator is gone, that’s something incredibly special. It may never happen in the same way again.