Composing an email – an example of foundational design choices

Observe>Interpret>DESIGN>Experiment>How does the concept of foundation design choices that I introduced in the previous blog post apply to a real design situation?  To explore this let us look at it in a context familiar to most of us – the challenge of designing an important email.  (If you do not think that writing an email is design, please keep reading with an open mind.)  As a manager for many years, a significant percentage of my time (probably more than 20%) involved composing, reading and responding to emails.  I believe the ability to compose (design) a clear, succinct and relevant email is a very underrated personal skill in most organizations.

In the previous post I proposed four foundational design choices:

  • Objective
  • Boundaries/constraints
  • Architecture/game plan
  • Metaphor.

Let us see how each of these could apply to composing an email.

Objective:  Each email will (should) have a specific principal objective.  It could be to persuade, to propose, to inform, to update, to report, to call to action, to instruct, to admonish, to praise, to entertain, to enlist, etc.  The overall objective must be determined before we start composing the email so that the entire email supports that intent and so that the intent is absolutely clear to the reader.  (I will leave aside here the question of whether an email is the best way to achieve this objective.  That is a higher level design choice that I assume we have already taken.)

Boundaries/constraints:  Any email is subject to a number of practical and contextual constraints.  They include the time available to write the email, the likely time and attention that reader will give to the email (both these constraints will influence the length of email), the confidentially of any information in the email, the level of familiarity of the readers with relevant technical terms and acronyms, the existing level of familiarity of the reader with the subject matter and context, scope of subject matter, etc.  Some of the these boundaries/constraints, such as the length and scope of the email, are within your control as a writer. Others, such as level of familiarity with technical terms and acronyms, are characteristics of the readers.  However, the extent to which the characteristics of the readers is taken into account is still a choice of the writer (designer), that is, it is still a foundational design choice.

Architecture/game plan:  The style of the email essentially defines its structure (architecture).  Possible styles include formal report style, journalistic style, ‘call to action’, conversational, and narrative.  Exactly how these styles are implemented will often depend on context.  For example, how you ‘call to action’ will depend on factors such as whether the action is mandatory or discretionary, your level of authority or influence, the complexity of the action, and the level of reader self-interest in undertaking the action.

Metaphor:  If the email is particularly complex and/or important, it may be valuable to identify a metaphor for the email before composing the detail.  If the email is instructional, a road map metaphor may be appropriate.  If the purpose of the email is to admonish or correct, picturing yourself as a coach or parent may help set a firm but constructive tone (although this may be better done face-to-face rather than use email).  If you are calling to action to address a very specific challenge, then picturing the email as a arrow may help create the required focus and emotion.

Clearly, not all emails require the effort to develop foundational design choices.  Many of our emails are routine responses to requests for information or routine elements of the business processes of our organizations.  The design for these emails are essentially determined by the business context and/or routine (best?) practice in our organization.  However, foundational design choices are much more relevant and significant when the email is part of situation that is uncertain, unpredictable and emergent. This is often the case when we are seeking to use the email to persuade and influence in the context of organizational or business change.

Design involves choices – not all are equal

Observe>Interpret>DESIGN>Experiment>Whenever we create something to achieve a purpose or objective, we are designing. In the context of Adaptive Iteration we are interested in designs that need to achieve their objectives in situations that are uncertain, unpredictable and emergent. In these situations the scope and complexity of the interactions are such that we cannot predict all the cause and effect relationships in advance. Not only are they complex, but they are also changing dynamically and are likely to change further in response to the introduction of our design.

The types of situations that require this type of emergent design include business plans and strategies, organizational change initiatives, new product development, new market entry, career development and organizational development. In other words, almost any situation that is forward looking and involves interactions of people or groups of people whose decisions will influence the outcome.

Designing involves choices. There is no one right design. The design choices will determine the extent to which the design meet its objectives. If the design context is uncertain, unpredictable and emergent, the best design choices are not at all clear. For example, we cannot be certain how customers or competitors will react to a new set of product features. Can we be confident that our new social media strategy will attract sufficient attention from our target markets? It may not be clear what coaching and training to give to our middle-managers to ensure that they can make the transition to our new project-based organizational structure?

How do we make these choices? If we use the Adaptive Iteration approach we do not have to be ‘right first time’. With Adaptive Iteration, we form hypotheses about the best design choices and then conduct low risk experiments to assess how those choices work in practice. We use the resultant observations and interpretations to refine the design choices (hypotheses) that we again test experimentally, and so on. By starting small with low risk and iterating rapidly, we home in on the best design to meet our objectives in the particular context.

However, in Adaptive Iteration, our initial design choices (hypotheses) are not random. Foundational design choices set the relatively stable core of the design on which choices about the design detail are made and adaptively iterated.  The foundational design choices are not unchangeable during Adaptive Iteration but will change much less frequently than choices about the design details.  A significant shift in any of the foundational design choices should stimulate a major rethink of the overall design. The foundational choices, in general order of significance are:

Objective:  The objective describes the intent of the design, and of the associated Adaptive Iteration, and forms the key anchor for all other design choices.  All other design choices must enable the design to achieve its objective.  The clearer the design objective, the more likely that Adaptive Iteration will proceed efficiently and effectively.  It is important to select an objective that does not implicitly constrain the design options.  In my blog post that summarized the start up stories of HP, Sony and Microsoft we saw that the objective of each of the founders was to create a profitable business based on their particular expertise and interests, rather than create a business in any particular product/market segment.  The founders of each company adaptively iterated the product/market segment until they found one that met their design objective.

Boundaries/Constraints:  The boundaries and constraints can apply to any aspect of the design. They set the scope of design variables (choices) available to the designers.  They also set any limits to or targets for the performance of the design, and they set the context within which the design sits.  In some cases, tight design constraints can stimulate focus and can help challenge the status quo. For example, a design constraint that requires that the manufactured cost of a product design be 20% less than its predecessor is likely stimulate new a search for new perspectives and step-change ideas.  In other cases, widening the design boundaries may create the scope to develop more systemic and more fundamental design improvements.  Roger Martin provides a good example of this in his book Opposable Mind where he describes how IDEO recognized that its design brief from Amtrak (redesign their railcar) was inherently limiting and convinced Amtrak that, to achieve its design objectives, it needed to look at the end-to-end train ride experience.

Architecture/Game plan:  The architecture or framework of a design will usually have a significant impact on our ability to adaptively iterate the design.  Key decisions include how much operating flexibility and how much modularity to build into the design.  For example, an organizational design that is based on a strong and commonly held set of operating values and principles will empower employees to use their discretion to meet customer needs as long as what they do is consistent with those values and principles.  On the other hand, employees in an organization that emphasizes rules and procedures will be constrained to only the situations and responses anticipated by those rules and procedures.  The nature and extent of modularity will influence the ability to adaptively iterate the design.  Coarse-grained modularity will constrain design changes to large steps (changing one or more of the coarse grain modules), whereas fine-grained modularity provides much more flexibility but may lead to costly customization and integration of the design after each adaptive iteration. Ideally we want to align coarse-grained modules with any relative stable aspects of the context and use finer-grained modules for those aspects of the context that are uncertain, unpredictable and emergent.

Metaphor:  Use of a design metaphor can help unify a design by stimulating coherence for the myriad of detailed design choices.  It can help create a distinct personality for the design and stimulate a positive emotional response from the user.  A metaphor can also help identify the mix of design features that will create both functional and emotional coherence for the design.  It can help overcome the tendency to load a design up with all manner of features and capabilities “just because we can”.  For example, a metaphor may assist the redesign of an under performing group or small organization.  Depending on the situation and objectives, the group could use the metaphor of a sporting team, an orchestra, a jazz ensemble, an operating theatre, improvisation theatre, etc.

What is a design hypothesis and when is it required?


Observe-Interpret-Design-ExperimentThe concept of a design hypothesis is central to Adaptive Iteration.  But what is it and when is one required?

All designs have some degree of freedom and therefore involve choice by the designer.  How does the designer make that choice?  It depends on the stability and predictability of the context in which the design is to be used and on the extent to which past practice has evolved optimal designs or design variants for similar situations.

If there is substantial precedence, it is likely that design choices will be determined by past best practice.  Past best practice may exist in a number of forms, including:  formal design rules, modular components or established design heuristics.

In the organizational context, best practice is often promulgated by consultants and the management literature.  However, quite often not enough attention is given to describing the context for the supposed best practice or to assessing the contextual factors critical to the success of the ‘best practice’.  As a result, many ‘best practice’ organizational improvement initiatives fail to achieve expectations because of significant contextual differences between the best practice context and that of the implementing organization.  As I will discuss in a future blog post, adaptive iteration should be used to tailor and refine the design and implementation of many such initiatives.

If there is limited relevant precedence and the context is stable and predictable, it is likely that the design choices will be made by experts through a combination of their experience and analysis based on existing information and codified knowledge.  If the context is complex and unpredictable, experience and past practice are significantly less valuable in determining optimal design choices.  In such cases, the designer should consider an iterative hypothesis based approach.  The initial design choices are recognised as informed predictions, usually involving input from experts, that need to be evaluated and refined through repeated research and testing (experiments).  In a sense, the designers have a dialogue with the context.

In comparison with expert driven design, hypothesis driven design involves greater use of multi-disciplinary and multi-perspective teams.  It favours early action (prototypes, concept outlines, story boards, ‘sighter’ trials, etc) to generate feedback and learning.