The Forgotten Key to Great Software: Human Touch (and Special Goggles)

Cast your mind back to 2006. RHCP’s Stadium Arcadium, Yeah Yeah Yeahs’ Show Your Bones, and The Killers’ Sam’s Town were grooving through your FM stereo. The second Pirates of the Caribbean movie was netting blockbuster sales (sails?), as the book Eat, Pray, Love was encouraging us all to take chances, live a little louder, and drink white wine at 10am (in a fun way, not in an alcoholic sort of way).

The iPod had been dominating the music world for five full years, and had a near-monopoly on the listening-device industry. But a new foe approached. One that promised to take the MP3 fight straight to those turtleneck-wearing hipsters in Cupertino. In November of 2006 the Microsoft Zune, a.k.a. the iPod killer, was unveiled.

On paper the two devices looked incredibly similar. In fact the Zune had a leg up in some areas, with it’s larger screen and built-in FM tuner. A battle of two tech giants, both yearning to get their device into your pocket, you’d think sales figures would be neck & neck. Yet after ~2 years of production the Zunefinally reached 2 million in total sales, while 3.53 million iPods were being sold every single month.

Why the substantial mismatch in sales? Sure the iPod was introduced 5 years earlier and had momentum, but that doesn’t fully explain the wildly different results.

I’d ague it’s because the iPod was built around it’s users, from it’s conception, to every design choice made, to every line of code written and hardware component created.

The iPod seemed intuitive, cool, and easy to use. It made sense. It felt good. That scroll wheel was smooth yet tactile as your finger raced around the rim. The menus & UX let you jump quickly to the perfect song, while also allowing you to meander through your catalog, looking for inspiration. Simple games like Texas Hold ’Em and that brick breaking game, though not cutting edge in their gameplay or graphics, gave the user something to concentrate on as they grooved to their favorite songs.

Even though the Zune stood toe-to-toe technically with the iPod, it lacked that human-centered touch. Instead of the easy-to-master scroll wheel, the Zune stuck with traditional directional buttons, causing you to “click, click, click, click…” through selection after selection until you found the right jam. The device was larger, heavier, and generally felt clunkier than the sleek iPod. The respective stores (iTunes vs. Zune Store) offered very different user experiences and ease of integration with their products.

On paper the two devices were incredibly similar, and if feature lists were the only criteria of a well-received piece of tech then Apple and Microsoft would’ve posted similar sales. But Apple built a device entirely around it’s users, and that made all the difference.

Software Can Fulfill All Requirements, and Still Be a Disaster

We’ve all had those sprint reviews, where devs unveil the feature they worked an unholy number of hours on, putting their blood, sweat, and tears into making sure reality perfectly matches each requirements specification, only to be bombarded with questions from other stakeholders during the demo.

• “Why do I have to click two buttons to reach this page?”
• “I can’t find the Submit button, where is it?”
• “Why do I have to toggle back and forth between pages? Can’t I just see all this info on one page?”

Worse still is when the whiz-bang feature that‘s been clamored for finally gets deployed to production, and no one touches it for months on end. When asked, users respond with statements like:

• “Oh that? Yeah I found it easier to just put all my comments in Notepad”
• “I tried that approach, but it just seemed so complicated. Whereas the old way I’m familiar with.”
• “Wait, you can do that? I never knew!”

As engineers, we like building cool things. Therefore we tend to focus exclusively on the engineering & technical aspects of our software. How robust is the design? How clean is the code? How scalable and maintainable is the system? Engineers should care about these dimensions, and fight for them if need be, but they’re only half the battle when creating a great system.

When using an iPod, 12-year old me wasn’t appreciating the masterful architecture that allowed each piece of the system to interface flawlessly with the greater whole, or the brilliant algorithms that saved heaps of space and time during repetitive calculations. I liked the fact that I could buy my favorite Rise Against album (remember them?) on iTunes, transfer it onto the iPod with ease, and within a few clicks listen to my new tunes wherever I wanted to. As an end user I didn’t care about the technical aspects of the system, I cared about the experience I had when using the system.

UX, not UI

So how do you build a great user experience? The old-school approach was to hire a couple designers, send them a list of fields & elements to be displayed on each screen, and have interns write CSS/GUI code to look like the resulting mockups. UI done, developers could now design the rest of the system around what they deemed important/interesting.

While good interface design is critical, it only scratches the layer of the entire experience. Most software goes beyond a series of screens. It’s dynamic; calculating, reacting, and sometimes being shaped by users’ input, in an intricate dance of man & machine. Good user interfaces don’t mean much if the user has to wait 45 seconds for a central page to load, or is redirected to unexpected, disjointed places as they flow through the system.

The responsibility of creating a great user experience can’t be entirely shouldered by designers. Every member of the team must keep this goal in mind, from the product owner who selects the right features to prioritize (not necessarily the most popular), to testers who, on top of teasing out crashes, bring up feelings of ambiguity or annoyance felt when using the system, to developers, who write every line of code with the intention of helping users achieve their goals or have an experience.

User Goggles

Stacks of books, papers, and articles have been written about the art of making a great user experience, and I recommend that all software professionals take at least a cursory dive into this field. But you don’t need a degree in Human Computer Interaction to create software that users love. Instead you just need the human touch, a.k.a. empathy, a.k.a. walking in another’s shoes, a.k.a user goggles.

The D.A.R.E., S.A.A.D., and P.A.D.B.T.O.B.A.T.G.W.J.D.T.W.O.K (People Against Drinking Before Twenty-One But After That Go Wild Just Don’t Touch Weed O.K.) programs in high schools relish the chance to break out their Drunk Goggles at school assemblies. These goggles simulate the visual, balance, & coordination impairment caused by a few too many White Russians, leading their wearer to stumble around the room like a drunkard on a Friday night. The person isn’t actually drunk, they’re probably stone sober, but they interface with the world as if they were a heavy drinker.

When giving fresh code a first run, I like to imagine putting on my “user goggles”. Although I’ve spent anywhere from hours to months in the intricate details of this system, I forget all that and pretend that I’m a first time user, trying to accomplish a specific task. It’s tough, and sometimes it feels like another distraction from writing useful code…

But as I’m stumbling through my task, I notice things:

• The Submit button’s on the left. That’s weird. I’d expect it to be on the right.
• I clicked Continue, is it doing anything? Hello?
• I feel like all my time is spent toggling between these tabs. Back and forth. Back and forth. Ugh.
• I keep submitting this form, and each time the next page takes at least 10 seconds to load. I’ve actually started checking my phone each time I click Submit, that’s how bad it is.

I write down all these little thoughts. These criticisms, annoyances, and tics. My users would think the exact same thoughts if they loaded my system for the first time, current state. I use these thoughts to fuel a second-pass at the code, to get in front if this criticism. It’s much easier to change the system now, then 4 months later when most of the dev team’s moved on and the code base is 5,000 lines ticker.

Every team member should practice some form of this exercise.

• While writing user stories, Product Owners should close their eyes and say “As a user, what do I actually want to do? What do I need to do? What’s the purpose of me loading this system? Does this user story help me execute my purpose for being here?”
• While trying new features, Testers should load the home page and say “I’m Jane Soandso. I loaded somerandomsystem.com because I want to do ___. Let’s see if I can figure out how to get this done quickly, easily, and painlessly”

Write down every hiccup, concern, or negative thought, and fix the root cause if possible. Remember: if you notice something, then you can almost guarantee that your users will notice the same thing, and their experience will be hampered as a result.

Conclusion

What’s presented here isn’t new (walk a mile in someone else’s shoes, anyone?), but user empathy’s sorely underutilized in software development. Development team members often see software in a very specific light. We’re creating a piece of art. A massive collection of code, interfaces, ideas, and test plans assembled by highly-skilled professionals over the course of months (or years). But the people who use this software (and directly/indirectly give us money for rent & Tostitos) see our creation as a tool, to be used for certain tasks or experiences, and nothing more. By simulating the mindset of our users mid-work, we can constantly readjust our creation to better fit their needs, lives, wants, hates, and secret, innermost desires (that last one’s tricky, and may require some imagination). By wearing our user goggles mid-development we can later release our software with confidence, knowing it’ll achieve it’s ultimate purpose: to be used & loved by actual people in the real-world.