Being an Experience-led organization

About experience-centric organizations.

Related posts:


We’ve heard it before: we should focus on designing for an experience; experiences are fundamentally different design challenges to a product or services; experiences are designed from the outside in.

We’re also told that we can apply this experience-centric perspective to tackle problems beyond the design of a product or piece of software. But we don’t often see examples of these ideas being put into practice. So that’s what I’d like to share.

Earlier this year I was asked by a client -YHA Australia – to work with them on a project aimed at selecting a new core IT platform for the organization. YHA Australia operate a network of some 120 or so hostels across Australia, and the system serves as the primary booking and hostel management system for each property.

During the first meetings to discuss the system it became fairly clear that the organization lacked any real sense of purpose for the system, and no clear idea of the strategic role the system might play in the organization.

More importantly for me, there was no real understanding of the role of the hostel management system in delivering a service or experience to hostel guests. What this meant was that we had no basis for prioritizing system features, or weighting features in the selection process.

To help facilitate this understanding I proposed to undertake some work with organization to help them better understand three things:

  • what does the guest lifecycle look like, and what are the characteristics of the experience at each point in that lifecycle;
  • in order to deliver on that desired experience, what does the business need to be doing; and
  • what are the technology requirements or features needed to support these business functions.

This approach explicitly mirrors the user:business:technology trinity of requirements that need to be balanced in order to deliver a quality experience, that in turns delivers value to the business. It also provides us a slightly simplified view of the framework Peter Merholz discussed in his recent HBR article, which begins with the experience and works inwards through interactions, touchpoints, procedures & systems.

In order to understand the guest lifecycle we brought together a group of experienced industry operations (hostel management), marketing and front-line service staff. We worked through a series of brain-storming and analysis tasks to arrive at a draft lifecycle.

This draft lifecycle was held up to reality using a number of techniques including:

  • contextual enquiry
  • interviews (with guests, more staff)
  • research in social networks

Using materials, research notes from previous projects (I’ve been working with YHA Australia for a decade), and interviews with back-office staff, each element of the customer experience was mapped to one or more front- and back-office tasks that need to occur to ensure the delivery of the experience as ‘designed’.

Part of the experience lifecycle

This research allowed for significant improvements to be made to the lifecycle in the pre- and post-stay stages of the service delivery. The detail in these two stages was meaningful because it allowed us to identify elements of the experience that would have been unsupported and yet clearly fit within a guest’s mental model of what constitutes the experience, even if not being a part of the traditional view of the service.

Most importantly, the research allowed for the experience to be deconstructed, and the important elements highlighted. This part of the work was informed by competitive analysis carried out previously, allowing points of clear and valuable difference between YHA and it’s competitors to be identified and prioritized.

By this stage we were back into familiar IT territory: what were the characteristics and features of the system needed to support the business functions previously identified. The big difference now, however, is that each business activity is directly related to a specific element of the guest’s experience.

Structuring the evaluation framework in this way also allowed us to question a lot of firm assumptions about what elements and functions within the IT system were most important. When features aren’t directly delivering a customer benefit, or enabling staff to deliver a customer benefit, it is muct easier to question the importance of that feature.

This framing of the problem also focused attention on several different sets of interactions within the overall service delivery system:

  • that between guests and the system, mediated through 3rd-parties (e.g. external reservation sites);
  • that between customers and front-line staff; and
  • that between staff and the hostel management system.

In other words, we have defined user experience requirements for two distinct audiences: customers and staff.

Describing multiple interfaces

Describing multiple interfaces

The next stage in the project is to layer in the functions that the business needs that aren’t tied directly to a customer experience. These include features related to financial management, corporate governance and risk management. In this model, these business-centric considerations are separated from the guest-centric considerations, and evaluated in parallel.

We are still in the process of using this approach to select the organization’s new IT platform, but this new framework has helped to transform the decision from a tactical, ‘day-to-day’ operations decision into a strategic choice affecting the whole organization’s positioning and point of difference.

I’ll be talking about this project, the approach, and lessons learned at UX Australia 2009 – a 3-day user experience design conference, with inspiring and practical presentations , covering a range of topics about how to design great experiences for people. It will be held on 26-28 August 2009, in Canberra (Australia).

Steve Baty

Steve Baty, principal at Meld Studios, has over 14 years experience as a design and strategy practitioner. Steve is well-known in the area of experience strategy and design, contributing to public discourse on these topics through articles and conferences. Steve serves as Vice President of the Interaction Design Association (IxDA); is a regular contributor to UXMatters.com; serves as an editor and contributor to Johnny Holland (johnnyholland.org), and is the founder of UX Book Club – a world-wide initiative bringing together user experience practitioners in over 80 locations to read, connect and discuss books on user experience design. Steve is co-Chair of UX Australia – Australia’s leading conference for User Experience practitioners; and Chair of Interaction 12 – the annual conference of the IxDA for 2012.

13 comments on this article

  1. One of the most important phrases: “I’ve been working with YHA Australia for a decade” – because you’ve asked them to reconsider the problem and thus the approach, and for an internal or an external consultant, that is often a real challenge. Nicely done!

  2. Lynne Polischuik on

    “When features aren’t directly delivering a customer benefit, or enabling staff to deliver a customer benefit, it is much easier to question the importance of that feature.”

    Yes! I just wrote this quote on our whiteboard and drew a big orange box around it :) Have been trying to pull team away from focusing on ‘Nice for us’ features but this articulates what I’ve been attempting convey perfectly. Thanks Steve!

  3. Nice.

    How often do we see a company approach the same situation with a vendor, platform or functions first approach without understanding “the need” or “the value” for the people using the product.

    We often hear how its hard to get a business to invest in some research up front before jumping into design and build.

    Doc – What made sense to YHA Australia when deciding to do user/business research first to help drive both strategy and IT going forward?

    rgds,
    Dan

  4. Firstly, thanks for the comments.

    @Nick: that user:business:tech trinity has been around for a while, and it makes for a great conceptual tool to talk to with clients and project stakeholders. Those two references are excellent – thanks for sharing them.

    @Steve & @Dan: There was certainly some resistance to the approach I was advocating. One of the factors acting in my favour was that I put forward the same idea on a similar project for the company four years ago (different IT platform); at the time they decided against it. That project continues to cause them pain to this day, and it’s ghost was definitely wailing in the room when I presented my idea this time.

    In addition, in the interim, I had led – from start to finish – the design & development of a bespoke Web-based business system for them, which was a great success. So the deck was stacked in my favour.

    @Lynne: Could you take a photo and send it to me? I’d love to see that!

    Thanks again.

  5. Thanks Doc. They clearly see your “value”

    The term “value” is becoming more interesting to me recently as I have heard over the years statements in UX circles like -

    * I am not valued
    * They dont value this
    * They dont value the results
    * My team is not valued
    * We dont know what the value proposition is etc

    This is certainly a larger topic, but wanted to share and aim to write and think more about it.

  6. Pingback: adaptive path » blog » Adaptive Path » Signposts for the week ending July 10, 2009

  7. Pingback: Brad’s Ramblings » Links 7/1 – 7/10

  8. Pingback: Facing Blend » A great example of the discovery process to design

  9. Pingback: Signposts for the week ending July 10, 2009 – UxSoup

  10. Fritz on

    Steve, late to this post but had to comment. For me the words…

    “We’re also told that we can apply this experience-centric perspective to tackle problems beyond the design of a product or piece of software. But we don’t often see examples of these ideas being put into practice…”

    at the beginning of the post are so poignant. Thank you for clearly laying out an example of where many of the methods we’re employing each day can applied to areas outside the web or software environment. In this age where so much technology is being made available to organizations who have very little understanding of its capability (which they’re often reluctant to admit), having someone with experience design background serve as trusted agent seems like an ideal solution.

    While system selection, vendor evaluation, workflow modeling have traditionally been the domain of IT consultants I think your article gives designers much to think about regarding what the extent of their contribution can be which in this economy can’t be a bad thing.

    Just curious though, how many designers can envision themselves in this sort of role. Also how did you refer to yourself or rather how did the client view and refer to your role throughout this process? As an experience designer? Tech consultant? Something else? Very curious about this, reply when you can.

    Good post all around though. Thanks. – Fritz

  11. Pingback: contextual enquiry

  12. Pingback: ST·Zeus | 用户为先·专注体验 » Blog Archive » UE学习笔记:也谈用户分群