Defuse your landmines… before it is too late

Anyone involved with development, support – heck even usage – of software knows that there are always little “gotchas” that you learn to avoid. We should eject thumb drives before removing them. Don’t delete your System or Windows directory. Or the dreaded “Saving… Don’t power off your console” message.

Some of these make sense or are pretty obvious. Also, there’s only so much you can do to prevent a user from shooting themselves in the foot. It is not feasible – at least from a cost/benefit standpoint – to design a game console that is capable of gracefully recovering your save if kill the power mid-flight, just to cite one example.

But, there are lots of other scenarios where there is much to be lost if things go bad. As totally pissed as I would be if my Forza save went “poof,” I believe I’d still live. If I lose all of my family pictures from the past decade because of a bug or a rare caveat, that’s a totally different story.

“Hello. My name is Chris and I’m a landmine denier.”

Admit it: You know your software has these types of problems. There are areas where we can reasonably expect users to tread, but we do not put up the proper fencing. Things where it’s not a matter of if it will happen – it’s a matter of when. In a way, I shouldn’t complain. It’s crap like this that keeps me employed.

That said, I view my job is to make myself unemployed. My software should be so simple, so robust, so intuitive that you don’t need a geek like me to deploy, maintain, or troubleshoot it… or at least fewer geeks like me :) [ I’ll let you in on a little secret. We geeks would rather be solving diffrent, more interesting problems, anyway.]

Landmines: The Home Version

I’ll offer up a non-tech example of this. We’ve lived in our current house for over 2 years. Thanks to our <sarcasm>lovely HOA</sarcasm>, our trash cans can’t be left by the alley. So, we’ve kept them on one side of the driveway as a “solution.” Simple enough and we meet the letter of the law to keep the HOA police off our back.

Because of this, parking a car on that side of the garage required pretty precise driving – both coming and going. I knew that some day, likely when we were in a hurry, one of us was going to get it wrong. Put the car into the wall of the garage, run over the trash cans, whatever.

But, I knew the caveat. I had “documented” the workaround: Just don’t run into the garage. SImple, right?

Did I put any effort into proper solution? Absolutely! I thought about digging out a space on the other side of the driveway, install some bricks (we have a stack taking up room in the garage, anyway), and park the cans over there. That would leave the driveway 100% clear.

OK… But did I do anything about it? Well, not really. I “didn’t have time.” There were other, more important things going on.

That said, I did finally manage to find time a couple of weekends ago… only after the side view mirror was ripped off my wife’s car. Amazing how things like that suddenly change our priorities (more on this later).

Rear View Mirror Damage 2 (Not actually my mirror, but you get the point…)

Now, not only did I install the bricks – which I should have done months ago, back when it wasn’t ~100 degrees outside – but I had to drop about $200 in parts to replace the mirror.

Bringing it Back to Tech

We all know of – or even create and support – software that has similar landmines in it. Sure, we can train people to step around these landmines. While the audience is small, this is manageable.

What happens when your product is the wonderful success you want it to be? Does a model that requires special insider info or meticulous attention to details in documentation bode for a great experience in the field?

In my trash can situration, I thought I had it all under control. Things went well for a long time. So long, in fact, that I convinced myself that implementing a proper fix wasn’t a priority. “Nothing has blown up so far. I probably don’t need to dig up the yard, after all.”

But, as I was picking up pieces of broken mirror from the driveway, I kicked myself for not acting sooner. Moreover, I had to rearrange my weekend to complete the work in a couple of days, whereas I could have taken more time (and likely done a better job) had I started earlier and paced myself.

Think back in your career and I am sure you can find examples of this in your product’s history. A major customer hits a critical issue, despite it being “well known” or even documented, which causes an all-hands-on-deck situation. New feature development grinds to a halt… and we were already behind on new features, because we’re human and we all suck at estimation.

“A stitch in time…,” “An ounce of prevention…”, etc. Yes, they’re all cliché, but that doesn’t make them any less true.

The point is: You can bury your skeletons before they are found or while a customer is beating you over the head with a femur. You make the call!


On the Importance of Requirements and Stakeholders

Not only am I curmudgeon when it comes to Supportability; I also nitpick about things in meatspace :)

Take this for example:


This is the ice maker in one of our break rooms. Let’s take a look at how we operate this thing:

  1. The user flips a switch (or two) to select ice, water, or both
  2. The user presses the button, which dispenses water and/or ice, depending on the selections in Step 1

Seems pretty straightforward, right? What’s wrong with this design, you ask? Here are a couple of things, for starters:

  1. The operation is sub-optimal.
    1. Say I wanted ice, but not water. But, the person who used the machine before me just wanted water.
      1. Side rant: Getting just water from this machine is silly, because we have a dedicated water machine about 3 feet away. Despite this, I find the ice maker in this state quite often.
    2. Now, I have to perform three operations to get what I want:
      1. Switch water to “off.”
      2. Switch ice to “on.”
      3. Press button (this one is common to all operations; no getting away from that).
  2. It does not allow for differing ratios of ice to water. Once I push that button, ice and/or water dumps out at whatever rate the machine wants.
  3. If the user is not paying attention, they can get something other than what they wanted.
    1. Say they pour a soda into a cup, then they just press that button. How good will their user experience be when both ice and water come out? Great if you like your soda watered down, but neigh impossible to fix once you push that button.

Bringing this back to coding and Agile, this is a prime example of issues I see all the time in software design:

  1. Improper requirements gathering
  2. Engineering implementing what was spec’d, despite the fact that a better solution might exist as a slightly higher cost
  3. Lack of stakeholder input

Let’s break each of these down.

Improper Requirements Gathering

I can envision the genesis of this feature. It’s an ice machine, so it likely had the single “Push” button for its sole end-user function: gimme some ice!

Then, someone came up with an enhancement:

User: “Could I get both ice and water… at the same time, from the same machine?”

Product Owner: “Hey, that’s a nice idea. I will run this by engineering.”

Here’s where the problem starts. The Product Owner simply took the requirement as the customer stated it. They let the customer design the solution to their own problem… which, with all due respect to our customers, may not be the best plan of attack.

Any feature exists to address a problem/need/desire. A good Product Owner would not gather requirements from the customer by simply parroting the customer’s proposed solution. Rather, they would ask “the question behind the question.”

Asking “the question behind the question” gets into actual requirements gathering. Simply taking the feature request at face value makes you an “order taker.” Also, if one customer has a need, it’s almost guaranteed that others have the same. By backing up to find out what itch needs to be scratched, a good Product Owner works hand-in-hand with the customer and Engineering to find out:

  1. What is the problem/need/desire to be addressed?
  2. Given technological, resource, and time limitations, what is the optimal solution to the problem/need/desire that can be used by the most customers?
    1. See also, Jason Fried’s book, Getting Real, and his comments about building your product around a small number of customers

Here is an example I encountered that illustrates this point (as a refresher, I am in the Enterprise Social Software biz.):

We had a customer ask for what I lovingly termed “the firehose.” They wanted a running activity stream of all activity across the entire system. Every time anyone created a post, discussion forum thread, updated their status, etc, they wanted to see it.

Sounds ridiculous, right? How would that be at all useful? It would be like watching The Matrix scroll by – total information overload.

Instead of taking that request to Product Management as-is, I asked, “What issue are you trying to solve?”

The answer: “We had this feature in a previous piece of software and it helped us find other people with similar interests, old colleagues, etc. Sure, it was unbearable during the day, but if I was working early or late, I sometimes saw content or people scroll by that were useful to me.”

Basically, they wanted to use serendipity as a sort of RDF mechanism. Also, I could argue that staring at a ticker tape of activities, hoping to find something useful, is not likely going to register with their management as a great use of time. But, I digress…

My reply: “Sure, that would work. But, how about we use data from within the system to help link you to people and Communities with common interests, geographies, job roles, etc? We can then display suggestions for people, Communities, Posts, etc to engage with.”

Turns out we we already had a Suggestions feature in the works that used standard RDF triples to get at this info, which is partly why I made the suggestion. It was already near completion, it was something nearly all of our customers wanted, and – IMHO – it scratched this particular customer’s itch… even if they didn’t know it just yet.

Had we given them “the firehose,” they would have exactly what they asked for… but not what they really wanted. In this case, they were keynoting on previous experiences as the solution to their problem. A better approach would be to vocalize the pain point and work with us to devise a solution that best met their true need – given the resources available to all involved.

Ultimately, “the firehose” would have likely been unusable for most people and engineering resources could have been better spent elsewhere.

“It was implemented as spec’d, man. Don’t blame me!”

Going back to the ice maker, recall the design:


Running with our assumption that the “Push” button was the previous design, I can take a guess at how we arrived at the design above. It probably went something like this.

In the initial design, pushing the button completed the circuit to drive the motor to dispense ice. Keeping with that same design, when they added a valve to dispense water, they took the same design paradigm.

Engineer1: But, wait… there’s only one button. How about we put a switch between the button and the motor to turn the ice dispensing on and off. We need to hook the valve for the water up to the same button anyway, so let’s just do the same for the water.

Engineer2: Awesome! We’re totally going to get a bonus for coming up with a working solution so quickly.

Yes, this would indeed address the product requirement given to them:

  • Give the user the ability to dispense ice, water, or both

Certainly meets the letter of the law. I can’t argue against that.

But, did they actually take the time to use their creation? Did they take a step back and challenge the design? Was there a better way to solve the problem – even if it meant a bit more engineering time?

Quite often, I see Developers – most of which I know personally to be very smart and very UX-aware – simply implement a design as-is, even if they know that design is sub-optimal.

Why would they do such a thing? There simply isn’t time baked into the schedule to get the requested work done, much less time to iterate on the design. So, they implement what’s given, which sometimes ends up getting redone in a later release.

This one I would put in the lap of the User Experience team, with Management coming in a close second. Just as you can’t take a requirement from an end-user at face value, neither can you take requirements given from a Product Manager to be infallible. The whole idea of Agile is to iterate quickly so you can get feedback – from all parties – early and often.

Rather than just have “one” design, you should have a basis for your design – and iterate from there. You need to have slack in your schedule to accomodate this iteration.

Instead, we are often both Feature- and Time-bound, thus there is no wiggle room to do anything outside of our immediate marching orders. Ultimately, quality and UX suffers.

Lack of Stakeholder Input

This is typically more of an issue with Commercial software, as your Stakeholders are every potential client and end-user. It’s unreasonable to attempt to get such a large audience in a room – virtual or otherwise – to gain consensus and gather feedback. As a result, internal audiences – like the Product Owner – are the ones who end up accepting a User Story as complete.

Unless you plan to be the sole consumer of your product (e.g.: internal applications), this is a horrible idea.

In my experience, the people who create a product are terrible at predicting all of the incorrect ways an end-user can attempt to use the product. Nor are they equipped with the varying array of business needs that exist in the field.

Because of this, the feedback loop ends up being support cases and defects – neither of which are a good way to “wow” a customer. Not only have you damaged your brand, it is also much more costly to fix a design once it is out in the field. While most teams “can’t afford” to do this iteration in their Sprints, they end up paying more for it on the backside as the defects and angry customers roll in. Pay me now or pay me later.


To understand why this happens, go back to our first item: Requirements Gathering.

We can have every intention of doing a kick ass job of implementing a feature, but no matter how hard we try, we can not anticipate the corner cases and preferences of the end-users. The only way to do this is to get the feedback from the customers themselves.

Short of calling Miss Cleo, there is no substitute.

Going back to our ice machine, I can suspect the new design met all of the issues I cited at the top of this post… and more. Did these things occur to be because I’m some wonderful UX genius who can see things others can’t? As much as I’d love to say “yes,” the answer is “of course not!”

Had this design been tested – even internally, in this case – for a couple of weeks, they would have likely received the exact same feedback. Most importantly, it needs to be tested outside of the team that created it!

Our end-users are not aware of what happens behind the green curtain. They know how they would like it to work – regardless of the underpinnings and engineering involved. As such, they will not let technology lead them to a solution or rule out potential solutions, as would often be the case for those closer to the metal.

OK, time to bring this home…

Like any good story, this one has a happy ending. If you look for the current model of this machine, here is what the design looks like now:


Apologies for the crappy pic, but you should be able to make out that the new design is quite simple: Two buttons: One for ice, one for water. That’s it! No switches, no carry over of the previous user’s preferences.

This design is not only more aesthetically pleasing and much easier to grok, it addresses the issues mentioned above:

  • Want just ice or just water – without having to jack around with switches? Check
  • Want the ability to determine what ice:water ratio you want, without any fiddling with switches, etc? Check
  • Are instances of getting something other than you intended reduced? Absolutely (the only way it can happen is if the user pushes the wrong button)

I’ll be the first to admit that this is a pretty asinine way to get my point across, but this is a real (first world) problem that ultimately required a redesign to address. I see this happening time and again in software as the release, customer fury, re-design, re-release cycle persists.

Not to jump on the Microsoft bashing bandwagon, but look a quick look at the Amazon reviews for Windows 8 tells you that they got it all wrong. They took the option of doing what was simpler – hastily bolting a touch-centric UI on top of the standard Desktop – rather than “doing it right.”

Am I stupid enough to say I have the perfect answer to what they should have done differently? Hell no. But as a start, if you read the reviews, there is near universal agreement that the odd jumping between Metro and the legacy Desktop is jarring.

You don’t need alot of field research to find that one out. Yet, they decided to ship and are now suffering the backlash, ultimately delivering a way to bypass Metro entirely.

The points I am trying to drive home are:

  • Be mindful when gathering requirements
    • Ask the question behind the question and look for the need left unspoken
  • When designing and implementing, don’t tack on something to what exists if it will ultimately make things worse
    • Do it right the first time, else expect to see it come back – with high velocity – when your customer base hates it
  • Keep your Stakeholders in the loop
    • You aren’t selling ice makers to yourself, so make sure to deliver strong the first time to the people that matter – your customers!
    • You don’t have a second chance to surprise and delight
      • Ignore them during design and implementation at your peril!