Monthly Archives: February 2016

Perspectives in (service|enterprise) design

All sorts of perspectives on service design and/or enterprise design keep spinning in my head and, I think, in many posts on the topic. Why not add one more?

This post is work-in-progress and an attempt to clean up my thinking.

Fundamental perspectives

As Tim Brown states in Change by Design and IDEO explain on their website, successful design has to satisfy the three constraints of:

  • desirability (human perspective: Do people want it? Does it make sense? Is it meaningful?)
  • feasibility (technology perspective: Can we do it?)
  • viability (commercial/ecological perspective: Can we sustain it?)

The faculty of Industrial Design Engineering at Delft University of Technology recognizes these perspectives as peopletechnology and business.

Consequently, desirability, feasibility and viability are three perspectives that we will want to consider in most of our design activities. (We’ll have to ensure that we do not consider these to be constraints too early in the process so that we do not prematurely limit our thinking.)

Levels of abstraction

Drawing upon work by Tom Graves we can identify several levels of abstraction when taking a service-oriented view of the enterprise:

  • purpose (Why are we here?)
  • context (Who is “we”? What else is around?)
  • concept (Who does what for whom? When? And, especially, why? The conceptual (or functional) level.)
  • implementation (How is this going to work? The implementation-specific level.)
  • deployment (When will this happen? Who is and which resources are involved? The operations-specific level.)

I’ve been rambling about this before. This time I’ve omitted the action-record level, i.e. the level providing an historic record of activity within the enterprise. This brings us to:

Time

I think time is best considered to be a distinct dimension rather than an aspect of other dimension. It can be useful to consider the past, present and future when discussing desirability, feasibility and viability. Similarly, different time perspectives can play meaningful roles when discussing the different levels of abstraction introduced above. In particular, the action-record level is just a past slice of the deployment level. An action plan constitutes a future slice of the same level.

In the context of service design, we’ll often want to consider five different time periods: before, at the begin of, during, at the end of, and after the service encounter. This could be easily extended by considering distinct phases of becoming and ceasing to be a specific service provider’s customer (for services involving continuous or repeat services).

Over time, the enterprise changes its shape: participants leave and others join, resources disappear and others become available.

Jeff Sussna pointed out that these comments reflect a purely linear view of time that is typical of many service design efforts. I think that this is also true for many other types of design efforts including user experience and business process design. However, in many cases, the people involved have at least a latent understanding of the fact that life is not as linear as e.g. a customer journey map might suggest.

As designers we need to be more explicit about the fact that linear time-based maps are a gross simplification. We need to point out aspects such as concurrent or parallel processes (which may have varying degrees of interdependence) and other non-linear aspects of time.

More of Jeff’s tweets on the topic here, here and here.

What next?

The above is only a start, but the mess in my head feels a little more manageable already. Other dimensions can (and should) be added, the different concepts could (and should) be discussed in more detail. For example, entire books can be (and have been) written on desirability alone.

Update

2016-02-20: Added reference to Delft University of Technology to Fundamental perspectives.
2016-02-15: Updated section on Time based on comments by Jeff Sussna.

Advertisements

Lead architects and collaborative design

Brenda Michelson had this to say on Twitter yesterday…

..and all I had was a smartass response. Brenda shared a valuable idea.

Somehow “lead architects” rubbed me the wrong way…so let’s get rid off it:

Considering…

All architecture is design… —Grady Booch

…we can just speak of “lead designers” who need to know all the questions…or at least many…or know folks who know questions.

Let’s also include “lead developers” and lead whatevers in that description and use this broad definition of designer:

Everyone designs who devises courses of action aimed at changing existing situations into preferred ones. –Herbert Simon

With that out of the way, why do we need lead designers when we’re all subscribing to collaborative design? What does leading design mean in the context of collaborative design?

What if we considered a lead designer to be an expert who then should be considered a knowledge manager as described by Andy Grove in High Output Management? From this perspective, leading (managing) is then much less about making (design) decisions than about gathering & distributing information and influencing decisions (nudging).

Leading design would then become facilitating and supporting collaborative design, i.e. helping the group design and designing with the group. Leading would then become helping the group figure out whom to follow with respect to different issues. Leading would then mean ensuring that all voice have a chance of being heard, especially the quieter ones.

Leading design would then be about helping the network make better (design) decisions (hat-tip Harold Jarche via Lisa Sieverts).

Leading design then wouldn’t rub me the wrong way.

 

 

The end of service encounters and customer relationships

I’m currently reading Service Design for Business: A Practical Guide to Optimizing the Customer Experience by Ben Reason, Lavrans Løvlie and Melvin Brand Flu of Livework. I’m enjoying the book so far and am convinced that it will make the field of service design much more accessible to a wider business audience.

The authors have extended the traditional three-stage model of service consumption (pre-purchase/pre-encounter, encounter, post-encounter stages) by another stage (begin) yielding these four stages: before, begin, during, after. Their reasoning for adding this stage is sound:

How customers begin their relationship with a service is critical to success…A good beginning helps to avoid dissatisfaction and makes customers more disposed to do more business with you later. –Reason, Løvlie, Brand Flu

In their takeaway messages for this chapter they conclude:

The beginning sets the tone for the relationship. –Reason, Løvlie, Brand Flu

Symmetry suggests we also take a closer look at how service encounters or entire customer relationships end. Thinking about our own experiences as service customers it becomes clear that the end stage of an individual service encounter or a relationship with a service provider can have significant impact on our evaluation of the overall service experience and the service provider.

For example, being rushed out of a restaurant after a nice meal with our partner (or having to wait too long for the bill) may well spoil an otherwise excellent experience on the finishing line. Similarly, if the service provider makes it difficult for me to leave a service after my needs have changed, my overall evaluation of a satisfactory service experience up to that point will be diminished.

In both cases, my readiness to re-purchase the service will be severely reduced as will be my readiness to recommend the service to others. On the contrary, I’ll probably complain about the service failure to anyone who cares to listen.

The authors seem to recognize this without highlighting the end of a service encounter or customer relationship as a distinct stage:

Past customers are also potential future customers–and are therefore always worth attention. –Reason, Løvlie, Brand Flu

In conclusion I suggest extending the discussion by considering referrals & recommendations by current and former customers, and by adding an explicit end stage to the model, thereby yielding these five service stages: before, begin, during, end, after.