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.
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.
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).
What have we learned about design from Agile Development?
- 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).
- 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).
- 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.
What have we learned about design from Lean Manufacturing?
- 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.
- 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 is the idea that design improvements naturally occur over a series of iterations (cf. Evolutionary Design – A Conversation with Martin Fowler).
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.