Influence Over Design

I came up with this silly metaphor to describe the problem of giving inordinate power to the wrong people for the implementation of design decisions. 

Imagine a house was designed by an architect who did research into how the structure would be used and by whom. 

• The first floor is where the owners, a couple, would spend most of their time. The primary features there are a living-room, a kitchen with a view of the backyard, and a bathroom that services basically all the guests who aren’t staying the night.
• The second floor can be used as bedrooms for children or guest rooms. It has a bathroom that services those bedrooms. 
• The top floor is the master suite, consisting of a bedroom and a bathroom for the couple who lives here. 

Now imagine the architect hands this design over to a team of plumbers and carpenters. They listen to the architect’s brief and take the following notes: 

• 3 stories. 
• 3 bedrooms. 
• 3 bathrooms. 
• Livingroom.
• Kitchen. 

Before they get to work, the project owner walks in and says “We need to keep costs down and do this as quickly as possible.”

They say “Does it need to be 3 stories or could we do it in 2?” 

The project owner goes “2 would be way cheaper. Let’s do that.” 

The carpentry team gets to work on the framing and roof and lets the plumbing team figure out what should come next. 

The plumbing team then redraws the plans with the following logic:

Plumbers have to deal with a lot of pipe breakages that cause damage to floors underneath, so it would actually make much more sense to not put anything that requires plumbing above the first floor. If there’s a break, damage will be minimized.

In order to reduce the amount of pipes they have to use, they put everything that requires water in a row on the same floor.

The first floor is now the plumbing floor. 

Everything else is on the second floor. 

Boom.

Nailed it.

Cheap, safe, and easy. 

Of course this story is silly, but I would argue, based on my experience studying, observing, and participating in design, it is a pretty reasonable depiction of what often happens when we give the wrong people inordinate influence over design choices, either with proper design happening up front (such as the architect did) and just throwing it over the wall to the engineering/programming team, or, more often, without that work happening in advance, with developers making design decisions on the fly, without research, heavily influenced by the biases of their discipline, and without the requisite competencies and activities to create user experience-driven outcomes. 

What might happen next in this story? Someone might come in and say “actually this bathroom feature is redundant on the first floor. Let’s reduce it to just one bathroom”

or worse…

“There’s already a sink in the kitchen that offers nearly identical features… What do they need a whole bathroom for?”

Imagine how an electrician might want to redesign things if they had too much control over design decisions.

“Why do you need lights in every room? Why not just cluster them all together in the basement next to the dishwasher and refrigerator, along the walls around the breaker box. That would make it way easier to troubleshoot outages.” 

I think you get my drift…

So what prevents this silliness from happening?

In the context of a software project, what prevents the constrained perspectives of non-designers from corrupting design decisions and causing what gets built from losing fidelity with user needs?

To put it simply, the kinds of things that prevent this include the following:

• Design criteria are established up front by dedicated, competent designers given the time and resources to do proper research and synthesis
• Design criteria are validated with end users, prior to implementation
• Design criteria are properly translated for implementation and protected from the constraints, motivations, and biases of those who did not generate or validate them
• Team topologies, work prioritization, and other organizational strategies and cadences serve to ensure that user needs remain at the heart of what gets created, often through ensuring there is continuous advocacy for validated design criteria
• Feedback loops are created and maintained to test features and user tasks against the hypotheses that they were based on

I haven’t spent that much time in this space, so I have plenty left to learn about design roles, competencies, and practices, but as of right now, it appears that in the USAF and DoD, we’re making some pretty obvious mistakes fairly consistently when it comes to design in the realm of software and beyond. I’m excited to see the work being done to rectify these problems, very much including efforts at my organization AF CyberWorx to introduce Human-Centered Design to Air Force and DoD audiences and problem-sets.

What do you see pulling us off course? Who do you see helping?