Shepherded Behaviours

When we design software and games we have one focus: the user. Our goal is to develop meaningful interactions and workflows that the user will adopt. Constructing behaviours can be very difficult, especially when the nature of the interaction is complex or the nature of your system is complex. Approaching this problem can also be exacerbated if your product is novel. If your solution is novel, you will be tasked with educating the user with how your product can benefit them before you can begin building their intuition for using the product. Unfortunately, lengthy education can be offputting. Instead, one effective approach is guiding the user to discover the behaviour for themselves. This is one highly impactful example of Shepherding Behaviours.

I define Shepherded Behaviours as interactions that guide the user with intentional design but without explicit barriers or restrictions. These interactions occur by guiding the user without explicitly stating their goal or limiting the user's interactions. In situations that are difficult, shepherded behaviours shine. We are able to design with our clear intent, but also encourage behaviour through our second-order intent. The term may be very broad, but it is a useful tool for constructing user experiences.

Designs will always lead to some unanticipated user behaviours, but deliberately exploring downstream effects and shepherded behaviours during the design phase can reward with deep and nuanced interactions.

Case Study: Games

Depth is a common term in game design. We contrast deep gameplay with shallow gameplay and deep mechanics with shallow mechanics. I think that depth speaks to how engaging the decisions are within a game. Exploring all possible decisions is not required of the user, but there is fun in diving into strategy and developing mastery. By contrast, some games are fun because they offer complexity through a breadth of shallow mechanics. Some games are fun and avoid complexity altogether by offering short sweet experiences (that may be repetitive if in a longer form). Teaching rewarding (and complex) behaviours in games can be very difficult and "hand-holdy" tutorials are harshly criticized. So how do you teach users to have fun and to enjoy the game experience in full?

Animal Crossing: New Horizons is a wonderful example of shepherding users towards the "fun" parts of the game. Animal Crossing is beautiful for many, many reasons. For one, it is my go-to example for Iyashikei (a growing Japanese genre of healing games) in an industry dominated by action. There is very little strategy or fast-paced action in Animal Crossing. Instead, you find yourself in a slice-of-life island paradise building houses for friendly animals. The core game loop is based on building and bettering your island, which requires collecting resources and selling them for the in-game currency. That's really all there is to it. You collect resources, build your island, and have simple interactions with the animal inhabitants. With New Horizons in particular, multiplayer interactions are fantastic. Animal Crossing offers some depth in how you maximize your resource collection, but that pales in contrast to the depth provided by genuine player to player interactions. Sharing your island and its animal inhabitants with other players is one of the most fun parts of the game. That's why the game's "stalk market" is one of the most interesting components for our analysis.

New Horizons' "stalk market" has players purchase turnips at a random price at the start of the week and then try to sell them for a profit throughout the week as the price varies. This is important for the core game loop because it enables island upgrades and purchases to be made more quickly. However, this "stalk market" is not limited to the player's local island - they can sell their turnips on their friends' islands at the prices listed there. So, it is not the thrill of this day-trading simulator that makes the game more fun: it is the interaction with other players! To encourage player-player is no simple task — after all, you can't just tell people to make more friends. Here, the game designers have structured the player's experience such that having more friends to play Animal Crossing leads to more profits and rewards in the game. Being able to interact with five other players drastically increases the player's returns. This has motivated players to create online communities for people where they connect and sell their turnips. This shepherded behaviour results in players being far more social in the game and having even more fun!

Case Study: Software

One example within software is Shopify's choice to limit the number of products that a merchant can have. Shopify is a complex product and it is difficult to introduce all of its features to new users. By limiting the number of products for the introductory account, the new merchant is encouraged to look for other solutions to fully list their inventory. This leads to the discovery of product variants. A t-shirt should be one product with different variants for sizing rather than five completely different products. Shopify does not require the usage of variants, but instead the merchant is guided to that behaviour through the initial constraint.

Designing to Shepherd Behaviours

For myself, as a developer on a platform team, I think about how decisions will affect the system for other developers. How do you scale the impact your team has and shepherd behaviours? Netflix's application security team presents a similar paved road mental model which guides developers by making the road to security (the paved road) the easiest to follow. Codebases are constantly evolving and my team's influence often manifests in building foundational components, being opinionated about structure, and identifying best practices. Introducing a certain pattern or some code it becomes more likely to proliferate across the codebase as other developers look for established solutions. The intent is to solve the required problems but a lot of value is derived from the second-order effects.

Shepherding is most effective when you have a workflow goal in mind. The focus is on your player and your intent. It may be impossible to know how all of the different aspects of your design will bias workflows and create guided behaviours. Instead, focus on the behaviours you want and the situations or scenarios that guide the user there. If you teach the player to run and you've taught the player to jump... you can guide them towards doing these actions simultaneously by showing them a new wider gap to jump over.

Thank you for reading. Thank you for exploring ideas with me.