Make Software for People

Whenever software professionals extol the virtues of Lean Manufacturing, I think of the I Love Lucy episode where Lucy & Ethel work the assembly line of a candy factory, then I wonder

What does quantity-based slapstick have to do with people interacting with visual representations of information?

Alan Cooper roasts the auto industry for slipshod telematics in this Cooper Journal post: Will Ford learn that software isn’t manufactured?

Auto manufacturers are far from mastering telematics. Toyota might have given birth to Lean, but 10 minutes struggling to make heads or tails of the slapdash telematics and interface controls on my Prius proves Toyota isn’t paying attention to my needs, let alone offering a familiar visual metaphor.

Someone at Toyota must have deemed an intuitive dashboard display & interface controls to be one of the original seven wastes.

You don’t have to be Alan Cooper or Don Norman to empathize with the people using your software. What’s the value and where’s the joy in using your products?

Design Serves Human Purpose – from paper clips to pyramids. Make software with people in mind.

It’s People, Not Machinery

Before we learned Toyota doesn’t know jack about software, the software community embraced Lean Manufacturing hoping to mimic Toyota’s legendary quality & efficiency.

In her post Creating a Mess by “Eliminating Waste, Esther Derby reminds me how principles built on assembly line manufacturing efficiencies don’t necessarily translate to people-centric businesses like software.

…any tool can and will be misapplied. This is especially true when a tool is plucked from one context and applied in another and when the use of the tool is divorced from the thinking and philosophy behind the tool. ~Esther Derby

Bill Clinton‘s advisor James Carville coined the phrase

It’s the economy, stupid.

In the same vein, I advance a rule of thumb about the making and consuming of software:

It’s people, not machinery.

The simplest caution I offer is “…start by understanding”, not by applying the tired bromides of manufacturing efficiency.

Lean’s three-legged stool of waste, overburden, & workload unevenness are more readily measured and tweaked in the context of machines and assembly lines — not so easily with people.

Yvon Chouinard, founder & visionary behind the outdoor equipment company Patagonia, has a mantra “Let my people go surfing” which is shorthand for

My business is focused on the fulfillment of my employees, and by extension, the fulfillment of my customers.

Encouraging your teammates to ditch work when the surf’s up is distinctly not a production-driven view that activity equals cost.

I cringe when referred to as a resource. I’m not a lump of coal to be burned. The phrase “efficient use of resources” is much less offensive to me when applied to carbon-based fuel than when applied to people.

Over-clocking a CPU & demanding higher output from people probably doesn’t overlap on any Venn diagram.

If it’s your job to nag me to cut waste, I’m left to wonder how and why you exist.

As a teammate, you may lean on me. But as a misguided efficiency weenie, please don’t Lean on me.

Design Serves Human Purpose

Humans have been designing for millennia.

Today, fast prototyping and rapid iteration cycles have become conventional wisdom in software development circles.

Enduring design serves a human purpose.

Human-experience-focused prototyping is a development practice I will follow with interest in coming months. Future successful software products will be made by teams in collaborative environments hyper-focused on human experience.

The Achilles heel of Big-Design-Up-Front (BDUF) is that it is rarely possible to know all design needs up front. Anticipating the many and varied outcomes a priori is daunting. And, many would argue, is inefficient.

Nature works in iterative cycles – in generations of adaptive species – to modify DNA. Why should software be shackled with a Creator-like BDUF when it can mimic the feedback loop efficiency of natural selection?

To encapsulate our trepidation for having to design and build products in an uncertain world, the authors of the book Subject To Change invoke ancient teachings

To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.
~Chinese proverb

From iteration zero to subsequent production releases, human-centric software seems likelier to succeed and endure. In Subject To Change, authors from the user experience design company Adaptive Path, have observed how user experience can inform and shape our product vision and growth from startup onward.

For products, software applications in our case, the authors of Subject To Change enumerate the facets comprising user experience:

  • Motivations: What do our users hope to get from our software?
  • Expectations: What preconceptions do our users bring to how our software should work?
  • Perceptions: How does our software affects the user’s senses (e.g., see, hear, and touch)?
  • Abilities: How are our users able to cognitively and physically interact with our software?
  • Flow: How do our users engage with our software over time?
  • Culture: What framework of manners, language, rituals and behavioral norms do our users operate in?

Human experience facets will likely be foremost in our minds in coming years and, in many cases, will likely supercede technical considerations (particularly technical considerations that have little bearing on product experience).

Agile Development

What have we learned about design from Agile Development?

  1. Bring the customer into the development process. Agilists have become adept at engaging stakeholders in the product development cycle. I would explicitly extend this concept to engage the end user (i.e., human experience).
  2. Value getting things right. Agilists produce early and often, then subject their product to the stakeholder’s approval. Again, I would explicitly extend this concept to include the end user (i.e., human experience).
  3. Be iterative and responsive to feedback. Because agile is, by definition, iterative and responsive, exploratory design and design changes are less costly than BDUF. With BDUF, no one wants to admit a year or two into product development, that a design approach everyone has been dutifully following, was flawed.

Lean Manufacturing

What have we learned about design from Lean Manufacturing?

  1. Value to our customer is our sole priority. Lean considers an expenditure of people’s time for any goal other than value to the end customer, to be wasteful.
  2. Build our product when the consumer orders it. Lean Manufacturing was pioneered during Japan’s post-war recovery by Toyota. The innovation was to build cars when an order was placed rather than stockpiling cars in anticipation of sales; a necessity for Toyota’s survival in the low consumer demand environment of post-war Japan. This innovation led to a tight feedback loop between the production line and consumers.

Today 3M has the motto: make a little, sell a little. This motto encapsulates 3M’s iterative approach that places its products temporally closer to the whims of the consumer.

Evolutionary Design

Evolutionary Design is the idea that design improvements naturally occur over a series of iterations (cf. Evolutionary Design – A Conversation with Martin Fowler).

Charrette is a French word meaning cart or chariot. The design charrette is thought to have evolved from frequent occurances in 19th century Paris where architecture students at École des Beaux-Arts would do frantic, last-minute collaborative design changes to their presentation en route to school in a cart (“en charrette”). Design charrettes have since come to signify collaborative design sessions.

One way evolutionary design manifests itself in software projects is with impromptu design charrettes. That is, impromptu discussions that occur amongst the development team. Novice and experienced developers frequently have adhoc sessions around someone’s cubicle, or around an open-plan Scrum pit, to discuss a design approach. Charrettes seem most helpful when everyone feels free to opine without retribution. These short and sometimes intense discussions are capable of rendering rapid, adaptive changes.

If the team also considers a guiding principal like How will this help our user? then design serves a human purpose.

Minimum Viable Design

There have always been talented designers on my teams who, thankfully, did most of the heavy design lifting. That’s not to say I didn’t offer ideas or opinions, rather realizing my limitations I have often deferred to others. I am not adept at planning ahead, but I am usually quick to recognize when things are working (and when they’re not).

Minimum Viable Product or MVP, is a concept borrowed from Lean Manufacturing by Eric Reis as a strategy for rolling out new product ventures. Eric’s incarnation of MVP is a mashup of agile lessons (e.g., release early, release often) and the realities of the funding cycles of a new venture. The MVP question is

What version is the version of a new product that allows a team to collect a maximum amount of validated learning about customers with the least effort?

An ever-so-slightly upstream companion concept to MVP might be called MVD or Minimal Viable Design. The MVD question is

What design pattern or design approach will allow our team to push a release that starts (and sustains) the feedback loop with stakeholders and users?

I am reminded of Naresh Jain’s post Embrace Simple Design where he encourages us to use the

Smartest Possible Thing That Could Possibly Work  ~Naresh Jain

Poet Wallace Stevens called this the art of what suffices.

To provide the utmost in utility and usability, software teams benefit from human connections and cycles of adaptive, rapid feedback. This is design for human purpose. It is an approach to design that is cast in the same mold as survival of the fittest.