Experience by example
Applying specification by example to experience design
At Friday, we design and build digital experiences. Producing the right experience requires us to reach consensus between strategists, designers, software engineers and the business departments of our clients, as to what we are building and why.
We have found, along with many others who work in digital, that these groups often use subtly different language. This can lead to miscommunication, mistrust, and the wrong product being designed and built. In this post, I describe a technique we’ve found useful for producing stronger customer experiences: applying specification by example to experience design.
Specification by example is a technique used in agile software development to bridge the communication gap between the business and engineering. It uses a template form of describing concrete scenarios that helps guide collaborative conversations between product, engineering, and QA.
The template that is often used to prompt the discussion around these scenarios is ‘Given-When-Then’, although using this language isn’t strictly required.
Good scenarios are described in the language of customers and stakeholders. They enable stakeholders and developers to more quickly come to a consensus and form an ‘ubiquitous language’ that unites business, design and engineering.
Applying specification by example to experience design
Experience design is also best done collaboratively, with everyone in the same room having meaningful conversations about the target customer experience, and any changes to the operating model that will support this experience. These conversations can be quite abstract, and involve many areas that are beyond the day-to-day experience of the participants.
This makes it hard for all parties to come to a common understanding of what is being discussed. Often, subtly different mental models clash leading to arguments over interpretations, even when they don’t fundamentally disagree.
We start applying specification by example from the most critical points of the experience. Identifying those touchpoints upon which the experience hinges (sometimes called ‘moments of truth’) allows us to prioritise our specification work on those elements that are essential to get right, where there is the greatest potential impact from any misunderstandings. We define the touchpoints as scenarios, using the domain language of the customer and client.
As an example, a pharmacy chain wants to make it easier for patients to receive their prescribed drugs by routing their prescriptions to their local pharmacy.
This scenario is both concrete (focusing on particular drugs, for example), and written in the domain language of the customer and client.
The next step is expanding these seed scenarios. There are two main ways to expand scenarios: by questioning the context, and by questioning the outcome.
When questioning the context, we are looking for situations where it may not hold, or where alternative contexts are possible for the same event. We might ask questions such as what happens if someone is allergic to amoxicillin, or whether there are any other groups who can prescribe drugs in this service.
Looking at outcomes, we can ask what happens if the patient doesn’t pick up the drugs within a certain time period — are the drugs returned to a depot or similar — and have a conversation about (and capture) what that time period may be.
This questioning lets us generate new scenarios. We can add these to the big picture to layer up the experience map and iterate this process until we have consensus that we have reached the boundary of the service.
By using concrete scenarios, and building a ubiquitous domain language, we can have a conversation that fully uses the expertise available from the client, strategy, design, and engineering. These concrete scenarios, and therefore the experience, can then be validated with real customers. From their feedback, we can fill in yet more detail.
Concrete scenarios spur more ideas. When dealing with large services that cross organisational and team boundaries, it can be hard to relate the experience being discussed with the impacts it may have on you or your team. Focusing the discussion on actual examples helps make things clear, and can naturally lead to conversations about alternative solutions.
They translate naturally into input for build. Engineers, designers, and QA have something solid to discuss, and interrogate. This allows the build teams to take the experience scenarios and expand them to incorporate edge cases and implementation detail. The experience scenarios become the first pass at a living documentation for the product.
Scenarios can be instrumented with code to test whether the experience has been delivered or not, not just that the technical implementation is error-free. This allows us to validate that the right thing has been built not just that a thing has been built without bugs.
The process generates a ubiquitous language for the key concepts of the domain that is common to strategy, design, engineering and business departments. This in turn allows for deeper conversations that are more meaningful to all parties. Less time is wasted establishing a frame of reference for conversations debating semantics and so agreement can happen faster because of the shared deeper understanding.
Detailing expectations can expose interactions between business departments. Assumptions underlying the experience become explicit through the iterative expansion process and can be discussed with less emotion, because the focus is on concrete user experiences and outcomes for customers and not on inter-departmental politics.
Scenarios can be walked through with real customers to extract better feedback and gain validation more quickly. They can be used as input for building prototypes to do early testing of the concept — the prototype becomes a representation of the scenarios.
What we’ve learned
Include just enough detail in the scenarios to be confident that the right thing is being built. Too much detail and the scenarios become brittle, applying to one highly specific state only; they are hard to understand at a glance and the process becomes slow to use.
Document the core journey from end to end before adding side journeys and edge cases and include the minimum of user-interface detail. For example, it’s enough in our pharmacy scenario to say ‘the patient receives a notification on their phone that includes location’ without trying to word the precise notification the patient receives. UX and content specialists can then use their expertise to add this detail at build, adding their own detailed scenarios where appropriate.
Scenarios should be described from a customer perspective, using their language. This allows the scenarios to be validated based on customers’ needs not on business needs. Sometimes, however, it is necessary to describe the interactions with backstage business processes. In that case, we treat the people involved as customers of that part of the experience.
Involve all disciplines and relevant departments in the conversation. This builds consensus quickly and reduces the risk of nasty surprises: the business understands what it is getting and how the system hangs together. Everyone knows what is to be built and why customers need it.
Ultimately, a highly visual experience map is a great way to concisely explain an experience, but it can be expensive to iterate on, particularly during the more speculative starting stages of the conversation. To help address this, we’ve built a tool called Eyemask that allows us to take the plain text scenarios and turn them into visual artefacts that can be understood and navigated by stakeholders and customers. Once consensus is near, a higher fidelity experience map can be drawn to ensure the big picture view is understood.
We believe that applying specification by example to experience design leads to better digital services for the customer. It focuses service design on concrete customer experience, facilitates communication with real customers, and allows us to cut across business silos. It also provides the ability to test customer experiences from the creative phase to the end of build (including QA) by providing a common language for the experience.
We are still exploring better ways of using specification by example in our work, and are interested in hearing from others who are doing the same. As with experience by design, this post is part of a wider conversation about how to better bridge the communication gap between customers, business, and the delivery of great experiences.
Friday helps ambitious organisations achieve agility at scale. Our strategic engineers and designers develop digital products, services and platforms.
If you are interested in learning more about specification by example, and how you can apply it to your work, the following links are good starting points.
Liz Keogh runs a fantastic blog about topics including specification by example/behaviour driven development. She provided a great articulation of the idea of scenario expansion by context questioning.
Agile Modelling provides a good, if software focused, introduction to the idea of doing just enough documentation and modelling of customer needs to drive delivery forward.
If you prefer video to reading, the annual CukeUp conference has many great talks on applying specification by example. You can find the summary of talks and videos for each conference here: CukeUp 2014, CukeUp 2015.