Stepping back from our design systems

Component led design has become very popular recently. Responsive design is complex and it is understandable why alternative approaches focusing on components have become more popular. To be clear, I am an advocate of design systems.

However, at the end of the day this method of working is primarily a method for solving difficult internal problems that we face in design, development and content management. The end users of our digital products do not recognise the atoms, elements and molecules with which our design systems operate. Sure the user can benefit from a greater sense of consistency, but lets be realistic, users will not consciously operate at the component level when we have spent the last 25 years talking about “webpages”. It is this difference in mindsets and the familiarity with our design systems that I want to talk about.

We are experts in our design systems
So we have conducted the component audit, built the style guide and identified every element in our atomic design approach.

Your collaborative approach with the client means that their content production team are equally well versed in the new design approach. After three months of working on the project you and your client recognise every atom, element and molecule that you have crafted. The project is going well.

My concern is that the longer we work on a website (either in its design or post launch) the more expert we become in it. We remember all of the previous design decisions we have taken. We recognise that “Input Field Atom” that actually makes up the “Email Sign Up Molecule”. We know the CMS inside out and how we can mix and match components to make our desired outcomes. Ultimately, we can look at a page and we can quickly tell exactly how it is built.

We have become experts in our design system.

The problem with becoming an expert in something is that you find it that much harder to empathise with a novice. To look at something for the first time and understand what you are seeing. Let me use an example from the 1970’s to explain what I mean.

Expertise in Chess
In 1973 two psychologists called William Chase and Herbert Simon were conducting research at Carnegie-Mellon University on Perception in Chess. Specifically they were exploring what it was that expert Chess players saw that novices didn’t.

In essence their experiment went as follows:

  • They had various types of chess player ranging from “master” to “novice”
  • Each participant in the study was shown a chess position for five seconds. They were then given a board and a set of pieces and asked to recreate the position they had just seen.
  • Participants were judged on their ability to get as many of the chess pieces in their correct positions.
  • Some of the positions shown to participants were taken from actual chess games whilst other positions were complete random presentations of pieces on the board.
A 2D representation of a chess board showing a traditional chess position

Figure 1: A position taken from an actual chess game

A 2D representation of a chess board showing pieces randomly placed

Figure 2: Chess pieces randomly placed on the board. This position is unlikely to occur in a real game

Chase and Simon took their results and compared the performance of “masters” with “novices”. What they found became one of the most famous studies in psychology around expertise and performance (this study is taught on most undergraduate psychology courses).

As you would expect, chess “masters” were better than “novices” at recalling positions. However this finding only applied for positions taken from real life games. When the results of the random board positions were compared between “masters” and “novices” there was little difference between the two groups in terms of memory recall.

Subsequent analysis showed that chess masters were able to use their extensive knowledge and memory of thousands of real world positions to effectively chunk up the chess boards they were shown in the study. For example, a castled king position is a very common position in chess involving a king and rook with three pawns in front of them (see figure below)

Two castled king positions side by side with one highlighted in its constituent components

Figure 3: What a “master” sees as one component a “novice” sees as five

It was proposed that chess “masters” would see the castled king position as one group whilst novices would see up to five pieces. The more expert a chess player then the greater likelihood of them recognising a configuration of pieces and being able to recall them easier.

Therefore, when the random chess positions were shown a masters expertise was effectively nullified as they were thrown back onto the resources of the short term memory, just like the novice group.

Stepping back from our expertise
Although not a direct comparison with the world of component based web design, I have thought about this famous psychology study several times in recent months and the impact that expertise has upon our perception of a configuration of components.

Specifically, expertise in our design systems means that we can recognise every component so quickly that of course the page looks good to us when we just to add a few more components. A type of “wood for the trees” syndrome can take effect.

Responsive design systems are by their very nature complex. However, we must never forget that a complex arrangement of components can appear simple to us because by our very nature we are experts in that system.

Put yourself in the shoes of the user, the “novice” in my analogy. They are seeing the board for the first time and they are not certain where all the pieces go or what they do. Maybe the board has been set up nicely for them but then again maybe its a horribly complex position that only a “master” could understand.

Component led design has many benefits to us as a community. But as I stated at the beginning, these benefits are primarily internal to our design, development and content processes.

As we embrace this more flexible yet potentially more complex way of working we must ensure that this added complexity does not shine through into our final configurations.

Our design teams and content producers (especially them!) must remember to take the time to step back and look at the bigger picture at the page level. As the diagram in figure 4 shows (and what I was getting in an earlier post from 2013), there are good and bad ways of combining elements to create either complexity or simplicity (taken from 101 Things I learnt in Architecture School).

12 rectangles are arranged in different configurations on the page. On the left they form a jumbled collective. On the right they are arranged to form the outline of three overlapping rectangles with the smaller ones visible inside. Thus the 12 shapes are reduced to the informed simplicity of three blocks.

Figure 4: Combining elements to make complex and simple shapes

Whilst component based design systems are providing us with a lot of value internally, we must ensure that our final external facing configuration of components is not random or complex but familiar and uncluttered. Only then can we ensure that we are giving our users a playable position to start from.

References

  1. Chase & Simon (1973). Perception in Chess
  2. Frederick (2007). 101 things I learnt in Architecture School

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.

Why structure matters – The second task

When I was asked to speak in Bristol at this years World Information Architecture Day (WIAD), I found myself contemplating a range of topics to present. Being the keynote with a 30 minute window, I wanted to find a balance between opinion piece and practicality. My eventual topic “Experience, Errors and Structure” was well received, which was very satisfying as it is a theme that I have been carrying through much of my work in recent years.

My goal with my presentation was to acknowledge some of the history of UX (human factors / ergonomics / UCD – Delete as appropriate) and its movement from an earlier focus on usability and optimisation of software, product and web interfaces to the provision of some form of experience across channels.

However, I was also keen to point out that in the rush to provide an “experience”, I felt there had been a loss of focus on the immense value of a well designed digital product structure and taxonomy. Some would call this classic IA thinking or maybe even systems thinking. I talked about how thinking about structure and taxonomy can:

  • underpin the design of many dynamic experiences;
  • mitigates the occurrence of human error within the system;
  • provides a level of inherent usability to the system no matter how tailored the experience has become for the user.

As I talked about taxonomy and structure being the foundation of experience design I realised that I wanted to find a simple example I could talk to people about that would emphasise the inherent value of user centric site structures, over more dynamic, personalised or tailored experiences. From talking to my team, clients and peers i’ve started to call this example “the second task”.

The second task
Our industry will talk a lot about how users come to a digital product and how we “convert them” once they are there (am I only the only one who thinks this sounds weird and stalkerish?).
Social media, email marketing, personalisation, geolocation contextual targeting are techniques that have the ability to route users intelligently and directly to relevant content like never before. They are powerful value adding techniques that enable user’s to successfully locate content that can can often be buried deep in our websites.

So lets assume we have been successful in our goal of helping a user achieve whatever behaviour or task they wanted to when they visited our website? For example:

  • The came and read the article on our website that they found on Twitter.
  • They logged in and changed their address after receiving an email from their utility provider.
  • They bought and downloaded the ebook they saw advertised in the window of the shop in the high street.

What next?

Are they going to leave or are they going to do something else with our website?

After consuming that first initial piece of content on the website (and assuming they are still engaged), a user can be presented with two logical next steps in order to continue:

  1. Available navigation options (assuming they are intuitive)
  2. In-page content (assuming they are relevant)

Both of these “second task” options are presented as a direct consequence of the structural and taxonomy level thinking we have completed during the early phases of design. When thinking about “the second task” it is our site structure and taxonomy that takes over as the primary facilitator for the continuation of a user’s journey.

When we consider “the second task” (and we really should when thinking about cross sell, upsell and prolonged engagement opportunities), in my opinion, we are really acknowledging why thinking about structure is important.

Why structure matters

“A day without taxonomies is not found” Jared Spool (from the Accidental Taxonomist)

If you haven’t read it yet, Mark Boulton’s article “Structure First. Content Always” is an excellent exploration of how thinking about structure really is the crux of successful web design.

It is not my intention with this post to dismiss many of the dynamic powerful techniques that we can use to tailor and personalise relevant content for users today. I understand the value these bring.

My intent with this post (and I believe what I was getting at in my talk at WIAD 2015) was to emphasise that the need for logical, user centric structures and taxonomies has never gone away. We can tailor and personalise experiences as much as we want but it is my belief that sooner or later there will be a need for a user to fall back upon the underlying structure presented to them.

When you consider the time and effort invested in the pursuit of fully tailored, personalised experiences that some organisations are striving for, you have to ask whether some good old fashioned IA and Content Strategy thinking wouldn’t have a faster return on investment and bigger impact instead.

After all, “the second task” isn’t going away, nor should anybody looking for deeper engagement want it to.

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.

Understanding our customers Minimum Expected Product

In “Designing a service no-one wants to use” I discussed combining Scott Jenson’s Value vs. Pain model with the experience realms of Pine and Gilmore. The aim of this approach was to identify opportunities for adding experiential value within a service.

I am referring to those occasions in a journey that result in positive, memorable, moments for the customer. Those delightful moments that could range from a quirky fun micro-interaction, a customer fear reassuringly allayed or the discovery of an entirely new set of functionality in the service.

The role of expectation in memorable moments
Discussion around these types of moments is not new. However, what is interesting is the consistency with which practitioners have discussed the role of customer expectation in determining their likelihood to occur. Whilst flicking through an old note book from 2011 I found the following doodle to myself:

What is a peak experience for a customer?
When my expectations are surpassed and my goals are achieved

Jon Fisher, November 2011

Despite writing this alone in the pub (it was £5 for a pie and pint to be fair), it appears I am not alone in my thinking. Pine and Gilmore discuss one measure of customer satisfaction in The Experience Economy as follows:

Customer satisfaction = What customer expects to get minus what customer perceives they get.

Dave Power III of J.D. Power & Associates

Giles Colborne in his presentation Designing for Delight  talks about delightful moments occurring following periods of anxiety. It is during these moments of anxiety when a customers expectations of a successful resolution to an issue are at their lowest.

There are many other sources that discuss the role of customer expectation in perception of a service but at its simplest I like the analogy of going to the cinema.

At some point we have all left a cinema and said something like “it wasn’t as good as I thought it would be“. If we are honest with ourselves how does our enjoyment of a movie change having read numerous positive or negative reviews vs. not having read any at all prior to watching the film? What expectations have we set ourselves?

Pain Points and low expectations
The service design community has consistently advocated identifying customer pain points and eliminating them as part of best practice.

A graph showing customer journey along the x axis and satisfaction along the y axis. The lowest point on the graph is highlighted.

Existing service pain points are obviously the place of low expectations

There are numerous definitions of pain points but Ratcliffe and McNeil ( a great book on Agile Experience Design) give a nice concise summary of types of pain point in a customer journey:

  • Manual workarounds;
  • Sources of customer frustration;
  • Anywhere that involves the use of legacy technology;
  • Points of high customer attrition;
  • Sources of customer complaints.

Eliminating pain points are the quick wins of design because these are the areas with the lowest existing customer expectations. More than likely, customers have already experienced these pain points (unless its a brand new service) and therefore have their low expectations firmly set.

In contrast, when things work well people don’t want change because they struggle to visualise how it could possibly be improved (plus if we are honest they are probably scared that the design team will screw it up). Acknowledgement of this fact may be part of the origins of Henry Ford’s thinking when he said:

“If I had asked people what they wanted, they would have said faster horses.”

Henry Ford

Deriving requirements – the Minimum Expected Product?
Hopefully by now you can see the powerful role that customer expectations play in both the the perception and subsequent design of a product or service.

Sophie Dennis discussed the combination of the Peak End Rule and the Kanban model for deriving a Minimum Viable Experience at her excellent talk Getting UX Stuff Done at UX Bristol last year. In my opinion, the strength of her technique was recognising that customer expectations have to be surpassed at some point (i.e. the peak in the peak end rule) whilst recognising that, in the context of a minimum viable product (MVP), we cannot do everything and must prioritise.

The Kano model showing three lines on a graph defining basic requirements, performance pay offs and excitement generators

The Kano Model from Sophie Dennis “Getting UX Stuff Done”

To further elaborate upon her approach, my point would be that we should be determining customer expectations around functionality much sooner in the development of our MVPs.

Whilst an upfront piece of user research is often conducted by project teams to identify user needs, we are missing a trick if we do not define the expectations around these potential requirements.

For example, on a recent project me and my team had developed a prototype and were excitedly sat watching users engage in our lab. We had developed a solution for a particularly complex filtering problem that was going down a storm with users but there was one small problem. It was trickier to build and implement than an alternative design solution the team was also thinking about.

The question was would customers miss the more complex functionality if it wasn’t there? Were they expecting it as a minimum or was our observed positive reactions from customers a direct result of their expectations being delightfully surpassed? Could we choose the alternative design option to ease our build and implementation whilst maintaining an acceptable level of customer satisfaction?

Without going into further detail on the project, I hope you can see the powerful role that expectation is playing in this context.

Customer expectation is a two way street
My key point is that expectation works both ways for project teams:

  1. Understanding expectations enables us to spot opportunities for adding experiential value by surpassing existing perceptions, thus delighting our customers.
  2. But also understanding expectation enables our project teams to understand, prioritise and justifiably de-scope functionality accordingly so that we can strategically invest our time and effort in the right places whilst maintaining acceptable customer satisfaction levels.

Both of these benefits can only be obtained early in a project lifecycle (most likely when we are conducting our initial research) and only by asking the right questions. Its all well and good defining our minimum viable product as a project team but perhaps a better way of looking at it would be to define the Minimum Expected Product from our customer base.

Viewed from this perspective we would then be in a position to both optimise our design efforts and delight our customers. Truly a happy place to be!

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.

Someone needs to do it!

This is not a blog post about definitions. It most certainly isn’t a blog post about job titles. Its a blog post written to humbly request a different viewpoint on the world in which we work.

As anybody who has worked in our community for a while will testify, every few months or so a conversation will start up about defining what we do. Levels of granularity will be endlessly argued on Twitter. Overlapping skill sets debated. Accusations of land grabs by X discipline over Y discipline will fly.

Stop.

I don’t care. This is why.

If you are working in the context of multi channel digital delivery in 2014 then you will be familiar with some of the following skill sets:

  • Service Design
  • Content strategy
  • Information Architecture
  • User Research
  • Interaction Design
  • Visual Design
  • Front End Development
  • Back End Development
  • Accessibility

When you look at the list above, I ask you not to see a list of job titles but a list of design considerations that must be completed in order for the project to be successfully delivered.
A number of steps that must be gone through. A set of things that when done correctly, lead onto other happier things. If any of these things are not done then the likelihood of our project suffering is high.

We need to be considering accessibility from the start. We need to be thinking about structured content. We need to be considering what our users need and want. We need to be thinking about brand application. I could go on…

The reason I don’t care for definitions and job titles is that as long as the things in the list above are being competently handled on my project, I don’t really care who does them.

Assuming your project team has competence in all of the above disciplines, your project will be ok.

Specialisation and project teams

Its the nature of a maturing industry that over time a wider range of specialisations will start to appear, quickly followed by the establishment of umbrella terms (user experience anyone?).

Those specialisms, in my opinion, arise over time because the community starts to discover an intrinsic value in their practice. The community discovers that when they do a thing from the list of disciplines above, more often than not their projects benefit. Any discipline or skill set that did not offer value to a project design process would quickly whither on the vine and die.

For example, at some point in time somebody realised the inherent benefits of talking to end users. A few years later the “user researcher” specialism is born. I would therefore propose that user research offers intrinsic value to a design process.

But does it necessarily have to be completed by a “user researcher”? If its a big project team with a properly qualified user researcher on the team then sure go ahead. But what if I also had a fully qualified Information Architect who also happens to be competent at user research on the project team? Hmmm, dilemma time.

Or not.

I don’t care who does it. As long as the user research (you know that intrinsic value adding thing that is really important) is competently handled, I really don’t care.

Don’t have an accessibility consultant on your project but do have a cracking front end developer who specialises in web accessibility. Great!

Got a content strategist and an information architect on the same team? Let them fight to the death using blunt spoons in a pit of tar. Ahem. I digress…

My blindingly obvious point is that when viewed in the context of getting stuff done, suddenly job titles and definitions just don’t seem that important anymore.

There is a whole range of value adding activities that need to be completed for a project to be successful. They are things that simply need to happen. As long as they are done correctly, who does them is just academic.

Therefore next time you are assembling a project team don’t tick off job titles, tick off competencies instead.

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.

When reviews stop being useful

Customer reviews are ubiquitous on the web today. Its hard to visit any site that sells a product or experience that doesn’t utilise customer reviews (usually on a five point scale). Whilst I acknowledge that the little five stars are not about to go anywhere soon, there is a scenario where they stop being useful.

Weddings, Zip wires and Mayan temples

In September I got married and went on honeymoon to Central America. As a consequence, In the last year I have found myself thinking (amongst other things) about the following three things:

Wedding venues: Where do me and my wife want to hold one of the important days of our lives?

Rainforest zip wires: Which company should we use for flying over the canopy of a Costa Rican rainforest?

Mayan ruins: Which of the 1000 year old long lost Maya pyramids poking out of the rainforest should we visit?

To quickly summarise 12 months, both our wedding and honeymoon were incredible. However, one thing thing that didn’t help us in planning was a customer review. The problem is, its very hard to find a wedding venue, Costa Rican zip wire or Maya temple that doesn’t come with a ridiculously good review…

Customer objectivity and bias
Its easy to see how any of these three activities will naturally come with excellent customer reviews, they are great things to do! Read any of the descriptions of the activities above and I challenge you not to inherently imagine how splendid (or awesome for my North American friends) they can be.

A photo of the author zip lining above a Costa Rican rainforest

How can anyone not give this five stars? But there are dozens of companies in Santa Elana, Costa Rica

However, when you look a little deeper at these activities (and talk with people who have done them) you spot two factors that helps explain the high ratings of customer reviews:

Unique or rare events: Typically these types of experience are unique or very rare in our daily lives. For example, most people who visit Costa Rica, rarely do more than one zip line trip.

Positive emotions: These kinds of experiences elicit a highly positive emotional response from us (well you’d hope so on your wedding day!)

In other words, If you only do something once and it felt great you are likely to give it a high score when filling out a customer review. Whilst this in itself is not a problem (I don’t begrudge people having a good time!) it does make the selection process when trying to purchase one of these experiences more difficult.

Your purchasing decision is harder
As a prospective customer looking to purchase one of these rare, positive experiences I simply stop using customer reviews. They just don’t enable differentiation in the selection process.

For more common experiences, customers are able to extrapolate and provide better critiques because they have a greater base of experience to allow comparison. For example, a business traveller may stay at several hotels a year and they generally don’t tend to be a particular highlight of their calendar year. Therefore, a customers reviews can be more objective. Thus I find Trip Advisor more useful for booking accommodation than trips to Maya pyramids in Guatamala.

Is this really a problem?

Everybody seems to be having a good time right? True. I guess my problem is that not all five star experiences are created equal. Anecdotally from our honeymoon travels, ourselves and several other travellers we met visited multiple Maya ruins across Central America. What quickly became clear is that some ruins were much better than others and yet they all had high scores on Trip Advisor. If you’ve only visited one set of Maya ruins then you will give it a great review, they are inherently cool. The paradox is that because you only visited one maya site (or got married once or zip lined once etc) you have no base of reference on which to base your experience.

A screenshot of Calakmul ruins on Trip Advisor with a 5 star review

The ruins at Calakmul with a five star review on Trip Advisor

A screenshot of Tikal ruins with a five star review on Trip Advisor

The temples at Tikal with a 5 star review on Trip Advisor

Contradiction and content implications

I’m not silly enough to suggest that having a five star review is a bad thing. What I am suggesting is that it should be possible to identify types of experiences where reviews will be less useful to prospective customers because of the combination of ultra rare and positive emotive circumstances I have been discussing here.

If we can identify these types of experiences, it enables us to consider what other factors we could potentially use to help differentiate these experiences for prospective customers. For example, if we know that reviews are less useful for decision making, then how does this change our content requirements for our individual product page? Is there additional content that we can add that is the clincher. For example, the fact that your zip line company offers couples zip lining options (how romantic on your honeymoon).

Despite me bashing reviews in this context, they will always be essential content requirements for customers. If only as an initial filter in decision making. The difficulty is that if all your competitors are proudly displaying their five star reviews then you too must puff out your chest and your “Trip Advisor Excellent 2013” award. You can’t afford to be the exception in the marketplace, even if in so doing your unique proposition is lost in a sea of five star reviews. A true contradiction if ever I saw one.

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.

Candidate Moves in Design Thinking

It has been estimated that there are more positions in chess than there are atoms in our solar system. However, at any given time a player is only allowed to make a single move. A single move to enable them to navigate the minefield of complexity in front of them. How does a chess player do this? What implications can this have for design?

When scouring the 64 squares in front of them a chess player is not evaluating every possible move available to them, this would be insane. Instead, good chess players rely upon the principle of candidate moves.

Candidate moves are a collection of moves (usually around 3 or 4) that the chess player has determined to have a suitable level of merit to require a further focus of their attention.

A chess diagram showing a 2D image of a chess position with arrows drawn on to show piece movement

Your move, which path do you choose?

In his excellent book “How to choose a chess move”, Andrew Soltis notes that by move 20 of a chess game a player on average has 38 legal options available to them. Soltis goes on to demonstrate how a good chess player is able to reduce this large decision tree through the application of a method called candidate cues:

  • Tactics: Immediate threats on the board (both offensive and defensive) that must be dealt with;
  • General Principles: Sound principles of play, based on experience, will often indicate to a player a possible good move, for example protecting your king;
  • Positional Desirability: If no tactics present themselves then the strategic positioning of your forces for the long term can throw light onto a potential move;
  • Consistency: If previously you have been engaged in a specific plan then it makes sense to continue down that road (unless your latest assessment has identified a flaw in your plan)
  • Problem Pieces: If nothing else the player may survey their forces and realise that they have a “problem child” that must be improved or removed.

Thus through the application of rules, pattern recognition and experience, a chess player is able to control and harness an incredibly complex environment and determine a course of action.

Candidate Design Moves
Sound familiar? We may not identify such an obvious framework for tackling design problems but certainly the above principles are used daily by me and my colleagues for shortlisting potential design solutions.

In the current movement towards lean methods of working, designers will consistently find themselves under tighter timescales with development teams demanding “the answer” sooner rather than later.

Fast sketching, ideation and co-creation workshops are all popular and invaluable tools for iterating quickly and pushing forward design thinking around a particular topic. I’m sure many of us can relate to the idea of developing large amounts of design ideas in a short space of time with the intention of throwing away 80-90% of them.

Failing to candidate
What I find interesting about the candidate moves concept is how noticeable it is when it is not adopted. I have lost count of the number of chess games I have lost through the immediate impulse move. When looking back in hindsight, I nearly always can attribute the loss to a point in time when I say the immortal words:

I never considered anything else

The great Russian chess players often refer to this as the “programmed move”. How applicable is this flaw to our early design discussions, particularly when we consider the work context of a minimal viable product and a wall of half drawn sketches?

How often, through the need for expediency, are we drawn to the obvious candidate? The one that deals with all of the short term immediate problems but has some positional long term flaw? The move that worked in the last game so why shouldn’t it work in this one?

Don’t get me wrong, I’m a strong advocate for lean design working methods but my question would be this:

  • On your last project how many true candidate moves did you really consider?

Admittedly your design team could just “fail fast and pivot” but in my opinion, a strong set of candidates can allow you to spot potential pivots before they happen.

A strong candidate set
In a chess game, a strong set of candidate moves will often present a player with a range of paths. The risky move with high reward. The unknown move that has never been tried and leads to an uncertain result. The quiet move leading to strategic positioning. Any or all of these moves could be good.

The same is true of our early design discussions. Im not advocating the risky solution over the tried and tested. What I am advocating is the identification of a number of potential design directions and a fair assessment of each.

Every time I have seen a successful product launch it usually had a broad set of potential candidate moves early on in the product design phase.

In my opinion we all become become better designers when we avoid the “obvious choice” and consider all the paths available to us. Embrace your candidate moves and become better at what you do.

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.

The Trouble with Resumption: Transitions in a modern service ecosystem

“Where was I?” Three little words that all of us have muttered when we return to something that we put on hold. It could have been five minutes or five days but either way we speak them aloud in an effort to refresh our memory. The phrase “Where was I?” is interesting because it leads to a subject that I have been thinking a lot about: transitions.

When I talk about transitions in the context of a modern service I am talking about the movement of a customer across various channels, typically following a period of elapsed time. This movement could include:

  • moving from Channel A (e.g. a website) to Channel B (e.g. a retail store);
  • returning to the same channel that you previously visited (although when considering responsive web design we could be looking at the same website on a different device…).

From discussions and experience, the phrase transition doesn’t seem to do justice to the significant realignment required on the behalf of a customer when shifting channels.

Therefore I have started referring to these channel movements as Macro Transitions to differentiate them from the smaller transitions that we typically design on a day to day basis.

What, Where and Why

Commencement of an activity following a macro transition can cause considerable problems for a customer. Immediately following a channel shift there are three obvious challenges that must be overcome that I like to call the three W’s:

  • “What was I doing?” – The customer must remember what they were thinking about before they stopped;
  • “Where was I?” – The customer must remember the very point where they previously stopped;
  • “Why am I here?” – The customer must place the new channel in the context of their overall goal.

Several others before me have discussed the concept of cross channel understanding (Andrea Remini’s and Luca Rosati’s 2011 classic Pervasive Information Architecture is a must read). However, for the benefits of this post it is a term coined by Joel Grossman in 2006 (in an article for UX Matters) that has resonated with me: “Designing for Bridge Experiences”.

Building bridges: The role of 3rd party applications

The bridge metaphor is apt when considering macro transitions as it perfectly sums up the problem we face as experience designers. We are trying to get a customer to cross a giant chasm in order to continue their journey.

As we have moved further towards cross channel ecosystems, the construction of these metaphorical bridges has been increasingly provided by third party applications and services.

In recent years there has been a proliferation of applications and services whose success is based on their ability to construct a bridge across channels. Some popular candidates here would include Dropbox, Pinterest, Evernote and QR code readers.

Hopefully this small list demonstrates to you the type of applications and services I am talking about. Each of these services or applications have the ability to reduce a customers pain when making a macro transition:

  • Dropbox: I can access files from any device I choose. I no longer have to worry about remembering to leave the house with the right file when i want to work on something;
  • Pinterest: When shopping I can pin something I like to one of my boards so that I do not have to worry about finding the same item again from whatever website I was on. I can access that board from Pinterest on my phone when I am standing in the high street store thus allowing me to continue my purchase journey;
  • Evernote: In a similar fashion to Pinterest, I can create folders for my interests and email things to myself that I can access at a later point from any web browser;
  • QR code readers: If implemented correctly then QR codes have the ability to help a customer jump the chasm from the offline world to some deep place in the online world, for example a specific product page in a large website.

Is there a problem?

So whats the problem you might say? As our society has embraced digital, certain companies have spotted opportunities to offer bridge building services. Good on them!

Thats not my issue, I love my Dropbox and Evernote! My question concerns the number of people in society who are using these services. Lets take a quick look at the number of global users for some of these bridge building services we have mentioned:

  • Dropbox: 100 million users
  • Pinterest: 49 million users
  • Evernote: 60 million users

So if these figures are correct then we are talking in the region of 200 million users (assuming some level of overlap). At this point I should acknowledge that there are other bridge building behaviours (for example emailing yourself links) that customers use but these are difficult to measure.

However, it still seems to me that there are potentially a lot of web users out there attempting to perform these macro transitions without any help whatsoever. Thats a lot of people struggling with the “What, Where and Why” and thats my problem with many existing cross channel experiences.

The trouble with resumption

Easing the burden of a macro transition typically relies upon a customer being both digitally savvy and proactive enough to adopt a bridge building service or application. I would argue these types of individuals are in the minority when compared to the total target population of many services.

Maybe this is only a temporary problem given the state of technology, the publics level of digital literacy and the range of commercially available alternatives in 2013. Whilst I love the concept of Just in Time Interaction, we are not there yet.

In my opinion, as long as navigating a macro transition relies on the proactive downloading of an application then there will always be a significant proportion of our target audience who will struggle in our services.

I will revisit the topic of transitions again but to conclude I want to leave you with a quote from the fantastic Thinking in Systems by Diana Wright and Donella Meadows. The quote comes from an old Sufi story and to me sums up everything about dealing with transitions in modern service ecosystems:

You think that because you understand “one” that you must therefore understand “two” because one and one make two. But you forget that you must also understand “and”

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support.  You can also follow me on Twitter here.