Tag Archives: design

Digital experiences: journey first or content first?

Both. Sort of.

Recently the topic of whether to take a journey-first or a content-first approach to delivering digital user experiences came up. The former seems to be favoured by more “traditional” user experience designers while the latter is favoured by many content strategist. No surprise here.

For now, my take is this:

I think I want to start with the customer experience in a conceptual, coarse-grained and probably channel-independent manner. A concept map (or a service ecology map, despite this grandstanding name) is a good basis from which to start mapping a customer journey.

Digging into more detail, increasing the focus on content seems useful, both in terms of detailing the content model and the actual content.

In turn, the content model as well as representative content elements can be an effective basis for designing the actual user journeys for a digital service.

Thoughts, please? Thanks.

Requirements are design decisions

I believe that the success of software development projects and many other types of initiatives could be greatly improved if we came to terms with a simple insight:

There is no such thing as a requirement. A so-called requirement actually is a design decision.

Why does this matter? First and foremost, I think we want to consciously make potentially far-reaching decisions, especially when other peoples’ lives and livelihoods depend on them. (Well, this dependency might be more pronounced in your business decisions than mine…) Second, when we see these design decisions for what they are, we can make them more effectively, e.g. by applying design methods to them.

Requirement statements are best understood as statements of stakeholders’ interests, needs or wants. Rather than taking them at face value, we ought to seek insight into the stakeholders’ deeper, underlying motivations.

For example, stakeholders frequently express perceived mechanisms for achieving desired ends as requirements. Identifying these desired ends will often lead to discovering better ways of achieving them.

Design decisions come in two flavours: decisions relating to the problem space (i.e. ultimately deciding which problem to solve) and those relating the solution space (i.e. ultimately deciding how to solve it and implementing the solution). Rushing to working on the solution may feel like progress, but this might well be progress in the wrong direction.

A request: I know that I’m not the first one to state that requirements are design decisions. Please let me know if you know who said this first (or, at least, early). Thanks.

In what context? For what purpose?

Dean Bubley (Disruptive Dean) said the following on Twitter yesterday:

The OSI stack for networking should have Layers 8 & 9 added to it: context & purpose. That’s where the value is going.

The underlying thought seems to be applicable to other areas, including service design, enterprise / business / solution architecture and software development.

Tom Graves’ describes several layers of abstraction in his service-centric view of the shared enterprise, starting with the enterprise layer, which defines purpose, and the scope layer, which defines context.

When describing a software service, for example, I typically begin by describing its intent and depicting the service in its context (both static and dynamic).

So, when faced with a new concept or a new challenge, one of the simplest ways to start adding value is asking two questions:

  • In what context?
  • For what purpose?

Design rulez!

Ruth Malan writes about software architecture, providing deep insights and entertainment in a great package. To me, her insights seem readily applicable to design and architecture work way beyond software-intensive systems, including service design.

I was going to write about–alright, link to–her work on Conceptual Architecture today, but I’m afraid this will have to wait for another day as this caught my eye: Design Rulez!   (Make sure you also read the continuation dated 7/19/10.)

I frequently observe the urge to jump from initial ideas, e.g. alleged requirements, to concrete implementations (or renderings) of these ideas, e.g. code, bypassing conceptual design and/or architecture. Ruth describes some of the effects of doing this:

When we put working code in front of someone, they work at tuning that–the mindset is small delta. That’s a generalization, of course, but generally once we are reacting to something concrete, the concrete thing shapes our expectation, and we tweak that. Instead of having a whole gamut of design options in front of us, we have narrowed the design space. So early on, if we really want to be creative, to explore the market and design opportunity, we need to keep people in the zone of possibility.

In my experience, this urge, behaviour and effects are not specific to software development.

To me conceptual design and/or architecture are essential activities for achieving truly satisfactory results. If our clients and colleagues don’t see that, perhaps we could do a better job of demonstrating (and delivering?) the benefits of our conceptual work.

Also, expending significant effort on a conceptual level makes many people feel uneasy, inviting the resistance to the party and the lizard to rear its head. Perhaps we could do a better job of helping others to work with this uneasiness?

I certainly can do better on both counts. Thoughts, anyone?


Service experience is more than just customer experience

Veigo Kell, retweeted by Bob Marshall, said the following on Twitter this morning:

It is remarkable how little the people running organizations know about the experiences of the people working around them. ~Dan Pink, Drive

This led me to write this post which I had thought about writing before but then put off:

An organisation should rightly be concerned with the experiences customers and users have when interacting with the organisation, i.e. humans and automated services representing the organisation. However, many humans other than customers and users are involved with the organisation. Some of those closer to the organisation are employees and partners. Note: See this blog post by Tom Graves for a discussion of other players in the enterprise, in particular anti-clients. So if it is beneficial to care about our customers’ experiences, it is surely (even more?) beneficial to also care about the experiences that humans working with and for our organisation have. (An ethical argument for doing so can easily be made, too.) A complete view of service experience has to consider the experiences of all stakeholders. And while I’m at it, let’s not forget service outcomes, i.e. non-experiential service results: A complete view of service outcomes has to consider the outcomes for all stakeholders. In other words, I suspect it’s “human-centered design” and not “customer-centered design” for a reason.

Services from an operations perspective

Service Operations Management: Improving Service Delivery” by Robert Johnston & Graham Clark was and continues to be one of the major influences on my thinking on planning, designing, building and delivering services to customers. While this textbook is written from an operations perspective, it takes a holistic and customer-centric view on delivering services. Continue reading