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?
Agile Development
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.
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.
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 JainPoet 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.
Bob, yet another simple and powerful idea I found inspiring is:
ReplyDelete"Make the users feel good about themselves by enpowering them"
- Maximize user participation
- Enpower users
- Let them feel good about themselves
I first learned these concepts when reading "the inmates are running the asylum" from Alan Cooper about five years ago. However unlike Agile his methodology seemed too specific, heavy weight and expensive. Nevertheless some of his ideas were very powerful and revolutionary at the time.
So I believe there is huge value if we focus on the motto "let users feel good about themselves" rather than the banal looking cliche "make the customer happy".
Two things are seriously wrong about "make the customer happy":
a) Above all it must be "make the user happy". Focus on "the user" rather than "the customer". The term "customer" is material focused (the guy who pays us) and less genuine, and customers are not necessarily the users.
b) Again the "happy" bit of "make the customer happy" is not genuine and lacks depth (how the hell we make them happy-no answer).
The secret is "make users feel good about themselves, give them the power they need". This should be engraved into minds of everyone in the team and written on the corner of whiteboard and not erased. Perhaps above all the origin of design should be just that.
Hi Ergun,
ReplyDeleteI'm learning a lot from your commentary here, from your negative matter blog, and from your discussion posts. Thanks!
I like the distinction drawn between user and "paying" customer.
Now I *must* read "The Inmates are Running the Asylum". David Hussman (my friend and "agile mentor") recommended it, so it's #1 in the queue after I finish "Subject To Change".
Cheers!