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.

Why Design-Build?

In Architects & Agile Like Zen Monks & Cell Phones, I questioned the relevancy of software architects in agile.

This morning I recalled two additions we’d made to our home. Both efforts were done by a superb craftsman who, in both instances, urged us not to engage an architect.

Both projects were completed on time, within budget, and, to our ongoing satisfaction, the results are functionally and aesthetically pleasing.

The trend toward agility in the software business is mirrored by the construction industry which has been evolving for more than a decade toward a Design-Build (DB) approach. In their version of DB, one contracting firm does the design and the construction; in contrast to Design-Bid-Build, or DBB, where one firm does the design (architecture) and other firms (construction) bid on the design specification to do the work.

A 1999 study by the Project Delivery Institute at Penn State found that DB beats DBB in delivery speed and in delivering at a lower cost. See the graphs above and right.

Is an additional advantage of DB for the construction industry

the ability to change on the fly?

In days of yore before agile, I questioned the wisdom of separating designing and building into buttoned-up packages that marched in succession. I knew that

we learned things as we built

and that

we adjusted accordingly

This summer my son will participate kiln-building course where students will design and build a wood-fired kiln. He’s an architecture student who is also passionate about functional pottery.

This is his first opportunity to build a structure that will provide decades of utility to others. I wondered if it would be his last opportunity to build a structure as opposed to conceptualizing a structure.

A side-benefit of agile is the organizationally-imposed distinction between architect and developer is blurred, if not irrelevant. In well-oiled agile teams, people wear many hats. As such, successful teams behave like start-ups (i.e., from necessity, they’re too small to segment specialties, so everyone does whatever needs to be done).

Design-build is personally satisfying, even if my design contribution is only to confirm what my more conceptually gifted team-mate, was thinking.

Agile Ennui and Egyptian Pyramids

The oldest known Egyptian pyramid is the Pyramid of Djoser.

This rock-solid design has served its intended purpose since the third dynasty. That’s roughly 4,620 years of service. Suffice it to say,

That’s one lengthy dirt nap for the Product Owner Pharaoh Djoser

It seems the Pharaoh’s Scrum team delivered the ever-elusive value in a mere 20 years — which begs the question:

Who has built software that lasted more than 36 months?

Deftly tapping an ergonomic keyboard is not quite like moving heavy rocks. Is it still possible to equate quality with duration? Today we build beautiful things, then hire demolition experts to strategically place charges to blow them up.

I once spent 18 months on a product that was universally praised, promptly scuttled, and never used.

I’m not a whiner, but does anyone experience existential ennui when they think about how we’re spending our time?

Agile coach David Hussman pointed out that the Egyptians practiced Evolutionary Design (cf. Evolutionary Design – A Conversation with Martin Fowler) with improvements with each iteration. According to David:

“The first pyramids were merely burial mounds. The next version was the step pyramid (Djoser’s tomb) and the next version the “bent” pyramid (a design in rock that they had to refactor during construction. These were all the forerunners to the Giza structures. It was a progression of small, simple structures which evolved based on the learning (and failures) from the last iteration.”