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.

The UX of Desire

The Botany of Desire by Michael Pollan gives a compelling perspective on how desirability determines viability and how plant species have thrived by co-evolving with humans. Michael Pollan’s insights are wildly applicable to software User Experience (UX).

Pollan begins with the premise

Design in nature is but a concatenation of accidents, culled by natural selection until the result is so beautiful or effective as to seem a miracle of purpose.

He demonstrates how four plants have survived through adaptation, and have ultimately thrived by capitalizing on human desires and needs:

  • The Apple – exemplifies our desire for sweetness & intoxication (apple jack),
  • The Tulip – exemplifies our desire for beauty,
  • Marijuana – exemplifies our desire for pleasure, and
  • The Potato – exemplifies our need for sustenance.

Human Desire & Software

Facebook grew from an idea in a Harvard dorm room to over 500 million active users in a hand-full of years (cf. Facebook Timeline). My hunch is that Facebook’s popularity is based on its appeal to human behavior and its fulfillment of human desires. That is, by tugging at our narcissism, our curiosity and our instinct to connect with others, Facebook enables us:

  • to know what our friends, and would-be friends, are saying & doing, 
  • to surreptitiously learn more about particular love interests, 
  • to be flirtatious within a socially removed virtual cocoon, or simply 
  • to be noticed.

The Botany of Desire reversed my bias about humans domesticating plants like corn or apples or cotton. Perhaps it was the other way around – could it be that the plants domesticated us? Plants have, at the very least, used humans to co-evolve and thrive.

I now think of my killer app as a “species” co-evolving with humans. Future startup software might well have to be every bit as cunning as a Venus Flytrap. Our software must provide the sensory lures, then deliver on needs. Future apps might well be like successful plants — spawned by and grown by adaptively fulfilling specific human needs in a survival-of-the-fittest environment.

The Lean-Startup approach seems a fitting platform for the evolutionary experimenting that future killer apps might require. Lean-Startup is rooted in the principle of iteratively adapting and refining a business model (i.e., an evolutionary concept), based on proving the viability of features (meeting needs that customers desire).

INot only will killer apps have to provide features and fulfill needs, they will also have to present desire fulfillment in an alluringly positive experience not unlike a flower’s nectar lures and intoxicates a honey bee to better serve the flower’s ongoing reproductive purpose.

The UX of Desire means attracting and delivering (…so beautiful and so effective) as if the life of your app depended on it!

Value Experience Over Features

As a software developer, it requires vigilance to temper my tendency toward joining feature frenzy. Like you, I like to build features.

My lazy inclination is to forget about asking why or how we justify the new-fangled feature that I’m itching to build.

Features represent our bread and butter, but we are also professionals. We want to be proud of our work.

Since

  • our business partners are utterly, in many cases, clueless;
  • we aspire to be better professionals; and
  • we identify with being craftsmen in the best Alan Cooper-ian sense,

it’s up to us to

Value experience over products & features.

How-To Value Experience?

Be an advocate for users. Politely question what’s motivating improvements. Are improvements driven from hard data or the soft notions of some muckity-muck over in operations? Resist your tendency to join the feature frenzy.

Let yourself be dragged kicking and screaming before you contribute to BAD user experience by layering in Over-Featured Confusion.

Over-Featured Confusion

Case in point of Over-Featured Confusion is LinkedIn’s new and improved Discussions feature.

As soon as LinkedIn released its groups concept, I founded two LinkedIn software groups (i.e., the global Agile .Net Practitioners and the local Twin Cities Software Consultants).

Laudably, LinkedIn has steadily rolled out features that have improved our group experience. Until now…

LinkedIn’s new Discussions feature amounts to a ball of confusion. The most glaring improvement is a horizontal slider bar with options to Like, Pass, Comment or More? as a mashup of blog, news and discussion items scroll past (horizontally).

At best, it’s confusing. At worst, it’s unusable.

  • May I Pass on this colossal FAIL by LinkedIn? No.
  • Did my feedback to LinkedIn about this improvement disappear into a black hole? Probably.

LinkedIn replaced simple & serviceable with confusing & dysfunctional.

Considerations

As design luminary Don Norman says

Forget the complaints against complexity; instead, complain about confusion.

Perhaps it’s excusable to transform something complex into something confusing. But it’s inexcusable to transform something simple, like a discussion board, into something confusing.

Google UX researcher Paul Adams says in his presentation Designing Experiences, Not Products

We need to understand how people think, and what motivates them to behave in certain ways. The best way to do this is to design from the outside in. To observe people in their own environment, probing them so that we understand their behavior. This understanding enables us to design things that are meaningful and valuable to people.

We’re Fast, We’re Not Cheap, But Are We Good?

Using the software term Sprint Velocity, I’ve mistaken Velocity for Speed for several years. Truth is, when I think of a treadmill, I might be confused about Speed too.

Speed and direction define Velocity. On the dashboards the software community is so enamored with, at best, we depict speed. Direction is mysteriously absent without leave (AWOL).

With Direction AWOL…

If you don’t know where you are going, it’s easy to iteratively not get there.
       ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck

Good at Delivery, But Not-So-Good at Discovery

I have programmed with development teams that range from pretty good to pretty stellar vis-à-vis rapid incremental product delivery. But the products we built could have been better – particularly if we had been better discovering what our user community valued about our software.

The consensus at Code Freeze 2010 and DevJam’s developer Jam Session last night is that few of us have much of a clue about the people trying to accomplish things with our software.

Many projects cling to monitoring speed, but that’s not good enough. It reminds me of lyrics from the Steely Dan tune Babylon Sisters.

Well I should know by now
That it’s just a spasm
Like a Sunday in T.J.
That it’s cheap, but it’s not free

It doesn’t matter how fast we deliver if we deliver junk. Are there ways to measure quality? The Interaction Design community says so.

My Pet Product

I am laser focussed on a pet product. I want to experiment with giving my future user community a place at the table in iteration planning. I want my future user community to help us prioritize the product backlog.

I want to be abundantly transparent to them that their suggestions are acted upon and not ignored.

The cheapest and most direct measures of quality I have considered for this particular product are

  • How many community members can we enroll? 
  • How active are they? 
  • How long can we retain them?

Enrollment, Activity, and Retainment are the legs of this product’s stool.

Averting Usability Calamity Software

Can Usability Calamity Software – you know who you are – be averted by paying better attention to users?

What would the measures of quality be for your pet product?

Credit Due

Most of the observations I make about software these days –

the notable exception being giving the user community a hand in prioritizing incremental improvements

have been adapted, or stolen verbatim, from the folks on my software luminaries list. The gist of this post is derived from things David Hussman has said (and I probably mis-understood).

Integrating Interaction Design Into Agile Projects

Thanks to advocates in Agile community, many software developers have gotten proficient at delivery. Perhaps now it is time to examine what we’re delivering.

Better questions and attentive listening might avert those occasions where we do an outstanding job of delivering the wrong thing.

Discovery & Delivery

At last week’s last week’s CodeFreeze 2010 on the University of Minnesota campus (my alma mater), speakers David Hussman and Jeff Patton were wearing t-shirts that said Discovery & Delivery.

The authorized theme of CodeFreeze was Redesigning Agility. The unauthorized theme might well have been as David and Jeff’s t-shirts said — Discovery & Delivery.

How do we integrate Interaction Design into our Agile projects?

Looking retrospectively beneath the vaulted glass and wood ceilings of Memorial Hall, where CodeFreeze was hosted, one might conclude that the Agile community deserves kudos for improving our ability to deliver software. One also might conclude that we have yet to make significant progress integrating interaction design and usability into the Agile cookbook.

Interaction design and usability considerations will continue to play a significant role in whether people are satisfied using our products. We had better jump on the design band-wagon, or at least appropriate all the most forward-thinking interactive designers as our own.

Jeff Patton posed the following question to the CodeFreeze audience

If you evaluated the quality of your process based on customer satisfaction, what would that process look like?

Jeff’s question helped solidify an approach I have been considering for months. Three influences on my thinking are:

  1. Google’s slogan of Launch Early and Iterate (see my post Launch Early and Learn);
  2. Eric Ries‘ concept for startups of a Minimum Viable Product; and
  3. At CodeFreeze, watching Alan Cooper talk about Interaction Design and watching David Hussman and Jeff Patton talk about Discovery (e.g., Story Mapping).

I have concocted a recipe for a discovery & delivery process that I am eager to share and to take for a test drive.

User-Driven Rapid Prototyping

Lets call it User-Driven Rapid Prototyping. As the name implies, the approach involves rapid prototyping. It is also user driven because the people who use the application help the software team prioritize the backlog.  The challenge and proposed approach are a follows:

Challenge Integrating Interactive Design into Agile projects
Proposed
Approach
Iterative Cycles of

  • N weeks discovery and 
  • N weeks coding & delivery

The diagram below shows what the iterative cycles of User-Driven Rapid Prototyping might look like

Where

  • The hand palming the spiral is a Discovery or Re-Discovery Iteration
  • The subsequent handless spirals are Delivery Iterations
  • Discovery iterations, after iteration zero, are called Re-Discovery
  • Odd iterations are for coding and delivery, while Even iterations are for discovery (interactive research and design).
The software team consists of developers and interaction designers working hand-in-hand. Since the backlog will be now driven by the people using your software, the over-worked and frequently clueless Product Owner we’re familiar with from Scrum, becomes redundant.

Iteration zero –  Iteration zero is a discovery iteration. The goal is to learn as much as is reasonably possible about the community for which you are developing the product. Iteration zero might include chartering, creating personae, and story mapping. Also it might include any of the groundwork you typically lay before iterating in earnest.

Iteration 1 (and Odd Iterations) – Iteration 1 is the first coding and delivery iteration. Iteration 1 might only include some user feedback screens, or a polling mechanism to enable the people using your application to help the team prioritize features, to call out usability snafus, and to bring to light potential design problems. In general, odd-numbered coding/delivery iterations are for adding new features and releasing a deployable prototype. During coding iterations, developers are coding while the interaction designers are working to stay ahead of the coding/delivery curve with ongoing user research and design deliverables.
Iteration 2 (and Even Iterations) – Iteration 2 is the first re-discovery iteration. The re-discovery iteration is a chance for the interaction designers to account for any feedback, then implement course corrections as needed. During this time, developers work with interaction designers to address the feedback, to re-factor code as needed, and to plan the next delivery.

Designers engage in “designing with your hands” which involves making multiple, low-resolution prototypes quickly
~Tim Brown, CEO of IDEO

There is no one-size-fits-all software process. There are conditions that are likely more amenable to the approach proposed here. Greenfield software projects and startup projects might be most suitable. For example, in the evolution of a startup, an ever-improving prototype might be used to attract rounds of investment to fuel continued development phases.

Wouldn’t it be a kick if the picture below could just as easily be the people using your software as the people crafting it?

More…

  • Tim Brown urges designers to think big in this video on Design Thinking.
  • In Usage-Centered User Stories & Story Mapping Part 1 and Part 2, I explain what post-Agilists like Jeff Patton and David Hussman, have been telling the Agile community how we might help teams enrich poorly conceived user stories and how we might better use our iteration zero time for product discovery. That is, how discovery might be improved.

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.