# data[].attributes.attachment_link.title
Your Guide to Practical Experience Blueprinting

# data[].attributes.body
Our Courses - Scottish Digital Academy

# data[].attributes.attachment_link.readable_text
At present, we fund spaces on courses for core Scottish Government Directorates through corporate recharge allocations which is an internal process. We are able to provide this as our funding is allocated as a corporate offer.
Non Scottish Government
Executive agencies, local authorities, NDPBs and other public sector organisations are required to pay through a recharge and invoice process to cover the cost of training. This recovery model allows us to procure the best value for the public sector on demand, to better address skills gaps at any given time.

The Scottish Digital Academy runs on a cost recovery model. Specialist resource, operational and ad hoc costs need to be recovered.

The charges for attending courses and for using our service are outlined in our Terms and Conditions. All organisations have delegated learning & development budgets and we are only seeking to recover the cost of delivering courses.

We do fund a small selection of agile courses which are free to attend for anyone in the Scottish public or third sectors:

Curious About Agile

Agile Mindsets

Why Agile?

Introduction to Scrum

User Story Mapping

Product Vision and Roadmapping

Sizing and Estimating

Leading in a Digital World

Empowering Women to Lead Cyber Security

Empowering Women to Lead Digital Transformation

We will evolve our funding and cost recovery model during 2022. We'd be more than happy to have a chat with teams about how the Scottish Digital Academy can support any future learning needs.

# data[].attributes.attachment_link.description
At present, we fund spaces on courses for core Scottish Government Directorates through corporate recharge allocations which is an internal process. We are able to provide this as our funding is allocated as a corporate offer.

# data[].attributes.body
The Scottish Approach to Service Design (SAtSD) - gov.scot (www.gov.scot)

# data[].attributes.attachment_link.readable_text
About this resource

Thank you for taking the time to read this short explanation of what you need to know about designing public services in Scotland.

This document will cover:

how a shared set of principles and some basic tools will help us design around the needs of people (and not around how the public sector is structured)

how thinking about people's 'life events' helps us embed that way of working

what we mean by services, design, and users * how you design with, as well as for, your service users - and how to do this in an accessible and inclusive way

how you can assess the maturity of the Scottish Approach to Service Design in your organisation

how to contact us for more information and to provide feedback

This is a framework to guide how we design user-centred public services and not an attempt to create a template/toolkit for designing any service. It's about how we all agree on and support the set of core ideas and intentions we need to build into our organisations to ensure we design the right thing, before designing the thing right.

# data[].attributes.attachment_link.title
The Scottish Approach to Service Design (SAtSD)

# data[].attributes.attachment_link.description
The vision for the Scottish Approach to Service Design is that the people of Scotland are supported and empowered to actively participate in the definition, design and delivery of their public services (from policy making to live service improvement).

# data[].attributes.headline
The Difference between a Journey Map and a Service Blueprint

# data[].attributes.subject
The Difference between a Journey Map and a Service Blueprint

# data[].attributes.body
The difference between a journey map and a service blueprint | by Megan Erin Miller | Practical by Design (practicalservicedesign.com)

# data[].attributes.attachment_link.readable_text
During that college experience, hundreds or thousands of people were working to keep the college running. Hospitals and doctors were providing care making education and support accessible to the soon-to-be parents. The airline, hotel, and cruise companies were working to keep everything they produce and manage working so you can have that vacation experience with as little friction as possible.

Mapping these experiences is a key part of being a human-centered business, and it is important to look at both perspectives - what the person experiences, and what went on outside of their view to make it happen. Customer journey mapping and service blueprinting are two complementary methods that can help us see both sides of our services.

Yet these two methods are often confused; what is a journey map, and what is a service blueprint, and how are they different?

Before we dive in, we need a little context. We need to understand the notion of "the stage" in service design, a cornerstone concept that is essential for understanding the difference between customer journeys and service blueprints. "The stage" is comprised of three perspectives: the front stage, the backstage, and the behind-the-scenes.

The literal metaphor is helpful here. If you imagine a simple stage in a theater, the front stage is where the action happens and what the audience can see; for us, customers act on the front stage.

The backstage is where all the support processes live that produce the front stage, the lights, the sets, the crew, all of which should be invisible to the customer, but often isn't. The backstage is us, the organization and all the things we do to make that front stage happen.

Then there is the behind-the-scenes, where all the intangible things that the organization must do to make both the front and backstage possible. Rules, regulations, policies, budgets; all the things that aren't really a part of either the front or back stage.

These three places are where service design has the opportunity to make an impact. Through different methods, we can better understand different stages. Let's talk about the methods in question.

A journey map captures iconic experiences that customers have, from their point of view; the front stage of the service experience. In creating a journey map, you use customer narratives and customer data to plot their experience over time, mapping what they are doing, thinking, and feeling, and what they are interacting with along the way.

What you end up with is a visceral journey that helps you see and evaluate the experience your customer is having from their point of view.

A good journey tells the story of what the customer went through as a narrative that flows like an author wrote it; the author being the customer. It contains all the richness of the experience - the emotion, the internal dialog, the highs and lows - that a true story would. It's our chance as creators to step into the customer's shoes and "see" how they would experience it. Empathy at its core.

You can create a journey map by interviewing customers to capture their insights, and then map them against each other to find commonalities, patterns, and trends. In addition, you can also piece together a customer journey map from data that is already being collected on the customer experience.

This method helps you map and make visible the end-to-end of the experience a customer has. This is the front stage of the experience, and is comprised of all the interactions they have in the context of their lives and how they interface with your business.

Beyond capturing the current experience your customers are going through, journey mapping can also be used to imagine and ideate on the future, using the format as a tool to speculate on what a customer might see and do in a future experience.

Typically, a journey map is not a depiction of an actual real-world, single customer's experience. A journey map is an aggregate of experiences compiled from customer research and the knowledge of subject-matter experts in your organization.

The nature of how customers traverse the stage is unique to every single customer, but when you aggregate those paths together into a narrative, it helps you see the experience as a journey from the customer's perspective.

This is a powerful storytelling tool that paints a picture and allows people a chance to see something through a common lens. Journey mapping builds empathy and also lets you identify areas of the experience that you want to improve or learn more about.

Now let's turn to service blueprinting. Where journey mapping focuses on exposing the end-to-end of your customer's front stage experience, blueprinting focuses on exposing the surface-to-core of the business that makes up the backstage and behind the scenes of how you deliver and operate, and ties that to the customer's experience.

What journey maps and customer narratives don't show is the internal workings of the organization. The service blueprint seeks to uncover and document (often for the first time!) all the things that go on beneath the surface and the internal makeup of the organization that creates it. It is data visualization of how your company works; the deep, dark inner workings of how the things a customer experiences are actually produced.

There are huge complexities that go unseen that are the support structures beneath every journey - the responsibilities of the internal actors, the systems that support those actors, all the processes and policies that dictate what can and cannot be done. Service blueprinting shows you a picture that not only includes the breadth of what happens along the journey, but all the depth that makes up the substance that the journey traverses across.

To create a service blueprint, you first need to have identified one or more end-to-end journeys, called scenarios, that you want to blueprint. These scenarios should be based in the customer journey, but can also include organizational scenarios that happen internally away from the customer's view. It is the story of what happens at each step along the way to make the scenario "go."

By going deep into each step in the scenario, you can expose the breadth and depth of the experience that supports and produces the stage where the journey takes place. This process relies on a cross-functional collaboration between different parts of the organization, in order to represent all aspects of the external and internal experience.

The end results is a complete picture of how the experience is delivered, end-to-end and surface-to-core. It is a powerful document that simultaneously gives you a high level view of the experience, and at the same time a detailed view into what is going on under the surface, moment-to-moment. Without this comprehensive surface-to-core view of who we are as an organization and our part in this journey we are creating, we can't make meaningful changes to how we serve our customers.

While journey mapping can help you document surface customer experiences, service blueprinting helps you "evidence" the reality of your organization. The fundamental value a blueprint provides is an objective picture, based in the reality of how your organization delivers, what they deliver, and the end-to-end view of how it is orchestrated.

There are many journeys and many customers, but there's only one of your business, only one collection of systems, policies, and actors that make up what you offer. That is what the blueprint uncovers; the backstage that is used over and over again by the customers. We map customer experiences all the time, but rarely do we take the time to map out and document our own businesses.

An experience is only as cohesive as the teams that produce it, and any attempt to make meaningful changes to an experience requires a deep understanding of the makeup of the organization that builds the stage for that experience. Blueprinting is not about documenting the customer experience. It uses the customer experience as starting point, and unpacks it to expose how the organization supports that journey.

This is why a blueprint can seem detached from the customer and detached from the empathy that designers are told again and again is the top priority. It's important to point out that the blueprint doesn't seek to remove the empathetic aspect of design, and is not in conflict with a journey map's purpose - it is simply focusing on a different dimension of that experience; the substrate it is created from. It is the objective answer to the question of "What does our organization consist of, both tangibly and intangibly, that allows these journeys to exist?"

A customer journey can only exist on what an organization can deliver; it is confined to and constrained by your internal capability. By taking a big step back and using the blueprint to truly see the end-to-end and surface-to-core all together as one, it grants you the freedom to then make big or small changes to how your organization delivers, which results in the improvement and evolution of the customer journeys it supports.

If you don't have an understanding of how your customers are experiencing what you offer, then journey mapping is a great way to uncover that, make it tangible for your organization, and build empathy around the customer.

A journey can tell a rich story about what happens to a person that is hard to capture if it's not turned into a narrative. That narrative is a powerful tool to rally a group around true human-centered design, and that can be an end unto itself.

If you already have a good understanding of your customer experience, or identified a particular pain point for the customer or the internal teams, then blueprinting should be your next step.

It will allow you to dive deep into how you deliver an experience and how your organization functions (for better or worse), allowing you to address organizational pain and breakdown of processes internally. The cross-functional collaboration it fosters brings diverse organizational knowledge into a central place for the first time.

However, don't just go chasing customer pain. There are cases when a customer's experience can be perfectly delightful, but behind-the-scenes the organization is going to great lengths to patch it together and maintain the appearance of cohesion.

In reality, you might be losing tremendous amounts of time, money, and employee moral by maintaining a great customer experience by using inefficient and painful internal processes. In cases like these, you might consider using the journey mapping tool to map the emotional experiences of your internal actors in order to understand organizational pain, challenges, and opportunities for improvement.

Blueprinting is an obvious must in these cases, because it will help you understand the complexities of your organization, and let you tie underlying factors to a customer journey so that you don't lose sight of how future changes - in the form of reduced costs, increased efficiency, boosted moral, and the overall health of the business itself - might impact the customer.

We have to pay attention to these internal organizational experiences just as much as we pay attention to the customer experience.

Journey mapping and service blueprinting are both critical methods to understand and use in doing service design work. It is important to understand the difference between the two, and how they compliment each other. Journey mapping is about a front stage lens through which to better understand and empathize with the customer's experience.

Blueprinting is about the backstage (and behind-the-scenes) of your business and how that backstage ties to the customer's experience. Whether you are seeking deeper understanding of the experience your organization has created, or a deep analysis of your business, these methods will help you identify ways to create meaningful improvements to your internal processes and your customer's experiences.

The next time you look at a customer journey, try digging beneath the surface to look down to the core of what is supporting that journey. Understanding how it all adds up to create that surface customer journey means now you know. And knowing is half the battle.
If you like this article, please go get our guide on Practical Service Blueprinting!
Continue reading:

You should give this article a 👏🏻 or 50, follow Erik Flowers and Megan Erin Miller on Medium, and on Twitter @erik_flowers and @meganerinmiller!

# data[].attributes.attachment_link.title
The difference between a journey map and a service blueprint

# data[].attributes.attachment_link.description
Everything that happens in our lives is a type of journey. It might be a journey that spans a few minutes, a few years, or an entire lifetime. It could be going to college, the birth of your first...

# data[].attributes.body
Creating an experience map - Service Manual - GOV.UK (www.gov.uk)

# data[].attributes.attachment_link.readable_text
Experience maps provide a visual representation of what users do, think and feel over time, from the point they start needing a service to when they stop using it.

Speaking to a range of users will help you understand all the events, transactions and related services they may experience throughout their journey. Consolidating these into a single map will help you to understand:

how users experience the current service

how things work (or don't)

interdependencies - for example, between different departments or services

pain points and where things are broken

When to use experience mapping

Experience mapping works best for services that take place over several weeks or months (for example, applying to become a UK citizen or setting up a business) and involve:

lots of separate steps or events

more than one location - for example home, a departmental office, the post office

different people or teams

several related services or service touchpoints

Steps to follow

Create experience maps with your team so that everyone can learn more about your users.

Preparation

You need to capture the experience of several users before you create an experience map. Once you've done this:

choose a quiet location with a wall (or table) large enough for you to arrange your cards and create a map

invite your team to help - reviewing users' experiences will help them make decisions about how to design and build the service

gather the event cards you used to capture users' experiences and stacks of different coloured sticky notes or index cards

decide a colour-coding scheme for your sticky notes - for example, blue for journey stages, yellow for steps in a process, green and red for emotional high and lows

Identify common stages

Start by:

laying out event cards for each participant in a row

line up common events

break the rows into stages

name each stage you've identified - use your colour-coded sticky notes to remind people that your aim at this point is to create a simple map - it's ok to start with only a few stages and iterate as you understand more

Once you've laid out your users' journeys, decide how many maps to create. You should:

create one consolidated map if all your research participants went through the same stages and similar steps

create separate maps for different user groups if participants went through different stages and significantly different steps

Build up the experience

Once you've established the stages you want to include, you need to add the steps involved in each. Together, these will form the 'spine' of the experience.

You can add to this by extracting important information from event cards. Look for evidence of:

emotional highs and lows - record these on different coloured sticky notes and add relevant quotes

people's reactions and thought processes

service touchpoints

which channels the service is delivered through

user needs at specific stages

You can also add photos and artefacts collected during your research.

Live with the map

Once you've created a draft map, move it to your team area. Over the next few days or week:

talk it over with your team

show it to lots of people - for example, people who observed your research with users, teams who deliver parts of your service, other researchers

review, rearrange, rename and reword things until you're happy the map is both clear and accurately reflects your users' experience

Draw a detailed map

Once you're happy with your draft map:

draw it in your preferred graphics application

print it at large scale and stick it on a wall in your team area

Your map can be based on a simple grid design that shows the stages, steps and activities your users experience over time.

Use your map to structure discussions about your users' experience and how you're working to improve it.

Most people outside your team won't be interested in detail, so make a summary map that you can share. This should:

just show stages and key findings for each stage

include a few images and quotes

be self-explanatory - you shouldn't have to explain it further

be easy to read on both screen and paper

Examples of experience maps

You might find the following blog posts about experience mapping useful:

You may also find the Plan a round of user research guide useful.

# data[].attributes.attachment_link.description
Experience maps provide a visual representation of what users do, think and feel over time, from the point they start needing a service to when they stop using it. Speaking to a range of users will help you understand all the events, transactions and related services they may experience throughout their journey.

# data[].attributes.body
User research - Service Manual - GOV.UK (www.gov.uk)

# data[].attributes.attachment_link.readable_text
We use some essential cookies to make this website work.

We'd like to set additional cookies to understand how you use GOV.UK, remember your settings and improve government services.

We also use cookies set by other sites to help us deliver content from their services.

# data[].attributes.attachment_link.description
We use some essential cookies to make this website work. We'd like to set additional cookies to understand how you use GOV.UK, remember your settings and improve government services. We also use cookies set by other sites to help us deliver content from their services.

# data[].attributes.body
Launching the new Policy Lab prospectus - Policy Lab (blog.gov.uk)

# data[].attributes.attachment_link.readable_text
At the heart of the Lab's work is a mission to "radically improve policy making through design, innovation and people-centred approaches." The team now has a track record of more than 180 policy innovation and development projects delivered in almost every government department.

From the and care review to autonomous ships, our work brings new voices into the debate and leads to real impact.

We bring leading edge approaches to policymaking into the heart of government. Over the past eight years we have pioneered the use of policy design, ethnography, systems thinking and collective intelligence. Our new innovation strategy means there is more to come.

The prospectus is the first time we have brought our offer together into a single document. It sets out how we can bring our multidisciplinary expertise to bear on the challenges faced by policymakers within and beyond the Civil Service, as our work expands into local government and the wider public sector.

If you would like to commission us, partner with us or learn more about our work please get in touch: team@policylab.gov.uk

Director of Transformation and Policy Capability, Department for Education

# data[].attributes.attachment_link.description
At the heart of the Lab's work is a mission to "radically improve policy making through design, innovation and people-centred approaches." The team now has a track record of more than 180 policy innovation and development projects delivered in almost every government department.

# data[].attributes.body
User Story Mapping – Help your organization focus on successful outcomes (jpattonassociates.com)

# data[].attributes.attachment_link.readable_text
Story mapping is a better way to work with Agile user stories

User Story Mapping is a dead simple idea. Talk about the user's journey through your product by building a simple model that tells your user's story as you do. It turns out this simple idea makes working with user stories in agile development a lot easier.

More importantly it'll keep your users and what they're doing with your product front and center in your products. That's better than getting lost in feature arguments - like what normally happens in software development. I'm not making any promises here, but if you use Story Mapping, I believe your products will ultimately be better.

From this page you can get to a number of resources on and off this site that'll help you with story mapping.

# data[].attributes.attachment_link.description
User Story Mapping is a dead simple idea. Talk about the user's journey through your product by building a simple model that tells your user's story as you do. It turns out this simple idea makes working with user stories in agile development a lot easier.

# data[].attributes.body
Writing user stories - Service Manual - GOV.UK (www.gov.uk)

# data[].attributes.attachment_link.description
User stories describe a user and the reason why they need to use the service you're building. You must use user stories when building your service - they're essential to building and running a service that meets user needs.

# data[].attributes.body
NHS Tayside (scot.nhs.uk)

# data[].attributes.body
What Is Story Mapping? | Agile User Stories | Create A Story Map (digite.com)

# data[].attributes.attachment_link.readable_text
You stare at your laptop. A long list of user stories stares back at you. You shuffle some around, trying to put them in a sensible order.

You constantly re-sort the list. Either to see all stories related to feature A, or to see the most important stories across all features. If that's even possible.

Time and again, you get lost.

What you need is a Story Map. Let's see how you create one using Story Mapping, but first, let's dig into what they are.

Let's Dive:

Story Mapping in Agile - What Is (User) Story Mapping?

Story Mapping or User Story Mapping is a technique used in product discovery: outlining a new product or a new feature for an existing product.

The result is a Story Map: all the user stories arranged in functional groups. This helps you keep your eye on the big picture while also providing all the details of the whole application.

What's the Purpose of Story Mapping?

The main purpose of Story Mapping is to facilitate product discovery and prioritization of development work. You achieve this by putting user activities and tasks on a map that serves to keep them in context.

The Story Map always shows how each individual story fits in the whole application. And this makes it easy to spot gaps and decide how important one is over another.

What agile values and principles does story mapping support?

Story Mapping supports two values of the Agile Manifesto. " Customer collaboration over contract negotiation" and " Responding to change over following a plan ".

You get the best results when you collaborate with a (future) user or a domain expert. Someone who is intimately familiar with the work that your application is to support and the problems it's to solve.

Using Story Mapping, it's easy to respond to change. Because when you add a new user story, or you change or remove an existing one, it's easy to spot what else needs to be added, changed, or removed.

Who Created Story Mapping?

Jeff Patton first described Story Mapping in his " It's All in How You Slice it" article in 2005 when he'd already been using it for a couple of years. But he didn't call it Story Mapping then. He coined that term in his " The New User Story Backlog Is a Map" article of 2008. He also wrote a book about it: " User Story Mapping: Discover the Whole Story, Build the Right Product ".

Why Use Story Mapping? - What Problems Does Story Mapping Solve?

When you finish your product discovery, you'll likely put the user stories into the backlog of a Scrum or Kanban board.

That's fine to drive the development effort once you've decided on the build order.

However, the backlog management capabilities of these tools fall short for product and release management. Simply because the backlog is shown as a long, flat list. The filtering, labeling, and coloring you can do, helps a bit, but you never get the whole picture.

Story Mapping solves this by arranging user stories in a simple helpful layout.

What (Other) Benefits Do You Get Out of Story Mapping?

Story Mapping gives you a number of direct and indirect benefits.

Everyone can easily understand the whole application-generally the most difficult part of software development. The Story Map tells the story of what your application solves and how it does it for anyone who's interested. Everyone can participate in creating it.

You keep the big picture of your application in full view-losing the big picture is a common complaint in agile teams.

Putting together and having a Story Map visible encourages iterative and incremental development.

Having the big picture at your fingertips

shows you where a user story fits in the whole system in a single glance.

helps you decide what to build first. A Story Map makes it easy to pick and choose user stories from different features that together will provide meaningful value. This means you can confidently determine the scope of and build an MVP or a useful release.

means you can more easily avoid building something that doesn't work. You won't get lost or forget important parts that would effectively render it unusable, like a car without brakes. For example, because you delayed low-value stories that your high-value stories depend on.

lets you walk the Story Map to test it for gaps: spot more easily where something is missing.

lets you make prioritization decisions taking the context of the whole system into account.

means you'll avoid staring yourself blind on a single user story.

When you create a physical Story Map, you get some more benefits.

The map becomes a focal point for collaboration and helps shared understanding.

The full context provided by the map helps to quickly size user stories relative to each other.

You can add smaller stickies to user story cards to add extra information or mark stories for the current and next iteration.

Pitfalls and Mistakes

The most important pitfalls and mistakes with Story Mapping are:

Working without a customer or someone intimately familiar with their work

You need to collaborate with someone that uses or will use your product to support their work.

Without their input and perspective, you'll be guessing at what's important and what'll provide real value. You'll be playing a hit and miss game and will likely waste development effort.

Working without a problem to solve, a goal to reach, you have nothing to guide your decisions and you'll have no idea when you're done. Leading to wasted effort, or at least to expending effort on something at the wrong time.

Out of sight, out of mind. Without the Story Map serving as a visible reminder of your application's big picture, veering off course is all too easy. As is the danger of getting lost in the weeds: getting caught up in the details of a single story that are irrelevant for the whole. This hurts even more, when those details would take more effort than the value of the story merits.

While a physical Story Map is preferable for the extra benefits it provides, with so many remote teams nowadays, you won't always have that luxury. But you can still keep it highly visible. You can for example have a dedicated, large monitor showing the map in every location where you have team members.

How to Create a Story Map in 6 Steps (With Examples)?

1. Start With the Big Boulders

Identify the big stories, the broad user activities that your application needs to support. They're big stories because they have many steps. These steps don't need to have a specific order or workflow. In fact, many user activities have steps that a user will do at different times and on different schedules.

Write each activity on a card. Arrange them in an order that makes sense to the user. If someone talks about doing one activity and then another, arrange them in that order. If activities aren't done one after the other, simply use the order the user talks about them. That'll help telling the story of the application to others.

Let's say you're building a Fun Events Club site. Visitors can look for fun events to join. Members can join and host events. And the team behind the site serve as moderators and check if new events are within the guidelines.

The big boulders of this site, the user-activities, could then look like this.

2. Crack Your Boulders Open

Break down the story of each user activity into smaller stories, the user tasks. Put the user tasks under the activity they belong to and arrange them in the same direction as the activities and in the order that makes sense to the user.

For the Fun Events Club, that looks like this.

You now have what's called the backbone of your Story Map.

Most user tasks have steps or independent subtasks of their own. You put these subtasks under (if you were going horizontally) the user task to which they belong.

That looks like this.

Both user tasks and subtasks become the user stories you'll implement. After all, a user still needs to select an event from a list to view its details or join it immediately.

3. Find the Pebbles That Got Away

Walk the map from beginning to end with someone else at your side. This can be a user, a developer, a tester, or someone else with a stake in the application.

Talk about the (types of) user of your application and how they're using your application. It's a sort of rubber duck debugging for your Story Map. And it'll quite naturally bring out things you've missed. Either because you think of them yourself, or because your companion points them out.

It turns out that for the Fun Events Club, we missed quite a few.

When you're walking the map with someone, take the opportunity to annotate the Story Map with other information you hear. Pain points in the current system, opportunities a user's been waiting for. Edge cases and constraints you need to take into account. Write them on a sticky and stick them on the relevant card.

4. Put Your Pebbles in Line

There's little sense in prioritizing the user activities. Apart from activities that won't be used daily, it's highly likely that something from each activity is needed to create a working whole.

So focus on prioritizing user tasks and subtasks within each activity. Added advantage is that you don't need to think about the relative importance of tasks belonging to different activities.

In our Fun Events Club example, the subtasks are already in order of importance. A bit of premature optimization by your author.

5. Sculpt a Valuable First Boulder From Your Pebble Piles

Select the tasks from each activity that are essential to create a first version that works end-to-end even if it's still in a very rudimentary way. That's your MVP, your Minimum Viable Product.

6. Continue Sculpting

Plan your subsequent releases by prioritizing the remaining tasks. It's entirely up to you how you want to move forward.

You can opt to prioritize the highest value stories from several or even all user activities. You can also opt to focus on a single activity and prioritize all but the lowest valued stories. And maybe the business people in your company want to take other aspects into consideration. They are in the best position to decide what features and stories make a good release.

Rather than drawing lines between the stories to mark which ones go into subsequent releases, you can also rearrange the map to show releases as horizontal spans of stories.

src: moqups.com

Using Story Mapping With Existing Applications

Story Mapping is not just for new applications. You can use it for existing applications as well.

To help you understand what an application does and recreate its big picture so you can take advantage of having that when moving forward.

And of course to map out new features and put them in context with the existing application.

If you can't (aren't allowed) to build a full Story Map of the existing application first, at least get all the existing user activities in place.

This'll give you the context for new features.

And it'll also give you a place to put the tasks you need to add or change in existing user activities. For example, when you create a new feature to send out targeted emails. You'll need to add selecting multiple contacts in the existing contacts list. And you'll probably need to add some extra filtering capabilities there as well.

Become a Storyteller

Remember the pain of having to prioritize stories in a long, flat backlog?

And how difficult it was to explain the application to other people?

You know now how Story Mapping can help you. To prioritize stories and assemble releases that deliver meaningful value. And to tell the story of your application as users will use it. Simply by walking the Story Map.

So, make your future self happy, and take advantage of Story Mapping. On a wall, or with a digital tool. For example, with Digité's Story Mapping.

# data[].attributes.attachment_link.title
What Is Story Mapping? | Agile User Stories | Create A Story Map

# data[].attributes.attachment_link.description
Agile methodologies are approaches to product development that are aligned with the values ​​and principles described in the Agile Manifesto for software development. Agile methodologies aim to deliver the right product, with incremental and frequent delivery of small chunks of functionality, through small cross-functional self-organizing teams, enabling frequent customer feedback and course correction as needed.

# data[].attributes.headline
Digital Fundamentals for Public Impact [Apolitical Webinar]

# data[].attributes.subject
Digital Fundamentals for Public Impact [Apolitical Webinar]

# data[].attributes.body
Digital fundamentals for public impact.mp4 on Vimeo

# data[].attributes.attachment_link.title
Digital fundamentals for public impact.mp4

# data[].attributes.headline
Digital Personas - Inclusive Design Toolkit

# data[].attributes.subject
Digital Personas - Inclusive Design Toolkit

# data[].attributes.body
Digital personas (inclusivedesigntoolkit.com)

# data[].attributes.headline
Glasgow School of Art Online Resource Lists

# data[].attributes.subject
Glasgow School of Art Online Resource Lists

# data[].attributes.body
KeyLinks GSA

# data[].attributes.headline
Dark Matter and Trojan Horses: A Strategic Design Vocabulary (Medium Article)

# data[].attributes.subject
Dark Matter and Trojan Horses: A Strategic Design Vocabulary (Medium Article)

# data[].attributes.body
Dark Matter and Trojan Horses: A Strategic Design Vocabulary | by Dan Hill | Dark Matter and Trojan Horses | Medium

# data[].attributes.attachment_link.readable_text
What connects Bryan Ferry and Cedric Price, dark matter and Hitchcock's "Macguffin", Trojan Horses and iPhones, 21st century social contracts and street food, the Brisbane floods and the UK riots, Occupy Everywhere and institutional redesign, whilst making bold claims about a relevant future for design and finding time for a quick pop at the "design thinking" movement?
A couple of weeks ago Russell Davies sent me a review of a talk by writer Neal Stephenson. Russell was aware of my interest in appropriating the concept of 'dark matter' after I floated the idea at Arkwright's Mill last summer, for our Laptops and Looms event.

In fact, said Stephenson, we already have much of the fundamental technology we need to fulfil such science fiction ambitions as large scale solar power production, or routine space flight. Instead, he said, we need to start looking at the non-technological obstacles to these advances, citing insurance as a key example. The development of alternative space launch systems has been curtailed by the unwillingness of the insurance industry to underwrite satellite launches on systems for which there is no good model of the risk involved. Turning to the audience of mostly MIT students, Stephenson said "maybe some of you people need to go into the insurance industry instead of writing code." The response was nervous laughter.

"Nervous laughter". That's often a sign that an edge has been detected, that we're in uncharted waters, that we're beyond precedent or habit, outside our comfort zone.

Funnily enough, that kind of response is partly why we pursue strategic design at Sitra, as Stephenson is describing a kind of practice with includes redesigning contexts - in this case, organisations, insurance and legislation - rather than solely addressing "technology". And few people are genuinely trying to connect these things together; to understand, clarify and address complex opportunities holistically. Stephenson understands that the problem is rarely technology - or "the idea" - but it is the surrounding context, the thing that makes something happen. Or not. And we need to design that context if we want, say, large scale solar production to happen.

So I've written a short book, called Dark Matter & Trojan Horses: A Strategic Design Vocabulary, to begin to sketch this emerging area for design. It would be lovely if you found the time to read and assess, critique or discuss, and ideally, appropriate.

Here's the synopsis of the essay from the Strelka Press website:

We live in an age of wicked problems, whether it's climate change or the decline of the welfare state. With conventional solutions failing, a new culture of decision-making is called for. Strategic design is about applying the principles of traditional design to "big picture" systemic challenges such as healthcare, education and climate change. It redefines how problems are approached and aims to deliver more resilient solutions. In this short book, Dan Hill outlines a new vocabulary of design, one that needs to be smuggled into the upper echelons of power. He asserts that, increasingly, effective design means engaging with the messy politics - the "dark matter" - taking place above the designer's head. And that may mean redesigning the organisation that hires you.

Those are not my words, but in my essay I'd argue this is a good place for design to be. In fact, it might be the best place for design, if not the only place that design can genuinely make a difference.

I also argue that we desperately need to make a difference, given last year's "Peak News" events, from the focused and organised incursions of Occupy Everywhere to the unprecedented, emergent and chaotic UK riots, from the rapid sweeps of the Arab Spring to the numbing stasis of the Eurozone Crisis, from the party-political-posturing stand-off over budget ceilings in Washington DC to the very real stand-offs in the streets of Moscow. When I wrote the essay (November-December 2011) Italy and Greece, both cornerstones of European civilisation, where being run by unelected technocrats, an implicit challenge to the very idea of democracy itself.

What on earth does design have to do with all this? Well, read the essay ... but given that we are approaching these new kinds of issues - these deep stress fractures in our established cultures of decision-making - in exactly the same way we approached older, simpler problems, we should not be surprised that they are no longer working. Should we not be exploring different responses, developing frameworks more attuned to thinking holistically, to collaboration, to prototyping and iteration, deploying synthesis rather than simple analysis?

Equally, the essay suggests we have to make a more meaningful case for design - without which we are largely left "sticking lipstick on the pig", as we charmingly say in Britain. Architecture, for example, is horribly, almost fatally constrained by its current positioning and practice. Its inability to reinvent its context, its industry, its practice and its purpose means it continues to fall far, far short of the claims it makes for itself, and indeed its true potential. (With some very honorable exceptions.) And much the same could be said for much of the rest of design. So design has problems of its own to solve too.

Lest this all sound a little turgid, note that all of the characters mentioned in the first line above are in there, along with others. And yes, it makes the time for a little critique of the 'design thinking' movement, and to some extent questions the efficacy of the design consultancy model.

Where the first book from SDU concentrated on the idea of using the studio concept to open up the right questions, this essay is a bridge, concentrating more on "what next?" How do you get things done, in this kind of different context for design?

We call this facet of design 'stewardship' in the team, and the essay is framed as a sort of tentative playbook of tactics, strategies and other approaches that might trigger useful thoughts, adaptations or discussions (Note it is not the kind of playbook that is to be simply enacted, but one to be interpreted.)

So, for instance, such plays include basic tactics for addressing ' dark matter ', such as appropriating the ideas of the Trojan Horse or Alfred Hitchcock's MacGuffin for the Low2No sustainable development competition. And yes, there's an anecdote in there about how Bryan Ferry gave me some of the best - well, most succinct anyway - design advice I ever received.

For more of a flavour, I'll shortly post a couple of off-cuts which didn't make the final e-book.

The essay is published as part of the splendid new e-books series on Strelka Press. Strelka is one of the sharpest new(ish) design schools in Europe, and the series is edited by the excellent Justin McGuirk. I was happy to be in good company, with other texts by some of my favourite writers, including Keller Easterling, Owen Hatherley, Sam Jacob, Alexandra Lange, Julia Lovell, and Justin himself.

As with much of Strelka's activities, the format of the series is also an experiment. I haven't had much to do with the model, but it's pitched at a price-point accessible to students whilst, through Amazon, making the discourse widely available outside of the school, which opens up the possibility of further readers for the Bryan Ferry anecdote I've shoehorned in there.

The series also looks great on e-book apps, by the way- credit to OK/RM for their graphic design; it hints at what one might be able to do with cover design in this format:

Thanks to Strelka Press for publishing the series. And many, many thanks to Justin for asking me to write it in the first place, and to both him and Chris Hall for their patient, careful and insightful editing. And thanks to Sitra, and particularly my colleagues Bryan Boyer, Justin Cook and Marco Steinberg.

And finally, thanks also to Bryan Ferry, of course. Now for the product placement, at Amazon.co.uk, Amazon.com, Apple, Barnes & Noble, and The Great British Bookshop.

# data[].attributes.attachment_link.title
Dark Matter and Trojan Horses: A Strategic Design Vocabulary

# data[].attributes.attachment_link.description
What connects Bryan Ferry and Cedric Price, dark matter and Hitchcock's "Macguffin", Trojan Horses and iPhones, 21st century social contracts and street food, the Brisbane floods and the UK riots, Occupy Everywhere and institutional redesign, whilst making bold claims about a relevant future for design and finding time for a quick pop at the "design thinking" movement?

# data[].attributes.body
Creative Agency of Misfit Geniuses (snask.com)

# data[].attributes.attachment_link.readable_text
A creative agency of misfit geniuses.

We are Snask and we are your future romance. A creative agency of misfit geniuses conquering the world through fine lookin' design and real emotions. To worry about what people think of us is a waste of time. As long as we stay true to ourselves, we are living our dream. We see love as the only way forward, and we will never sell out or abandon our values. Standing up for our opinions and beliefs is the only way we know. We walk with our backs straight on the path to pursuing our truth. With one foot in front of the other, we seek to challenge conservative frameworks. We are doctors of disturbance, wizards of disruption and spokesmen of disobedience. We assume the responsibility to stay engaged, give a damn, and strive for empathy. There is a short word for this assumption of responsibility: Snask.

The SNASK Manifesto

01/ If you don't like your job - quit.

02/ If you love someone - let it show.

03/ Generosity always pays itself back.

04/ Always achieve greatness yourself before pointing out the faults and mistakes of others.

05/ Bureaucracy is spelled Bureaucrazy.

06/ Talk with clients like you talk to your family, friends and pets.

07/ Social skills are as important as being good at setting type or knowing how to spell.

08/ See people as people, not as target groups.

09/ Just because you wear a black suit, doesn't mean you're a goddamn professional.

10/ Having enemies is a good thing. It proves that you stood up for something sometime in your life.

Make Enemies & Gain Fans: The true and unraveling story about SNASK

Written in 72 hours, this is an action-packed journey of our first five years in the business. The story of how we started to paint the world pink and realized that we do it pretty damn well. It is an action-packed journey about making it big through branding, pink lies, bold ideas, great design and loads of fun. Praised by design gurus as well as business owners and management consultants. Now out in an all gold 2nd edition with extra content, updated cases and new outro, even though the gold cover really is the deal breaker! Read it now!
Buy our book!

South America. Asia.
Europe. North America.
Africa.
Next stop: Australia

The world was ruled by grumpy old men desperately clinging to power, but then along came SNASK with a whole load of fresh new thinking. Our lecture destroys the myths about being "creative" as well as giving you our perfectly honest story about taking risks, fucking up and reaching success. We get booked to talk about creative entrepreneurship at the world's biggest conferences. So if you can cough up the cash we'll come and make your school, conference or company go wild for a night and be inspired for months (we take no responsibility if someone quits their job straight after our lecture).

UPCOMING:

23/03/2023 - OFFF, Barcelona, Spain

10/11/2022 - University of Indiana, Indianapolis, USA

27/10/2022 - Kikk, Namur, Belgium

PREVIOUS talks 2011-21:

29/09/2022 - Paradigms, Barcelona, Spain

30/05/2022 - Billy Blue, Sydney, Australia

27/05/2022 - Semipermanent, Sydney, Australia

08/11/2021 - Norwegian Government, Son, Norway

29/10/2021 - Arla The Barn, Viby, Denmark

09/11/2020 - Design Thinkers Conference Virtual, RGD

09/11/2019 - Eastern Conf, Kosice, Slovakia

29/05/2019 - Blanc Festival, Barcelona, Spain

29/05/2019 - The Design Conf, Brisbane, Australia

23/05/2019 - Billy Blue, Sydney, Australia

21/05/2019 - Billy Blue, Melbourne, Australia

18/04/2019 - The Crop, Baton Rouge, USA

29/03/2019 - Sabla Bra, Kristiansand, Norway

07/12/2018 - Design vs Music, Tromsö, Norway

09/11/2018 - EPDA, Paris, France

27/09/2018 - SuperNova, Antwerpen, Belgium

16/09/2018 - Designtrend, Moscow, Russia

03/06/2018 - Play Media Day, Banja Luka, Bosnia and Herzegovina

13/03/2018 - SXSW, Austin, USA

08/02/2018 - Bergen Marknedssymposium, Bergen, Norway

01/11/2017 - Creativity World Forum, Aarhus, Denmark

06/10/2017 - Something Good, Bristol, UK

16/09/2017 - GATHER Festival, Stockholm, Sweden

06/09/2017 - Nordic Design, Stockholm, Sweden

29/07/2017 - Freaky Summer Party, Minsk, Belarus

15/06/2017 - Forward Festival, Munich, Germany

17/06/2017 - Forward Festival, Zurich, Switzerland

06/06/2017 - Days of Communication, Bogóta, Colombia

11/05/2017 - AdDay, Stockholm, Sweden

20/04/2017 - Forward Festival, Vienna, Austria

01/04/2017 - Days of Communication, Rovinj, Croatia

28/03/2017 - Bang For The Buck, Stockholm, Sweden

17/03/2017 - FID, San José, Costa Rica

07/03/2017 - Vuoden Huiput Festival, Helsinki, Finland

3/11/2016 - Designthinkers, Toronto, Canada

30/06/2016 - Typo Circle, London, UK

18/06/2016 - Cannes Lions, Cannes, France

21/05/2016 - HOW Design Live/The Dieline, Atlanta, USA

18/02/2016 - Design InDaba, Cape Town, South Africa

24/9/2015 - Brand New Conference, New York, USA

18/5/2015 - OFFF Barcelona, Barcelona, Spain

24/3/2015 - ING: Conference, Dubai, United Arab Emirates

07/3/2015 - OFFSET 2015, Dublin, Ireland

9/1/2015 - Dropbox, California, USA

8/1/2015 - Stanford University, California, USA

6/1/2015 - Google HQ, California, USA

11/5/2014 - iMD14 Media Confe rence, St Gallen, Switzerland

18/5/2014 - By Design Conference, Bratislava, Slovakia

15/5/2014 - TYPO BERLIN, Berlin, Germany

18/10/2012 - DesignFest, Guadalajara, Mexico

6/10/2012 - We Love Graphic Design, Copenhagen, Denmark

17/5/2012- OFFF!, Barcelona, Spain

08/12/2011- Scandinavian Design, Shenzhen, China

You're too nice people!

SNASK is like Disneyland for graphic designers

Noura Andrea Nassar, Student.

The guys from SNASK have it all: Humor, talent, their own gold book, a pink bike, and the ability to drink me under the table. These are all incredibly rare things. They make me jealous.

Jessica Walsh, Partner at Sagmeister&Walsh

These guys are the designers we all want to be: fun, irreverent, and fucking excellent at what they do.

Thomas Both, Designer at the Hasso Plattner Institute of Design at Stanford

# data[].attributes.attachment_link.description
We are Snask and we are your future romance. A creative agency of misfit geniuses conquering the world through fine lookin' design and real emotions. To worry about what people think of us is a waste of time. As long as we stay true to ourselves, we are living our dream.

# data[].attributes.body
Radical Help – Hilary Cottam

# data[].attributes.attachment_link.readable_text
Radical Help is about new ways of organising living and growing that have been developed with communities across Britain.

The British welfare state transformed our lives. The model was emulated globally, setting the template for the ways we think about social change across the world. But this once brilliant innovation can no longer help us face the challenges of today.

Radical Help argues that our 20th century system is beyond reform and suggests a new model for this century: ways of supporting the young and the old, those who are unwell and those who seek good work At the heart of this new way of working is human connection. When people feel supported by strong human relationships change happens. And when we design new systems that make this sort of collaboration feel simple and easy people want to join in.

Radical Help shows how we can make change and how we can make a transition now towards a new system that can take care of everyone.

UK readers can order a book here. US readers can order here. The Danish translation Radikal Hjaelp is available here.

An Introduction to Radical Help: presentations and articles

For a brief introduction to some of the ideas in Radical Help you can watch Hilary speaking about the book at its London launch at the RSA here.

The following are some of the articles and comment pieces written by Hilary on Radical Help published in the Huffington Post , the Guardian and the Financial Times.

Reviews and Comment on Radical Help

Jonathan Freedland called Radical Help 'the most important book you [will] read this year. In 2019 he wrote in the Guardian that Radical Help was 'the idea that could transform Britain'.

In the New York Times, David Brooks called Radical Help ' mind-shifting ' writing that Cottam is showing the way to a welfare system of the future.

Nicholas Timmins, the biographer of the welfare state, wrote ' Humane and beautifully written... there are powerful ideas here. This book should be required reading for every politician, professional and manager who seeks to make the UK a better place.' Prospect

Melissa Benn wrote ' Cottam's ideas could transform the way we all live. She is onto something exciting in her insistence on the potential of both relationships and new technology to sustain long-term human prospering'. New Statesman

Anne-Marie Slaughter hailed Radical Help as 'the most important book I have read in the last decade. A must-read for everyone who believes that we can make a measurable and lasting difference in the lives of our fellow human beings, even those who may seem hardest to help. The former Director of Policy and Planning for the US State Department and CEO of New America wrote further on the importance of the participatory methods used in Radical Help in The Stanford Social Innovation Review.

Nicolas Colin wrote 'In the great tradition of British social innovation - from Robert Owen to William Morris - Cottam's optimistic vision shows how we could reinvent the welfare state. Not a utopia but a promise'. Le Monde

Kate Raworth, author of Doughnut Economics wrote 'One of my very top reads. If you care about the future of the welfare state and the role of human relationships, I deeply recommend it. Set in the UK, relevant everywhere'.

Frederic Laloux, author of Reinventing Organisations wrote 'One of the rare books capable of making an impact on society. It's the most exciting thing I've read in years.'

Paola Antonelli, Senior Curator at MOMA wrote, 'One of the principles behind great design is to be radical. In this indispensable volume Cottam explains the approach she has pioneered - Social Design'.

# data[].attributes.attachment_link.description
Radical Help is about new ways of organising living and growing that have been developed with communities across Britain. The British welfare state transformed our lives. The model was emulated globally, setting the template for the ways we think about social change across the world.

# data[].attributes.body
Good Services

# data[].attributes.attachment_link.readable_text
Our programmes of training are for everyone

Whether you work in a digital team, operational role, on public facing services or are leading an organisation, everyone has a role in shaping how services work

# data[].attributes.attachment_link.description
Our programmes of training are for everyone Whether you work in a digital team, operational role, on public facing services or are leading an organisation, everyone has a role in shaping how services work

# data[].attributes.headline
The Good Service Scale - Template Download

# data[].attributes.subject
The Good Service Scale - Template Download

# data[].attributes.body
The Good Service Scale — Good Services

# data[].attributes.attachment_link.readable_text
How to use the scale

Use the scale for user research, in workshops or on your own to assess and continuously monitor the quality of your service

Self-assess the quality of your service, either on your own or with your team

Structure your research with users and understand how your service is performing with different groups

Benchmark your service and track how it improves over time

Prioritise where to invest in service improvement by understanding which services need the most improvement

For more ideas and instructions on how to use the scale read the instruction guide

Good Service levels

Score your service against four levels of quality:

Level 5 - Good

Your service is easily findable and usable by anyone who needs to use it, enabling all users to consistently achieve the goal they set out to achieve. Your service is likely to encourage behaviours that benefit not just your user and staff, but society and the planet as a whole

Level 4 - Moderate

Most users are able to find and use your service successfully, although some users may still be excluded. A user's ability to achieve the goal they set out to achieve, in one seamless service is still likely to be made more difficult by organisational silos or more inconsistencies in the service

Level 3 - Unsatisfactory

Though some users will be able to use your service to reach their desired goal, the service is still difficult to use for the majority of users, and is likely to favour those with time and previous experience. Your users may face delays in the use of your service due to organisational silos or unnecessary bureaucracy, and may still become confused by inconsistencies in the service or ways of working that are unfamiliar

Level 2 - Poor

Though a minority of users might be able to complete your service it is unlikely to get them to the goal they need to achieve. The majority of your users are likely to struggle to find or use your service, either because it is not inclusive, or it is designed for expert use

Level 1 - Bad

Only the most expert and determined users can find and use this service, it is impossible for most. It may pose significant risks to those users who are able to use it by encouraging unsafe behaviours, and may make it extremely difficult for users to understand and resolve issues when they arise

For more detailed information about scoring read the scoring guide

Download the scale

Download the tool for free

# data[].attributes.attachment_link.description
Use the scale for user research, in workshops or on your own to assess and continuously monitor the quality of your service Self-assess the quality of your service, either on your own or with your team Structure your research with users and understand how your service is performing with different

# data[].attributes.body
Introduction - Digital Scotland Service Standard - gov.scot (www.gov.scot)

# data[].attributes.attachment_link.readable_text
We use cookies to collect anonymous data to help us improve your site browsing experience.

Click 'Accept all cookies' to agree to all cookies that collect anonymous data. To only allow the cookies that make the site work, click 'Use essential cookies only.' Visit 'Set cookie preferences' to control specific cookies.

# data[].attributes.attachment_link.description
We use cookies to collect anonymous data to help us improve your site browsing experience. Click 'Accept all cookies' to agree to all cookies that collect anonymous data. To only allow the cookies that make the site work, click 'Use essential cookies only.' Visit 'Set cookie preferences' to control specific cookies.

# data[].attributes.attachment_link.readable_text
This Age Thing is a community of healthy ageing advocates working collectively to celebrate diverse stories of getting older, challenge negative stereotypes, and help develop better products and services that can help all of us to age happier.

# data[].attributes.attachment_link.description
This Age Thing is a community of healthy ageing advocates working collectively to celebrate diverse stories of getting older, challenge negative stereotypes, and help develop better products and services that can help all of us to age happier.

# data[].attributes.body
Good Services: How to Design Services That Work : Downe, Louise: Amazon.co.uk: Books

# data[].attributes.attachment_link.readable_text
Select Your Cookie Preferences

We use cookies and similar tools that are necessary to enable you to make purchases, to enhance your shopping experiences and to provide our services, as detailed in our Cookie Notice. We also use these cookies to understand how customers use our services (for example, by measuring site visits) so we can make improvements.

If you agree, we'll also use cookies to complement your shopping experience across the Amazon stores as described in our Cookie Notice. This includes using first- and third-party cookies, which store or access standard device information such as a unique identifier. Third parties use cookies for their purposes of displaying and measuring personalised ads, generating audience insights, and developing and improving products. Click 'Customise Cookies' to decline these cookies, make more detailed choices, or learn more. You can change your choices at any time by visiting Cookie Preferences, as described in the Cookie Notice. To learn more about how and for what purposes Amazon uses personal information (such as Amazon Store order history), please visit our Privacy Notice.

# data[].attributes.attachment_link.title
Good Services: How to Design Services That Work

# data[].attributes.attachment_link.description
Service design is a rapidly growing area of interest in design and business management. There are a lot of books on how to get started, but this is the first book that describes what a 'good' service is and how to design one. This book lays out the essential principles for building services that ...

# data[].attributes.body
Courses - Service Design Academy (sda.ac.uk)

# data[].attributes.attachment_link.description
See the range of courses available from the Service Design Academy. We teach businesses and individuals the value of good service design.

# data[].attributes.attachment_caption
We are currently designing for 1 in 55 people in Scotland.

# data[].attributes.body
From L&D session

# data[].attributes.headline
[Video] Service Design Academy with Dover Fuels 

# data[].attributes.subject
[Video] Service Design Academy with Dover Fuels 

# data[].attributes.body
Service Design Academy with Dover Fuels - YouTube

# data[].attributes.body
Child poverty system map - gov.scot (www.gov.scot)

# data[].attributes.attachment_link.readable_text
We use cookies to collect anonymous data to help us improve your site browsing experience.

Click 'Accept all cookies' to agree to all cookies that collect anonymous data. To only allow the cookies that make the site work, click 'Use essential cookies only.' Visit 'Set cookie preferences' to control specific cookies.

# data[].attributes.attachment_link.description
This system map shows the range of factors that influence child poverty, and the relationships between them. It is intended to help develop a shared understanding, examine the evidence about how factors interact, and provide a key reference for people looking to address the systemic factors that inf

# data[].attributes.body
Tools for Systems Thinkers: The 6 Fundamental Concepts of Systems Thinking | by Leyla Acaroglu | Disruptive Design | Medium

# data[].attributes.attachment_link.title
Tools for Systems Thinkers: The 6 Fundamental Concepts of Systems Thinking

# data[].attributes.attachment_link.description
In this series on systems thinking, I share the key insights and tools needed to develop and advance a systems mindset for dealing with…

# data[].attributes.body
3 popular ways to run a productive retrospective (nulab.com)

# data[].attributes.attachment_link.readable_text
The Scrum framework of project management is based on four basic Agile meetings, i.e., ceremonies: the Sprint Planning meeting, Daily Stand-up, Sprint Review, and Sprint Retrospective.

Brandi Gratis

September 14, 2020

Continuous improvement is one of the biggest benefits of working in an Agile work environment, and in the Scrum framework, the driver of improvement is the Retrospective.

Retrospectives are ceremonies held at the end of each Sprint where team members collectively analyze how things went to improve the process for the next Sprint. They're usually facilitated by a Scrum Master and include only the team (not managers or other stakeholders, since their presence can deter teams from bringing up mistakes).

Teams identify key observations, like:

what's working

what's not

what can be improved

what can be added to the process

what can be removed from the process

People have come up with various formats and exercises for approaching these topics, but all face a similar challenge: keeping the Retrospective engaging and productive over time. Unfortunately, no single approach is a silver bullet.

People tend to adapt to new habits fairly quickly. After a few Sprints with the same kind of Retrospective following each time, you'll probably notice that team participation and the overall energy level people bring to the Retrospective start to drop.

That's why it's important to mix things up! As one of my favorite bizarre sayings goes: there's more than one way to skin a cat. And there's certainly more than one way to run a Retrospective. The best way to keep Retrospectives productive is to continuously challenge the team to think of solutions in new and interesting ways and create an agile Retrospective format.

Here are three popular ways to run a Retrospective.

Start, stop, continue

One of the most straightforward ways to run a Retrospective is the "Start, Stop, Continue" exercise. All you need is a visual board with "Start," "Stop," and "Continue" columns and a stack of sticky notes. Within each column, people write their observations about the Sprint as they relate to the following categories:

Start: actions we should start taking

Stop: actions we should prevent or remove

Continue: actions we should keep doing and formalize

Start by giving your teams a set amount of time (5-10 min) to write and categorize their cards. When everyone finishes, address each item one by one to allow people time to share input. At the end of the discussion, set up a vote to decide which items are most important. Give each team member a set number of items they can vote for (usually three). Calculate which items got the most votes selecting the top few (no more than three), and keep those items as your area of focus for the next Sprint.

Review these focus areas at the beginning of your next Retrospective to measure their success. Incorporate any feedback into your next "Start, Stop, Continue" board.

The Agile Retrospectives

The "Start, Stop, Continue" exercise is too brief and quickly feels repetitive for some. Esther Derby and Diana Larsen created a more in-depth approach in their book Agile Retrospectives. With a bit of tweaking for personalization, your team can use an agile retrospective format. To follow, break up your Retrospective into the following five stages:

1. Set the Stage

2. Gather Data

3. Generate Insights

4. Decide What to Do

5. Close the Retrospective

Set the stage

'Set the stage' means priming your team for discussion. Start with a game, like asking each team member to summarize the Sprint using only three words. Use the first few minutes of your meeting to establish an open and informal tone where people feel comfortable bringing up ideas.

Gather data

You can approach the data gathering stage much like the beginning of the "Start, Stop, Continue" exercise. Ask each team member to compile their observations about the Sprint onto cards.

Generate insights

To generate insights, lay out all the cards from your team and organize them by similarities. Sometimes you might notice that many people share the same point, which probably means it's worth addressing. Other times people may realize that all the cards seem to relate to a specific stage in development. Now is the time to pay attention to recurring themes, patterns, and issues that might cause one another.

Decide what to do

Next, it's time to decide how you will put those insights into action. The team should brainstorm solutions and put a plan in place to actualize the best ideas. It's best to limit the number of changes Sprint-to-Sprint, so you can isolate their effects when reviewing them at the next Retrospective.

Close the Retrospective

Finally, it's time to close the Retrospective on a high note. Too often, meetings end when people simply run out of things to say. Close your Retrospective with a summary of findings and praise things done well. The ending of these meetings should be a celebration!

Good, bad, better, best

For some, both of the above approaches rely too much on the Scrum Master. Because Scrum teams are self-organizing, many want to emphasize team members working together rather than "reporting to" the will of a Scrum Master or Project Manager.

The "Good, Bad, Better, Best" model starts much like the "Start, Stop, Continue" exercise and the data-gathering stage from Agile Retrospectives. Give your team 5-10 minutes to write down their observations about the Sprint on separate cards.

Once people finish writing, take turns going around the room one by one, with each person discussing one card per turn. Unlike the other two formats, present all cards before discussions start. This is the discovery phase. Questions from the team are fine, but debate can't begin until the last person finishes. Continue the discovery phase until all cards have been read and placed on the board, then discuss as a whole. Each item should be categorized as follows:

Good: Things that went well, i.e., areas where the team met or exceeded expectations

Bad: Things that didn't work well, i.e., areas where the team didn't meet expectations or where unexpected problems occurred

Better: Opportunities for improvement, i.e., suggestions on how to do something better

Best: Things that deserve recognition, i.e., outstanding performances and people who went above-and-beyond

The most important differentiator of this process is that the Scrum Master (or whoever is serving as the facilitator) is not to editorialize, comment on, or summarize the discussions. The Scrum Master is an observer, gathering information related to the project overall. The team should drive the conversation. Team members are also responsible for deciding on action items and next steps to prevent the Scrum Master from taking on a delegatory role.

Final thoughts

There are many other Retrospective formats and activities you can use to enhance these meetings. If your team starts to fall into a rut using one format, switch to another, or alter aspects of your current format. Small changes - like putting all cards on the board at once vs. going around the room one at a time - can be enough to re-spark engagement. Keep things interesting, and don't be afraid to try new formats just because they don't have the same features as your old one.
This post was originally published on November 14, 2016, and updated most recently on September 14, 2020.
Once you've settled on an update or change to your process, be sure to track how those changes affect your workflow and output over time - project management software can be especially helpful here. Whether you're running Agile as a development team, product team, or whole business, retrospectives will give you invaluable insights that incrementally improve your teamwork over time.

# data[].attributes.attachment_link.title
3 popular ways to run a productive retrospective

# data[].attributes.attachment_link.description
The Scrum framework of project management is based on four basic Agile meetings, i.e., ceremonies: the Sprint Planning meeting, Daily Stand-up, Sprint Review, and Sprint Retrospective. Brandi Gratis September 14, 2020 Continuous improvement is one of the biggest benefits of working in an Agile work environment, and in the Scrum framework, the driver of improvement is the Retrospective.

# data[].attributes.headline
How to run an agile retrospective meeting

# data[].attributes.subject
How to run an agile retrospective meeting

# data[].attributes.body
How to Run an Agile Retrospective Meeting with Examples (atlassian.com)

# data[].attributes.attachment_link.readable_text
The steps above are for a brief 30-minute retrospective meeting. Depending on the scope and complexity of your work, team size, and/or length of time since the last retrospective, you may need to expand this up to an hour, or possibly even two hours. Scale each section of the basic workshop as you see fit.

Alternatively, here are some variations and extra elements to try.

MAP OUT THE PAST TWO MONTHS (10 MIN)

On the whiteboard, draw a timeline spanning the past two months. Then have team members call out significant events: iteration/sprint starts, releases, victories, discoveries, moments of great teamwork, or anything else that had an impact on your work.

Do this activity at the start of the meeting. Not only is this a great way to foster a shared sense of achievement and solidarity, it helps refresh everyone's memory and sets the stage for the rest of the retrospective.

THE 4 Ls MODEL (20 MIN)

Replace the "what worked well" and "what didn't work well" activities with a four-part format:

What did you like?
What was lacking?
What did you learn?
What do you long for going forward?

This variation works best in longer (45 - 60 min) retrospectives where you can devote five minutes or more to each question.

TESTIFY (10 MIN)

If time allows (and team members are willing), have each participant speak about the stickies they put up during the "What worked well", "What didn't work well", and "Next steps" activities. This helps to ensure all team members contribute evenly (even the quieter team members) and promotes an even deeper discussion.

ACKNOWLEDGEMENTS (5 MIN)

Take a few minutes to let team members acknowledge each other's accomplishments since the last retrospective and/or express thanks for having received help from a teammate. Keep it brief, and keep it genuine. At some there might be a flood of acknowledgements, while at others there might be very few. Just roll with the ebb and flow - don't force it.

This should be a strictly peer-to-peer exercise, with only team members at the individual contributor level allowed to participate. Managers, scrum masters, etc. are asked to keep quiet.

DOT VOTING (5 MIN)

If loads of ideas emerge during the "Next steps" activity, vote on which action items you'll prioritize in the immediate term. Everyone grabs a marker and places dots on the three ideas they'd like to see at the top of the list (no more than one dot per idea, please!). Tally up the dots, discuss the results with your team, and select owners for the top-voted items.

Note that you can also do this immediately after the "What didn't work well" activity to identify the team's top three areas for improvement. This helps guide the "Next steps" activity and keep it focused on those three areas.

To see a retrospective in action, click here.

# data[].attributes.attachment_link.title
How to Run an Agile Retrospective Meeting with Examples

# data[].attributes.attachment_link.description
The steps above are for a brief 30-minute retrospective meeting. Depending on the scope and complexity of your work, team size, and/or length of time since the last retrospective, you may need to expand this up to an hour, or possibly even two hours. Scale each section of the basic workshop as you see fit.

# data[].attributes.body
Collaborative sensemaking – mygov.scot | resources

# data[].attributes.attachment_link.readable_text
Summary

Sensemaking is a collaborative technique used to validate, organise and interpret research data. Find out how to plan and run a sensemaking workshop.

User research activities can result in a large, sometimes overwhelming amount of data. Sensemaking is a collaborative technique used to validate, organise and interpret research data.

Why we should sensemake

Research data needs to be analysed and interpreted so it becomes useful to the team, and can guide the way they design and deliver a service.

Your analysis should be unbiased and objective, and you'll need to do it quickly. You could try to do it on your own but this creates problems:

your personal biases and opinions will influence your interpretation

your logic may not make sense every time

you will not have time to explain all your decisions - no one will be able to judge whether your analysis is solid

Collaborative sensemaking overcomes these problems. In a sensemaking workshop you share your data with different people and ask them to do the analysis with you in a structured way. This is a fast and productive way to understand whether everyone sees the same issues from the evidence, gather different perspectives on the data and check that your analysis of the problem is thorough.

As well as producing more robust insight, collaborative sensemaking gives the wider team (including users and stakeholders) an opportunity to see for themselves what was seen and heard, and reflect on what this means for the project. It helps everyone on the team become part of the design decision-making process.

How to make sense of your research

Collecting your data

At the end of every research session, record your most important thoughts and ideas while they're fresh. Use these questions to prompt your thinking:

what is this saying or what is trying to be conveyed here?

what is this an example of?

what do I see going on here?

This is a good time to make sure that your research approach and questions are still relevant. Change your questions - or your approach - if you feel you're not learning anything.

Soon you'll have collected a vast amount of data, and it will be in many formats. For example, statistics, transcripts, video recordings and scribbled notes.

When to run a sensemaking workshop

Every project is different. But as a rule, you should use sensemaking workshops as part of your research analysis after any significant piece of user research when you need to either:

make sense of the research

validate conclusions you have already made about the research

Once you have a good grasp of sensemaking, you should include workshops in the team's project plan. Sensemaking may be a new concept to the team and this will help underline its importance and value.

Before your workshop

Prepare your data so it's easy for workshop participants to use and understand.

Sticky notes are good because you can move them around easily and use colours as categories. Use them to write important points, quotes and categories. You could also print out and cut up typed notes or transcripts separately.

Label each piece of data so you know which participant number, workshop and task it relates to. Make sure you leave out any information which could be used to identify research participants.

If your research involves watching someone do something, categorise your notes by:

what the participant said

what the participant did

what the researcher/observer/facilitator thought

Labelling gives you a record so you can understand and - if necessary - explain how decisions were made.

Choosing your participants

Plan your session to make sure you involve the right people and make best use of the time available. Who you invite will depend on your project, the goals of the workshop, the project phase and the time and space available.

There should be a maximum of 9 participants per facilitator, who can be split into smaller groups for some activities. Participants can be more likely to contribute if they're in a smaller group. You can easily scale a workshop with the support of more facilitators.

A mix of people from different disciplines, roles, or with different relationships to the service is essential to provide the perspectives you need.

Think about how the participants will relate to each other and the different levels of experience and understanding of the project. Also consider what skills are needed to take part - such as reading or analysing research data - and what experience people may have of this.

You should consider people from these groups:

users and stakeholders of the service

people who have observed research workshops

people involved in making decisions about the design of the service

people whose work will be directly affected by the workshop

Making participants comfortable

Building trust is an essential part of collaboration. Treat participants as equals, with respect and care. When you first invite them to take part, consider their time and commitments. Explain clearly:

the value and goals of the workshop

what you expect from them

anything they need to do in advance

When planning the workshop, make sure:

the format of the workshop lets all participants contribute, regardless of any disability

the location is easy for everyone to reach and enter and has suitable facilities

you provide extra support for those who may need it

all participants understand and agree with any 'rules of engagement' - for example, behaving appropriately and keeping conversations confidential, especially if you're sharing sensitive data

participants who have contributed data to the workshop are not in a group looking at their own information

to limit the number of non-participants in the room

Make sure there's enough space for small groups to move around. The wall space should be big enough to display the research and to allow the groups to work on it.

You may want to record the workshop with photos and/or film. This can be helpful to share the findings more widely afterwards. Get permission from the participants and give them the chance to opt out of being recorded if they wish. This should be included when you get consent.

Planning the workshop activities

Create a workshop plan based on your research and aims. You may already have themes, assumptions or user needs to validate - think about how you'll present them to people who are not as close to the project as you.

For guidance, timings and activities download the Collaborative Sensemaking Template.

What to bring to the workshop

To run the workshop you should bring:

data from the research you've carried out

any additional research for supporting evidence

sticky notes

marker pens

Facilitating the workshop

A facilitator will prompt discussion and keep conversations focused. This could be someone with facilitation experience, but if you want to reduce bias you should use someone who is not attached to your project.

As a facilitator, your role is to draw out the thoughts and experiences of the group, asking questions rather than letting your own opinion influence the discussion. Participants should be doing most of the talking.

Question any individual opinions or anecdotal evidence. Keep bringing the discussion back to the research data. The workshop is about understanding the problem so keep the focus on the problems, challenges and barriers, not on possible solutions.

The workshop is an opportunity to review and discuss, not to reach agreement on everything. If the discussion gets stuck on something, move on to the next topic.

Writing up the results

At the end of the workshop the participants will provide you with one or more sets of themes. You must now bring these together and sensitively balance and judge the different perspectives.

You can share the results in different ways, for example a concise presentation or report. This should summarise the research, what it means for the project and how it can help the project team take action.

Before starting on the report or presentation, write up the workshop notes and data. This will help you form a story around the findings, making them easier to describe and communicate.

You should also present and discuss your findings with any workshop participants who are not on your project team. This only needs to be an informal presentation.

Read more about communicating findings.

# data[].attributes.attachment_link.description
Sensemaking is a collaborative technique used to validate, organise and interpret research data. Find out how to plan and run a sensemaking workshop. User research activities can result in a large, sometimes overwhelming amount of data. Sensemaking is a collaborative technique used to validate, organise and interpret research data.