Experience design
Dev dogfooding is not user research
Managers and team members often have common goals during the project lifecycle. All are interested in change, either technology, or process, or even business models. Independent of the final direction, there are some fundamental prerequisites to consider even prior the project start which sometimes requires a change in mindset and project set-up.
If you ask managers and change agents alike why change fails, you get different answers. But if you filter out all the nuances, the most common answer is people:
At Thoughtworks, we don’t think addressing the people issue means coming up with better communications, or explaining the reasons for the change. We think people are more likely to engage with change when people are put front and center, and when change starts with them.
The concept of people-centered change echoes the principles of another influential discipline that starts with the user: user-centered design.
User-centered design believes in one fundamental truth: gather success when starting with the user, finding a real user need and then building a good solution. If you find a real need and provide a good solution people will be willing to pay for it, and commercial success will follow.
But what will happen if you start with the employees, the teams, the people on all levels of the hierarchy and ask the question what they need to be better at their job? What if you identify their needs and come up with solutions? What if the same assumption the underpin user-centered design holds true — that you start identifying from needs, before looking at good solutions or commercial success?
In our experience that often does hold true. If you have empowered teams, which have everything they need to do their job and no organizational blockers keeping them from being fabulous, they will deliver more value to the company.
Or as Peter Drucker put it:
First up: research. What is the current situation? Research — as in user-centered design you have to start with research to understand the problem at hand. Observe, listen to the stories.
Once you understand the needs, you can go into solutioning. With the ideas at hand, you can start to break down the steps into a roadmap. Last but not least: scale. Once you have seen first success how to scale that through your organization? This rather than start with user stories and think about possible workarounds.
Something product designers are very keen on are so-called workarounds. A workaround is something a user does with a certain product it wasn’t intended for. If you start thinking about workarounds, they’re everywhere.
The earliest example of a workaround I can remember was at my grandparent’s house. When we were little, we used to sleep upstairs while my grandparents were downstairs. The light switch for the staircase was too high to reach So my grandma would put a walking cane next to the wall, as she was scared we would fall down the stairs in the dark.
Actually, my grandma’s house was full of workarounds. And, the older she got, the more workarounds appeared. There was the nutcracker to open jars and bottles; tongs to pull up her stockings. What she was doing was adapting her environment to her needs and ability.
And this is what workarounds do for their users: they have a need and lacking a suitable solution, they find ways to make things work.
That also happens in organizations. Keep your eyes open, and you see plenty of workarounds the hidden network people have, to get stuff done outside the official process; the ways they adapt their workspaces to make them more convenient; tweaks to remember stuff. And these workarounds tell you something about barriers for value to flow in your organization.
Once you’ve identified the workarounds, what’s next? We think it makes sense to try to understand the underlying problem. What is the person or team trying to solve? Why did they adopt the workaround? How does the workaround make their life better?
To get to the bottom of these questions, you can ask people, you can observe but often working on it together, in your team, is the best approach.
For instance, when you are building a system to specify products, you need a good team set up. The power users are tightly integrated, the developers regularly delivering value and the team is protected from interruptions. Nevertheless, there can be misunderstandings; things might not feel smooth, but you can’t put the finger on why.
So you might have to run what we call the journey a story. A story in agile is the representation of the value that is being delivered. So basically, if you follow the story through the process you get the value stream visible.
When you put the stickies up on the wall, patterns became visible. It is easy to see who was involved with each story and when and who wasn’t involved at all. And so you can create a common picture of what was going on, and decide together what your biggest needs for improvement were.
The biggest value in this exercise lies in getting a common understanding of what is happening. Even when conducting interviews and working with individuals rather than teams, there comes a moment when it’s important to put the insights on the table and discuss them.
We were working for the digital team of an automotive company and were tasked with improving the planning process. Here it was important to assess the different perspectives. The person responsible for consolidating the planning had different needs from the teams or stakeholders. We first gathered individual needs and then generated a big picture, which was then shared in a workshop with everybody involved. Priorities were discussed and agreed on. Here, a second principle shines through: don’t just see things from the user’s perspective but let them decide what it is they want to change.
In product development, we believe in iterative approaches. Try something, put it in front of your customer, gather feedback, learn from it, go again.
The same is true in organizations. Design an experiment that helps you combat the existing problem. Set yourself a timebox and see if things improve. Go broad, try to come up with different solutions and see what works best. Even if you don’t solve the problem, you will learn from it and it will help you to understand the problem better.
Establishing DevOps is a transition that is happening everywhere. It is a classical change challenge, mainly around breaking down silos and getting people to work together in different ways than they’re used to. It’s one of those situations where you’ll find a lot of workarounds during research. No matter how big the organizational walls between silos are, there are always people who have found ways of working around them. Who knows who to talk to get stuff done? This is where you want to start when solutioning. Can you take those people and their under-the-radar solutions to form the basis of an official experiment? Think about what you can get these experiments to do, make it official and show the benefit from it. What can you learn? How can you spread that?
In product development, when we have a long way to go we create a roadmap. So once you’ve identified your problems, paint a picture of how you’d envisage an ideal future. We call that the target state. Similar to a product vision, you now have a guiding star of where you want to go. Now, you can design your experiments step by step, without losing sight of where you want to go. It also helps to define measures for your experiments because the question you’re trying to answer with each experiment is: What have we learned that gets us closer to the target state?
Let’s continue with the DevOps example from above. DevOps has many facets to it and probably even more misunderstandings. The roadmap helps you to keep the target picture you created together visible. At the same time, you’re breaking down the steps of how to get there. Having both visible at all times helps to stay on track while experimenting. To get closer to your DevOps goal, you can have different topics up on the wall. For example, automation, breaking down process barriers to have people interact more closely and generate the necessary infrastructure as code. Now, you can make your experiment in those three areas visible and make sure they get you closer to your overall goal.
If you design good experiments and see success, you’ll be rewarded with the best thing a designer can hope for: word of mouth. The success stories happening in one part of your organization will go viral. The early adopters who’ve tried the new ways will drag the majority along, and changes will spread through your organization.
One thing that can help create the buzz is what we call information radiators. Visualizing what is happening up on the wall helps the team to find common understanding and stay on track, but also makes the change visible. People get curious and start asking questions. If you don’t want to rely on people picking up on things, be more proactive and run some ‘lunch and learns.' Order some pizza, invite everybody along and share what you are doing. This gives you an opportunity to share what you are doing and start talking to those interested.
No matter where you start — in a team, with the strategy group, or any other group — the process is always the same. Understand the problem, find your target picture and start experimenting. Pick any user group and just get started.
If you ask managers and change agents alike why change fails, you get different answers. But if you filter out all the nuances, the most common answer is people:
- People who were reluctant
- People who didn’t understand
- People who didn’t have the skills
- People who didn’t follow the plan
At Thoughtworks, we don’t think addressing the people issue means coming up with better communications, or explaining the reasons for the change. We think people are more likely to engage with change when people are put front and center, and when change starts with them.
The concept of people-centered change echoes the principles of another influential discipline that starts with the user: user-centered design.
User-centered design believes in one fundamental truth: gather success when starting with the user, finding a real user need and then building a good solution. If you find a real need and provide a good solution people will be willing to pay for it, and commercial success will follow.
Changes in mindsets
Often, change is initiated from some urgent need — for instance, we need to be faster, or more efficient, or able to react quickly to the market. Change goals are almost always stated from the perspective of the enterprise.But what will happen if you start with the employees, the teams, the people on all levels of the hierarchy and ask the question what they need to be better at their job? What if you identify their needs and come up with solutions? What if the same assumption the underpin user-centered design holds true — that you start identifying from needs, before looking at good solutions or commercial success?
In our experience that often does hold true. If you have empowered teams, which have everything they need to do their job and no organizational blockers keeping them from being fabulous, they will deliver more value to the company.
Or as Peter Drucker put it:
The purpose of an organization is to enable ordinary human beings to do extraordinary things.
How to get there?
In the following, we describe, step by step, how to put your people — as users of your system — at the heart of change.First up: research. What is the current situation? Research — as in user-centered design you have to start with research to understand the problem at hand. Observe, listen to the stories.
Once you understand the needs, you can go into solutioning. With the ideas at hand, you can start to break down the steps into a roadmap. Last but not least: scale. Once you have seen first success how to scale that through your organization? This rather than start with user stories and think about possible workarounds.
Something product designers are very keen on are so-called workarounds. A workaround is something a user does with a certain product it wasn’t intended for. If you start thinking about workarounds, they’re everywhere.
The earliest example of a workaround I can remember was at my grandparent’s house. When we were little, we used to sleep upstairs while my grandparents were downstairs. The light switch for the staircase was too high to reach So my grandma would put a walking cane next to the wall, as she was scared we would fall down the stairs in the dark.
Actually, my grandma’s house was full of workarounds. And, the older she got, the more workarounds appeared. There was the nutcracker to open jars and bottles; tongs to pull up her stockings. What she was doing was adapting her environment to her needs and ability.
And this is what workarounds do for their users: they have a need and lacking a suitable solution, they find ways to make things work.
That also happens in organizations. Keep your eyes open, and you see plenty of workarounds the hidden network people have, to get stuff done outside the official process; the ways they adapt their workspaces to make them more convenient; tweaks to remember stuff. And these workarounds tell you something about barriers for value to flow in your organization.
Once you’ve identified the workarounds, what’s next? We think it makes sense to try to understand the underlying problem. What is the person or team trying to solve? Why did they adopt the workaround? How does the workaround make their life better?
To get to the bottom of these questions, you can ask people, you can observe but often working on it together, in your team, is the best approach.
For instance, when you are building a system to specify products, you need a good team set up. The power users are tightly integrated, the developers regularly delivering value and the team is protected from interruptions. Nevertheless, there can be misunderstandings; things might not feel smooth, but you can’t put the finger on why.
So you might have to run what we call the journey a story. A story in agile is the representation of the value that is being delivered. So basically, if you follow the story through the process you get the value stream visible.
The importance of user stories
Go into a room together, and every role got differently colored stickers and write down every step they made from the first to the last contact with any given story.
When you put the stickies up on the wall, patterns became visible. It is easy to see who was involved with each story and when and who wasn’t involved at all. And so you can create a common picture of what was going on, and decide together what your biggest needs for improvement were.
The biggest value in this exercise lies in getting a common understanding of what is happening. Even when conducting interviews and working with individuals rather than teams, there comes a moment when it’s important to put the insights on the table and discuss them.
We were working for the digital team of an automotive company and were tasked with improving the planning process. Here it was important to assess the different perspectives. The person responsible for consolidating the planning had different needs from the teams or stakeholders. We first gathered individual needs and then generated a big picture, which was then shared in a workshop with everybody involved. Priorities were discussed and agreed on. Here, a second principle shines through: don’t just see things from the user’s perspective but let them decide what it is they want to change.
Solutioning by experiments
In product development, we believe in iterative approaches. Try something, put it in front of your customer, gather feedback, learn from it, go again.
The same is true in organizations. Design an experiment that helps you combat the existing problem. Set yourself a timebox and see if things improve. Go broad, try to come up with different solutions and see what works best. Even if you don’t solve the problem, you will learn from it and it will help you to understand the problem better.
Establishing DevOps is a transition that is happening everywhere. It is a classical change challenge, mainly around breaking down silos and getting people to work together in different ways than they’re used to. It’s one of those situations where you’ll find a lot of workarounds during research. No matter how big the organizational walls between silos are, there are always people who have found ways of working around them. Who knows who to talk to get stuff done? This is where you want to start when solutioning. Can you take those people and their under-the-radar solutions to form the basis of an official experiment? Think about what you can get these experiments to do, make it official and show the benefit from it. What can you learn? How can you spread that?
Roadmapping for targeting
It seems a big leap: going from removing one blocker in a team to rock star teams, but every journey starts with a first step.In product development, when we have a long way to go we create a roadmap. So once you’ve identified your problems, paint a picture of how you’d envisage an ideal future. We call that the target state. Similar to a product vision, you now have a guiding star of where you want to go. Now, you can design your experiments step by step, without losing sight of where you want to go. It also helps to define measures for your experiments because the question you’re trying to answer with each experiment is: What have we learned that gets us closer to the target state?
Let’s continue with the DevOps example from above. DevOps has many facets to it and probably even more misunderstandings. The roadmap helps you to keep the target picture you created together visible. At the same time, you’re breaking down the steps of how to get there. Having both visible at all times helps to stay on track while experimenting. To get closer to your DevOps goal, you can have different topics up on the wall. For example, automation, breaking down process barriers to have people interact more closely and generate the necessary infrastructure as code. Now, you can make your experiment in those three areas visible and make sure they get you closer to your overall goal.
Scale success across the company
If you design good experiments and see success, you’ll be rewarded with the best thing a designer can hope for: word of mouth. The success stories happening in one part of your organization will go viral. The early adopters who’ve tried the new ways will drag the majority along, and changes will spread through your organization.
One thing that can help create the buzz is what we call information radiators. Visualizing what is happening up on the wall helps the team to find common understanding and stay on track, but also makes the change visible. People get curious and start asking questions. If you don’t want to rely on people picking up on things, be more proactive and run some ‘lunch and learns.' Order some pizza, invite everybody along and share what you are doing. This gives you an opportunity to share what you are doing and start talking to those interested.
Your organization is full of users
This does work across all levels of your organization. Pull out an organizational chart. Every name on there in one way or another is a user of your organization. One core element that is often tackled early on in change processes is strategy — for good reason: the strategy sets the beat. But the strategy is made by people. Look at the people responsible for strategic direction. Try approaching them and their task the same way. To be able to generate a kick-ass, up-to-date strategy, what do they need? What makes their job harder today? Where are the barriers and what can you do to take them down.No matter where you start — in a team, with the strategy group, or any other group — the process is always the same. Understand the problem, find your target picture and start experimenting. Pick any user group and just get started.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
