Summary: Don't make square gloves: When you define the base requirements, ask what sort of gloves are you making? And why?

Let’s say you wanted to make gloves. In order to do so, you defined the product’s requirements as “a covering for the hands that protects them from extreme temperatures.”

Because you’re not a glove-maker yourself, you then handed that requirement to someone responsible for designing and creating the actual item, and they came back with something like this:

Question: were the product requirements met?

Answer: Yes.

Two squares of warm material, sewn along three sides, will provide a cover for a hand that will protect the hand from extreme temperatures. Does this pass Quality Assurance criteria? Yes.

My little analogy may be an oversimplification, but the truth is this sort of thing happens a lot in the software development lifecycle. It would be nice if we could blame it on just one weak point in the chain of production, but the issues are usually myriad, from many areas of the organization.

A short-list of possible issues:

• The business need was passed along, but without narrative context for the problem they’re really trying to solve.

• Teams are working within what they assume are immovable constraints: “We have square pieces of fabric and no scissors, so here’s how we’ll make these ‘hand covers.'”

• A production team may be under pressure to create a “minimum viable product” within a sprint or two, and they pick the core functional requirement, deciding to forego any “enhancements” as “out of scope.”

Please understand, I’m not meaning to impugn any particular methodology. Waterfall, Agile, Lean, Design Studio, “MVP” or Other Method Du Jour and any permutation of them all … no matter how robust the process might be on paper, it’s in actual practice where value goes off the rails. The weak links are often due to a lack of shared understanding about the product’s contextual narrative.

What Do I Mean by Contextual Narrative?

A lot of stuff, and more than I can cover in a blog post. But for one thing, there’s the context of use: how do end-users actually need the product to perform, in real life? One of the benefits of an actual glove, fitted to the hand with fingers and thumb, is that you can still manipulate things pretty well even though you’re wearing a cover over your hand, such as writing something down or fishing car keys out of a pocket. In everyday life, adults need to be able to do these things in cold weather. Hence, gloves are about more than just keeping hands warm, they also need to allow full articulation of the hand.

This sounds ridiculously obvious. But look closely enough at software you use on a regular basis, and you’ll start noticing gaping holes between what your actual behavior expects from something and how it actually works.

For example, I have friends who have sent a message to multiple recipients on Facebook, and then received a reply from one of the recipients who had no idea it was a “group” message, only to divulge some personal information that they never would’ve wanted the others to read. Did the system meet requirements? Probably it did, if the requirement was “allow users to send to multiple people, and replies to go to all original recipients” but it did not take care of a really essential requirement: “make sure it’s obvious to all senders that replies will be to ‘all’ not just the original sender.” A similar issue was rampant in the iPhone’s multi-recipient text feature a while back, until Apple (only barely) improved the interface to make it somewhat more clear what’s going on.

Back to our glove analogy: what if the context of use were different? Let’s say the requirement of “protecting hands from extreme temperatures” was actually about picking up hot pots and pans from a stove? In that case, having a very basic cover that you can put your hand into in a hurry (without fussing with fingers) is an excellent solution!

An improvement could be made by at least adding a place for a thumb: then you can still get it on quickly, but have use of an opposable thumb as well—a win-win! 

This seems so straightforward. So why do the pitfalls above happen, resulting in mittens when we need gloves, or vice versa? Partly because software is a lot more complicated than gloves; and partly because of the nature of business.

Lay the Groundwork with Learning

Companies run in part on making things efficient, which often involves paring decisions down to their essentials, breaking the work into serial chunks, and passing each stage of an effort down the line of command (or across the departments responsible for making things). What often results is a bureaucratic version of ‘whisper down the lane‘  that manages to lose the contextual narrative that would have made the outcome more coherent, relevant, and “good.”

Starting off the work with the right contextual narrative to begin with is quite a challenge. TUG has a number of approaches for determining the contextual narrative behind our clients’ products and services (even if we don’t always call it that). We learn all we can about users, of course, but we place a high value on learning about the business as well. Through planned alignment sessions and evolving methods like Performance Continuums, we’ve had great success helping clients determine “what good means” for them and their customers, before they start spending resources on designing and building anything.

What about after discovery and alignment? There’s the rub. Ultimately, it’s up to the organization itself to keep the work relevant to its original narrative context. Not that you have to be alone: TUG often help clients with program planning, “road mapping,” and creating governance frameworks to help them stay on track; and we find it can be helpful to stick around to help with direction and coaching as client teams keep the program moving.  Still, the organization has to be committed to the vision. Call it what you will—”user experience direction” or “product management” or “intent architecture”—it takes dedicated effort to manage a coherent narrative  across the command silos and development phases.

So, what sort of gloves are you making? And why?