Are Your Features Really Your Requirements?

Last night, I was flipping through the manual for my new-to-me car looking for some guidance on resetting the trip computer data. This being my first “new” car in 10+ years, there's lots of new gadgets and features. As I browsed, I hit one that made me excited because it answered a need I'd seen for years: adaptive brake lights that show braking intensity.

On the trafficchoked NoVA / DC / MD streets, knowing how hard someone is braking is huge. I've driven around here for years, watching folks slam on their brakes because the person in front of them stopped quicker than they anticipated. In fact, I've been that person. And after stomping the pedal harder, your eyes jump to the rearview mirror to see if the person behind you is going to stop or not. The result, at best, an instant mini traffic jam and at worst a multi-car pileup. If there was a way to signal to the person behind, "Hey! Pay attention! I'm braking really hard now!", then they can gauge their reactions accordingly. A carmaker put a highly thoughtful and highly useful feature in their product. Most excellent.

But as I thought more about it, my initial excitement waned. Not because the feature didn't work as advertised. Instead, I realized this excellent piece of engineering was completely useless to me and to others. Why? Because it was buried in a manual that only the operator of the car would read.

This feature wasn't for me; it was for the people behind me. No one on the road would know why my brake lights changed that one time. Or those two times. Hit the brakes with enough variation of force often enough in a short enough time span, someone paying attention might make a connection between a hard stop and brighter brake lights. Do you want to teach that potentially expensive and dangerous lesson on the fly? I sure don't.

Great & Useless

So here's a great feature that is hampered by the fact that the real audience doesn't know it exists and doesn't know how to interpret it - expertly specified, elegantly executed, completely useless.

So what happened here? How did this get from need to requirement to execution, yet turn out so badly? For obvious reasons, my mind went immediately to my 10+ years of system operations experience, supporting web applications.

My first thought was a particular quote, "No user interface design survives first contact with a user.” Now I won't start bashing my developer counterparts, because gathering and implementing user requirements in a ... creative ... manner is not just a software development problem. Interpretation happens at all levels; sometimes due to incomplete requirements, sometimes due to misunderstandings, and sometimes we wind up implementing a great feature in a completely unusable fashion, like my brake lights.

The implementation changes the expected behavior of an object. We find a signaling device that is trying to communicate additional but non-specific information.  It's like that mental moment when you need to figure out what to do when the green light goes green, but instead of a glowing circle, you get an arrow pointing up.  You hesitate because you now have to process information differently than you expected.  And if you think that modifying common signals doesn't cause problems, think about the last horizontal stop light you saw. If that doesn't do it for you, imagine you are red/green color blind and no longer have the known quantity of “top means stop.” We wind up with signaling devices that don't signal.

Who’s Responsible?

The responsibility falls on both sides of the fence. As you are describing what you think you need from your systems, make sure that those needs make sense once implemented. Over specification has been the millstone around the neck of many a project. As you are designing the implementation, make sure to raise issues where features may not present the uptake that was intended. Agile development arose over just these sorts of issues. The constant eye doctor "better like this or better like that" iteration cycle makes these sorts of discrepancies between what's in your head and what's on your screen easier to catch. Agile isn't the be all, end all, but iterating over designs with stakeholders can illuminate these sorts of potential issues.

We also have to realize that all of our good ideas simply don't work in practice. While it may be a great thing on paper, in execution it may fall flat. Authors are repeatedly told to be ruthless with their words, because we write too much to get our points across.  I obviously don't follow this as well as I should. We need to be ruthless with our ideas and requirements too. Brake lights that communicate more than one piece of information aren’t a bad idea in theory, but in practice pose a raft of issues. We need to think our requirements through to the end, not just toss cool widgets against the wall to build our systems and interacts. We need to communicate early, frequently and constructively.

Be thoughtful and ruthless when designing, it may just save your project.